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

[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.


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