https://bugs.freedesktop.org/show_bug.cgi?id=72716
--- Comment #9 from Alex Deucher <[email protected]> --- (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.
_______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
