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

[Julien Isorce]

Thx for the suggestions.

No, it does not respond to ping.

radeon.dpm=0 does not help. But it only tells to use the old power
management right ?
So I tried: low, mid and high for /sys/class/drm/card0/device/prower_profile
 (and setting profile for power_mode)
With radeon.dpm=1 I tried all values for power_dpm_state /
power_dpm_force_performance_level. Same results.

I also tried today amd-staging-4.9 branch and same result.

Note that this also happens on W600 (verde), W9000 (tahiti) and W9100
(hawaii), with radeonsi driver.

I have open a bug here: https://bugs.freedesktop.org/show_bug.cgi?id=100465
. It contains a test to reproduce the freeze.

Cheers
Julien

On 29 March 2017 at 18:26, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170330/ba556c2b/attachment.html>