[PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Michel Dänzer]

On 29/03/17 06:07 PM, Christian König wrote:
> Am 29.03.2017 um 10:59 schrieb Michel Dänzer:
>> On 28/03/17 08:00 PM, Julien Isorce wrote:
>>> On 28 March 2017 at 10:36, Michel Dänzer <michel at daenzer.net
>>> <mailto:michel at daenzer.net>> wrote:
>>>
>>>      On 28/03/17 05:24 PM, Julien Isorce wrote:
>>>      > Hi Michel,
>>>      >
>>>      > About the hard lockup, I noticed that I cannot have it with the
>>>      > following conditions:
>>>      >
>>>      > 1. soft lockup fix (the 0->i change which avoids infinite loop)
>>>      > 2. Your suggestion: (!(rbo->flags & RADEON_GEM_CPU_ACCESS)
>>>      > 3. radeon.gartsize=512 radeon.vramlimit=1024 (any other values
>>> above do
>>>      > not help, for example (1024, 1024) or (1024, 2048))
>>>      >
>>>      > Without 1 and 2, but with 3, our test reproduces the soft
>>> lockup (just
>>>      > discovered few days ago).
>>>      > Without 3 (and with or without 1., 2.), our test reproduces
>>> the hard
>>>      > lockup which one does not give any info in kern.log (sometimes
>>> some NUL
>>>      > ^@ characters but not always).
>>>
>>>      What exactly does "hard lockup" mean? What are the symptoms?
>>>
>>>
>>> Screens are frozen, cannot ssh, no mouse/keyboard, no kernel panic.
>>> Requires hard reboot.
>>> After reboot, nothing in /var/crash, nothing in /sys/fs/pstore, nothing
>>> in kern.log except sometimes some nul characters ^@.
>> Does it still respond to ping when it's hung?
>>
>>
>>> Using a serial console did not show additional debug messages. kgdb was
>>> not useful but probably worth another attempt.
>> Right.
>>
>> Anyway, I'm afraid it sounds like it's probably not directly related to
>> the issue I was thinking of for my previous test patch or other similar
>> ones I was thinking of writing.
> 
> Yeah, agree.
> 
> Additional to that a complete crash where you don't even get anything
> over serial console is rather unlikely to be cause by something an
> application can do directly.
> 
> Possible causes are more likely power management or completely messing
> up a bus system. Have you tried disabling dpm as well?

Might also be worth trying the amdgpu kernel driver instead of radeon,
not sure how well the former currently works with Cape Verde though.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer