| Summary: | radeon RV250: xorg locks up when running glxgears | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Jose <braket> |
| Component: | Drivers/DRI/r200 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Xorg.0.log with backtrace | ||
Looks like it might be evdev related. Does upgrading everything except xf86-input-evdev help? 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? > nevermind. As Dave mentioned on IRC, the hang is in DRILock, evdev handler just notices and prints the backtrace. xorg-server 1.7.1.902 fixes the problem. 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. 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. Is this still an issue with mesa from git? 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. 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.
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.