Description of problem: since F8 my machine will lock up Xorg randomly when using Firefox. Not quite sure if this should be filed under xorg-x11-server-Xorg xorg-x11-drv-ati firefox but as so far I can only see this hang when actively using Firefox, I'll file under that component. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.3.0.0-33.fc8 xorg-x11-drv-ati-6.7.196-1.fc8 firefox-2.0.0.10-2.fc8 How reproducible: totally random but multiple times a day Steps to Reproduce: 1. have a fully updated F8 box 2. be in X11 (gnome in case it matters 3. interact with firefox (enter text or click) Actual results: randomly Xorg will lock up as follows - display does not update - cursor still movable (I presume hardware cursor) - NumLock does not toggle LED - waiting up to 10 minutes still does not update display - ssh'ing to the machine works just fine, in a ssh session I will see (all commands run as root, after a sudo su -) + top shows X eating all CPU + pstack $(pidof Xorg) will just sit there + chvt 1 never returns and the display does not update (i.e. I still see X, not the expected VT 1) + issuing a 'shutdown -r now' works just fine but I see my frozen X until the machine actually resets Expected results: stable X Additional info: - I ditched all proprietary Firefox plugins from my system, error persists - logs will follow
Created attachment 282221 [details] tempertures and voltages of the box during a Xorg freeze
Created attachment 282231 [details] xorg.conf of the affected box
Created attachment 282241 [details] lspci -vvv of the affected box
Created attachment 282251 [details] syslog from shortly before the freeze and with the output of SysRq-t
Created attachment 282261 [details] SysRq-t output after issuing a chvt 1
some notes: $ rpm -qa|grep xorg|xargs rpm -V S.?..... /usr/bin/Xorg this seemed odd, so I did $ sudo rpm -i --replacepkgs xorg-x11-server-Xorg-1.3.0.0-33.fc8.i386.rpm $ rpm -V xorg-x11-server-Xorg ..?..... /usr/bin/Xorg yesterday. This morning the verify gave the same results bit now after another hang it reports S.?..... /usr/bin/Xorg again. As to machine stability itself, apart from the freezes with FF and Xorg the machine is stable. I used my old UT2003 with the linux client to give it a graphics workout, worked just fine. The machine will also be stable when not interacting with firefox (it tends to run 24x7 and the only times I log out is on new kernel, when playing under the games loader (see below) or when there is a kernel update. I also have that other OS installed to play World of Warcraft (which gives the machine a very thorough graphics workout as I play in 1600x122) and that is stable. Can't test anything else under Win though as WoW is the only installed application.
agh, fat fingers, in Comment #6 I obviously meant 'but now' and not 'bit now' '1600x1200' and not '1600x122'
an rpm -Va just showed S.?..... /usr/lib/libGL.so.1.2 setting on NEEDINFO to self until I get the hang again after the rpm -i --replacepkgs mesa-libGL-7.0.1-7.fc8.i386.rpm I just did
It hung again, still no idea how to trigger or to debug it. But at least what I mentioned in Comment #8 does not seem to be part of the problem. Removing the NEEDINFO on me.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please install firefox-debuginfo; in order to do this you have to enable -debuginfo repository. yum install --enablerepo=\*debuginfo firefox-debuginfo (if you use x86_64 firefox, install firefox-debuginfo.x86_64 package). Then run firefox with a parameter -g. That will start firefox running inside of gdb debugger. Then use command run and do whatever you did to make firefox crash. When it happens, you should go back to the gdb and run (gdb) thread apply all backtrace This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment. In case the freeze happens when you are not running firefox inside of the debugger already, you can connect with gdb to the existing firefox running with gdb --pid=$(pidof firefox-bin) and then you can continue with thread apply all backtrace. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 291427 [details] gdb output as requested here is the requested output
oh and for completeness' sake $ ps aux|grep Z USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND pcfe 3069 0.0 0.0 0 0 ? Z Jan08 0:00 [xrdb] <defunct> no idea though if that was a zombie already before the freeze, it just caught my eye in the top output.
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test Firefox 3, available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping as the default in Fedora rawhide and provide feedback as to whether it still exists so we can file a ticket upstream to try to fix it in Firefox 3 before it is released.
For other reasons (playing games) the box in question now has the closed source ATI driver. As such I am unable to test (and the hang has not occurred since the switch). As the open source ATI driver is moving rapidly in a good direction, I will close this bug for now with INSUFFICIENT_DATA and open a new one if the hang re-occurs once I switched back to the open source ATI driver (or if I do see the bug again under the current setup)