When one attempts to suspend the system while running compiz (have yet to try any other application), Xorg freezes on resume with nothing but a black screen and a cursor. The machine is still otherwise responsive (tested through serial console) although the keyboard does nothing. Log attached.
Created attachment 12660 [details] A log from a crashed Xorg session after VT switch
The problem actually appears to be an issue with VT switching as a whole. Switching to a VT then switching back to Xorg with compiz running results in a freeze 100% of the time.
might be a dup of bug# 13196...
Can you get a backtrace? See http://www.x.org/wiki/Development/Documentation/ServerDebugging
Created attachment 12836 [details] Backtrace from frozen Xorg process This was acquired by attaching a gdb session to Xorg remotely, and switching away from and back to Xorg.
It might be significant to note that after getting the above backtrace, I was able to restart Xorg and the system returned to fully working order.
Moreover, it appears that the following sequence of events also causes the same type of freeze: - Start Xorg with non-compositing window manager - Switch to a VT - Switch back to Xorg - Try starting compiz - Admire frozen Xorg session
Created attachment 12861 [details] [review] Test patch So it's a deadlock due to recursive locking... Does this patch happen to work? That 'drop batchbuffer on the floor' code's still a little iffy though.
Created attachment 12877 [details] A backtrace from Xorg patched with Attachment 12861 [details] As you can see, the patch certainly did something. Now, instead of deadlock, Xorg crashes from a SIGABRT, apparently after waiting for the GPU. Looks promising.
After restarting X after the crash (which perhaps unsurprisingly resulted in another deadlock with X running 100% of a CPU), I noticed the following message logged to the kernel log. It could have been produced by either the initial or restarted X session: [drm:drm_fence_lazy_wait] *ERROR* Fence timeout. GPU lockup or fence driver was taken down. 0 0x0000344e 0x03 0x01 0x00 [drm:drm_fence_lazy_wait] *ERROR* Pending exe flush 1 0x0000344e [drm:drm_bo_expire_fence] *ERROR* Detected GPU lockup or fence driver was taken down. Evicting buffer.
Created attachment 12878 [details] Xorg.log from crashed patched server Log gives ring buffer dump for your perusal
So this results in a GPU lockup instead, which probably isn't too surprising given the recursive batchbuffer flush... Does it work if you comment out the whole if (sarea->width != intel->width || sarea->height != intel->height) block in intelContendedLock() instead?
Nope, no dice. Commenting this block just seems to produce a complete hardware lockup instead. It may be that the kernel is still alive so I can pull some more detailed post mortem information over ssh, but I won't have another computer until later today. Should I try this?
Ben, does the fix in bug# 13196 helps?
(In reply to comment #14) > Ben, does the fix in bug# 13196 helps? > Michael, Thanks a ton, that was the bug. I can now VT switch with complete reliability. This will be in git soon?
Reopening so I can DUP it.
*** This bug has been marked as a duplicate of bug 13196 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.