| Summary: | VT switching with OpenGL application running freezes Xorg | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ben Gamari <bgamari> |
| Component: | Drivers/DRI/i915 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
A log from a crashed Xorg session after VT switch
Backtrace from frozen Xorg process Test patch A backtrace from Xorg patched with Attachment 12861 Xorg.log from crashed patched server |
||
|
Description
Ben Gamari
2007-11-20 16:26:52 UTC
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.