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

[Nicolai Hähnle]

On 29.03.2017 11:36, Michel Dänzer wrote:
> 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.

I've recently used it to experiment with the sparse buffer support. It 
worked well enough for that :)

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.