[Bug 72716] SIGBUS in EVERGREENUploadToScreen after hibernation (Linux 3.12.4-tuxonice)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Dec 23 06:22:12 PST 2013
https://bugs.freedesktop.org/show_bug.cgi?id=72716
--- Comment #9 from Alex Deucher <agd5f at yahoo.com> ---
(In reply to comment #8)
> During the many cycles of “printk, compile, reboot, suspend, resume, crash
> X” I’ve found that the problem may have to do with the fact that I load
> radeon.ko during my initramfs before attempting resume by echoing into
> /sys/power/resume or /sys/power/tuxonice/do_resume.
>
> If I do *not* load radeon.ko into the “booting” kernel (i.e., the one which
> is then replaced by the “resuming” kernel), I couldn’t reproduce the crash.
> Furthermore, I do *not* get these four messages from the “resuming” kernel
> about a lockup:
>
> [ 864.574325] radeon 0000:01:00.0: GPU lockup CP stall for more than
> 10000msec
> [ 864.574328] radeon 0000:01:00.0: GPU lockup (waiting for
> 0x0000000000000004 last fence id 0x0000000000000002)
> [ 864.574331] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed
> (-35).
> [ 864.574334] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB
> on ring 5 (-35).
I think what's happening is that when you get the GPU lockup, the driver can't
reset the GPU properly so it has no way to migrate data from non-CPU accessible
vram to CPU accessible vram and you end up with the SIGBUS when the CPU tries
to access the non-CPU accessible vram.
I'm not quite following what you mean by booting vs. resuming kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20131223/a9fd23d2/attachment.html>
More information about the xorg-driver-ati
mailing list