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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxxx
<mailto:michel@xxxxxxxxxxx>> 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.

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux