Bug 25005 - radeon RV250: xorg locks up when running glxgears
Summary: radeon RV250: xorg locks up when running glxgears
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-09 19:32 UTC by Jose
Modified: 2010-11-11 13:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log with backtrace (35.85 KB, text/plain)
2009-11-09 19:32 UTC, Jose
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jose 2009-11-09 19:32:58 UTC
Created attachment 31075 [details]
Xorg.0.log with backtrace

I just ugraded to xorg 7.5 and the system locks up when running 
glxgears.
When glxgears is run, a black square window appears and the system stops 
responding. The mouse pointer can still be moved but clicks are ignored 
and the keyboard doesn't respond (not even alt-sysrq keystrokes). 
I can still ssh into the laptop and see that glxgears is taking 100% 
cpu. If the process is killed, then the Xorg process goes at 100% cpu 
and can't be killed. The machine can be rebooted fine through ssh 
though.

For testing I downgraded all the Xorg related packages to the previous 
working version (some 7.4 state). Then I upgraded everything except:
xf86-input-evdev
xf86-video-ati
xf86-video-vesa
xorg-server

In this situation, the bug is not present. If I fully update, the bug 
appears. The updated (latest) versions of the server and driver packages are (in archlinux):
xorg-server 1.7.1.901
xf86-video-ati 6.12.99.git20091014

I attach my Xorg log with a backtrace.
Comment 1 Alex Deucher 2009-11-10 09:31:07 UTC
Looks like it might be evdev related.  Does upgrading everything except xf86-input-evdev help?
Comment 2 Jose 2009-11-10 14:41:34 UTC
I tried downgrading to xf86-input-evdev-2.2.5 but then my keyboard doesn't work and I can't test.

(In reply to comment #1)
> Looks like it might be evdev related.  Does upgrading everything except
> xf86-input-evdev help?
> 

Comment 3 Alex Deucher 2009-11-10 14:49:30 UTC
nevermind.  As Dave mentioned on IRC, the hang is in DRILock, evdev handler just notices and prints the backtrace.
Comment 4 Jose 2009-11-21 09:13:13 UTC
xorg-server 1.7.1.902 fixes the problem.
Comment 5 Jose 2009-11-29 20:05:27 UTC
The problem appeared again.
glxgears locks the computer with both xorg-server-1.7.1.902 (the version I thought fixed the issue) and with the new xorg-server-1.7.2 

I don't know what is going on, I swear I tested right after 1.7.1.902 and glxgears worked fine. I'll see if I can get more info.
Comment 6 Jose 2009-11-30 12:39:26 UTC
I did some more testing and I found a way to trigger the bug. Kernel version seems to have an effect on this bug.

With kernel 2.6.32-rc8:
- After a fresh boot, I run glxgears -> good
- I do a mem suspend/resume, run glxgears -> X locks

I can then reboot the system (through ssh) and I can repeat the steps above with the same results.


With kernel vanilla 2.6.31.6 the results are not so straight forward, something funny is happening there. Initially I tried:
- After a fresh boot, I run glxgears -> good
- Do mem suspend, however on resume computer restarts intead of resuming.

To get around this restart weirdness I have to do a suspend/resume before I can run glxgears at all. So:
- After a fresh boot, do a mem suspend/resume
- Run glxgears -> X locks

Another twist with 2.6.31.6 is that once the bug has been triggered, no number of reboots seem to make things work again: glxgears will lock up even on a fresh reboot.
The only way to have glxgears work after a reboot is to boot into 2.6.32-rc8.
Comment 7 Alex Deucher 2010-10-19 18:42:04 UTC
Is this still an issue with mesa from git?
Comment 8 Jose 2010-10-19 19:53:47 UTC
I won't have access to the machine with the ATI card for a while. It may be a couple of weeks before I have a chance to test it.
Comment 9 Jose 2010-11-11 13:06:26 UTC
I finally got a chance to test and the bug seems to be fixed.
There was no need to test mesa from git.

I'm running:
kernel 2.6.36
xorg-server 1.9.2
xf86-video-ati 6.13.2
mesa 7.8.2


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.