Hi Michel,
[..]
The most striking problem of kernel 3.18.9-rt4 affects all systems that
are equipped with Radeon graphics (irrespective whether PCIe cards or
APUs with on-chip graphics). They suffer from a hanging radeon driver.
The block occurs when accelerated graphics load is created by x11perf or
gltestperf. Sometimes only the graphics are frozen while ssh login still
is possible, somtimes the entire box is no longer accessible at all. In
any case, a reboot is needed to recover from this situation.
Here is a selection of kernel messages:
[...]
The commits from
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=f957063fee6392bb9365370db6db74dc0b2dce0a
to
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cffefd9bb31cd35ab745d3b49005d10616d25bdc
and
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=b6610101718d4ab90d793c482625e98eb1262cad
might help for this.
Thanks a lot. I have applied these patches to a number of systems:
# quilt applied | tail -7
patches/drm-radeon-do-a-posting-read-in-r100_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-rs600_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-r600_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-evergreen_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-si_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-cik_set_irq.patch
patches/drm-radeon-fix-wait-to-actually-occur-after-the-signaling-callback.patch
The graphic boards still crash and freeze the screen, but in contrast
to the earlier situation the systems remain accessible, and the X
Window server can be restarted after the offensive programs are
removed. The crashes were reliably triggered by
- gltestperf
or
- x11perf -repeat 3 -subs 25 -time 2 -rect10
This is not entirely correct, since gltestperf does not reliably crash
the graphics controller. However, "x11perf -repeat 3 -subs 25 -time 2
-rect10" always does a reliable job to trigger the crash.
but the crashes also occur several times per day during normal work
such as browsing the Internet or writing a text document. If you wish
me to provide additional diagnostic information such as running test
programs while the graphic boards are unresponsive, I certainly can do
that.
Does it also happen with a kernel built from a current drm-fixes tree?
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
No. Apparently, you need full preemption to expose the problem.
The following list contains the results whether the command "x11perf
-repeat 3 -subs 25 -time 2 -rect10" freezes the Radeon board under test
(Radeon HD 7970 XFS / R9 280X) or not:
linux-3.12.33-rt47 no
linux-3.14.34-rt32 no
linux-3.14.34-drm-3.16.7-rt32* no
linux-3.18.7-rt1 YES
linux-3.18.9-rt4 YES
linux-3.18.9-rt5 YES
linux-3.18.9-drm-3.16.7-rt5** no
linux-4.0.0-rc4 no
linux-drm-fixes no
*DRM subsystem backported from linux-3.16.7 to linux-3.14.34-rt32.
**DRM subsystem ported from linux-3.16.7 to linux-3.18.9-rt5.
More observations:
If full function tracing is enabled (which makes the system about five
times slower), the graphics controller no longer freezes. With partial
function tracing such as "echo *drm* >set_ftrace_filter", the
controller still freezes. The trace then contains vblank interrupt
processing only, ioctls are no longer executed.
This is the location where the driver hangs:
[25104.509258] INFO: task Xorg.bin:16591 blocked for more than 120 seconds.
[25104.516322] Not tainted 3.18.9-rt5 #2
[25104.520715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[25104.528853] Xorg.bin D ffffffff8171ed90 0 16591 16239
0x10400080
[25104.536102] ffff8800ba0bb8d8 0000000000000002 ffff8800ba0bbfd8
0000000000000006
[25104.536103] 000000000000dc08 ffff880626d0dc08 ffff8800ba0bbfd8
000000000000dc08
[25104.536104] ffff88061b2cdcd0 ffff880616d3a940 ffff880035c10000
ffff880616d3a940
[25104.559274] Call Trace:
[25104.561844] [<ffffffff8171bb54>] schedule+0x34/0xa0
[25104.561846] [<ffffffff8171e2ac>] schedule_timeout+0x23c/0x2a0
[25104.561870] [<ffffffffa00e3ab6>] ? radeon_fence_process+0x16/0x40
[radeon]
[25104.561879] [<ffffffffa00e3b24>] ?
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[25104.561887] [<ffffffffa00e3e97>]
radeon_fence_wait_seq_timeout.constprop.8+0x327/0x380 [radeon]
[25104.561889] [<ffffffff810d19c0>] ? __wake_up_sync+0x20/0x20
[25104.561898] [<ffffffffa00e4287>] radeon_fence_wait_any+0x57/0x70
[radeon]
[25104.561914] [<ffffffffa015a36f>] radeon_sa_bo_new+0x2af/0x4b0 [radeon]
[25104.561916] [<ffffffff81379b07>] ? debug_smp_processor_id+0x17/0x20
[25104.561918] [<ffffffff811d0b4a>] ? __kmalloc+0x8a/0x300
[25104.561932] [<ffffffffa01b2197>] radeon_ib_get+0x37/0xe0 [radeon]
[25104.561943] [<ffffffffa01003ee>] radeon_cs_ioctl+0x22e/0x860 [radeon]
[25104.561952] [<ffffffffa0005bc7>] drm_ioctl+0x197/0x670 [drm]
[25104.561954] [<ffffffff81379b07>] ? debug_smp_processor_id+0x17/0x20
[25104.561956] [<ffffffff810901ba>] ? unpin_current_cpu+0x1a/0x80
[25104.561959] [<ffffffff810ba200>] ? migrate_enable+0x90/0x1a0
[25104.561966] [<ffffffffa00c604c>] radeon_drm_ioctl+0x4c/0x80 [radeon]
[25104.561967] [<ffffffff811fdb88>] do_vfs_ioctl+0x2c8/0x4c0
[25104.561969] [<ffffffff81208a92>] ? __fget+0x72/0xb0
[25104.561970] [<ffffffff811fde01>] SyS_ioctl+0x81/0xa0
[25104.561971] [<ffffffff8171f99e>] tracesys_phase2+0xd4/0xd9
Conclusion:
An upgrade change of the DRM subsystem between 3.16.7 and 3.18.9
introduced a race condition that freezes Radeon graphics. It requires
full preemption to be exposed reliably.
Thanks,
-Carsten.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
