Summary: | Unity locks up with latest xorg/mesa/dri/drm | ||
---|---|---|---|
Product: | Mesa | Reporter: | Ernst Sjöstrand <ernstp> |
Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | pedretti.fabio, runesvend, stephan |
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Output of gdb after attaching to frozen/hung compiz
Output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz Second output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz |
Description
Ernst Sjöstrand
2011-04-25 01:16:00 UTC
I was in a hurry but I thought it was better with a quick bugreport than no report at all. :-) This was with Ubuntu Natty's 2.6.38 kernel + xorg-edgers 20110422. Can't remember exactly what I did, some window management operation. Hasn't happened since. Attached to compiz with gdb from the console and got the backtrace when this happened. Created attachment 47018 [details] Output of gdb after attaching to frozen/hung compiz I'm experiencing this bug as well, it seems. I'm attaching the output of gdb after attaching to compiz (which is what hangs/freezes). This bug happens when a new window wants to open. That's my experience at least. It can be any window. A new dialog in an existing program, or a new program opening up a window (for example mplayer). This happens for me using mesa from git from this PPA: https://launchpad.net/~oibaf/+archive/graphics-drivers/ I'm on r600g and x86-64 as well. Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . Does running thread apply all bt full in gdb give backtraces for any other threads? Yes, it's probably when a new window is created or similar. But just opening 100 gnome-terminals doesn't trigger it so it's not super easy to trigger. Created attachment 47157 [details] Output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz (In reply to comment #3) > Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex . > Does running > > thread apply all bt full > > in gdb give backtraces for any other threads? I'm attaching the output of that command here. Please let me know if I'm missing any relevant debug symbols. I can see a lot of the loaded libraries don't have debug symbols, so please let me know which are relevant, if any. Created attachment 47160 [details]
Second output of running 'thread apply all bt full' in gdb after attaching to frozen/hung compiz
It just happened again.
I did a 'thread apply all bt full' again, and I can see that the output isn't the same as the previous time. So I'm attaching this output in case it's relevant.
I have found a reliable way of reproducing this bug on this computer at least. Compiz must be enabled. 1. Go to CompizConfig Settings Manager (ccsm) 2. Under "Window Management"->"Resize Window" in the "General" tab, choose "Normal" as the Default Resize Mode. This will cause windows to resize real-time, as they are dragged by their corners/sides. 3. Open up gnome-terminal and start resizing the window quickly, it will lag a lot and eventually hang compiz. The output of gdb after attaching is similar to that of the "Second output" (https://bugs.freedesktop.org/attachment.cgi?id=47160) attached to this bug report. Ie. line #3 in Thread 1 is "radeon_bo_destroy" followed by "radeon_bo_reference" "r600_bo_destroy" "r600_bo_reference" etc. Old stuff not an issue anymore. |
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.