Created attachment 344247 [details] dmesg right after lock-up Description of problem: X is locking up on me rather often. It seems to happen more often when loading a page in Firefox (maybe because that's what I'm doing most of the time), but it has happened other times. When Xorg locks up, no updates are drawn on the screen. My cursor will move, but the cursor image doesn't update (eg. from standard pointer to text-insertion). Strangely, one, or sometimes both of my monitors will go blank and enter power-saving mode when X locks. Logging in via SSH shows Xorg at near 100% CPU. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.6.1-11.fc11.i586 xorg-x11-drv-ati-6.12.2-14.fc11.i586 How reproducible: Not at will. Sometimes restoring my Firefox session after a Xorg lock and reset will trigger another lock. Steps to Reproduce: 1. Wait 2. 3. Actual results: Unresponsive Xorg Expected results: Responsive Xorg Additional info: This is on a fully-updated F11 Preview install, with a Radeon 9000 and KMS enabled. I think the only time this has happened when I wasn't using Firefox was during a yum transaction in a terminal. That was also the only time Xorg un-locked after waiting a while. Maybe it's a coincidence, but it unlocked right when I pressed the control key. Or maybe the keypress just brought my monitor out of power-saving mode, and Xorg had already unlocked. I'll attach dmesg, Xorg.0.log and a gdb backtrace, all copied via SSH while Xorg was hung. Also, pointing strace to the running Xorg gets me this message repeated over and over: ioctl(8, 0xc0086464, 0xbfc9ae28) = -1 EBUSY (Device or resource busy)
Created attachment 344248 [details] gdb backtrace of locked Xorg
Created attachment 344249 [details] Xorg.0.log right after lock-up
I am experiencing the same problem on a Radeon Xpress 200M. Bt to follow.
Created attachment 344997 [details] Backtrace of locked xorg
John B, if you have a 200M, you may also be interested in bug 498457. Oh, and if you switch to vesa as a substitute, please let me know if you also are suffering from 498852.
On my machine the experience of comment #12 of bug 498457 has the result described here, 100% cpu in _kernel_vsyscall(). Firefox 3.5 definitely triggers this -usually within minutes of starting it- although it has happened elsewhere.
I just tried xorg-x11-drv-ati-6.12.2-15 and kernel-PAE-2.6.29.3-155. When I booted into runlevel 5, I could log in, but then my background came up, and the rectangular shape of an un-redrawn window. No response from keyboard. When I booted into runlevel 3, then ran startx, the screen filled with random-yet-tiled garbage, and the mouse pointer. The mouse pointer could not be moved, and the garbage didn't go away. I logged in remotely using ssh, and tried to get a backtrace of Xorg. gdb hangs. I tried running strace on Xorg, that also hangs. Screenshot to follow.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm going to have to stop using F11 because of this bug. Launching Firefox crashes my GPU every time, before a window even shows up. A hard reboot is the only option. If there is anything I can do to provide more information, I'll be glad to. Thanks, John
I've got a few updates to my original report: 1. This bug only happens with KMS enabled. So John B, try booting with nomodeset. 2. I still see this bug with: xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586 xorg-x11-drv-ati-6.12.2-14.fc11.i586 kernel-PAE-2.6.29.4-167.fc11.i686 Let me know if an updated backtrace would be helpful. 3. I saved a copy of my firefox profile after an X hang was triggered. Restoring this session reliably triggers a hang, so this bug is reproducible. If it would be helpful, I can try to get an X-hanging profile that doesn't have all my saved passwords, history, etc. and attach it.
Hi guys, This bug is likely a duplicate of bug 498457, you may like to head over there to catch the action.
Do you still have this issue with fedora 12 (you can test livecd from http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/) ?
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Unless someone else shows up to test, this report can be closed. I no longer have this video card and so cannot test it.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.