[Bug 72716] SIGBUS in EVERGREENUploadToScreen after hibernation (Linux 3.12.4-tuxonice)

[bugzilla-daemon at freedesktop.org]

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>