Description of problem: When X changed over initially I was able to use the ati driver without problems. Eventually with changes to the driver it quit working. What I get now is a mostly black screen with a more blue colored bar along the top. The computer becomes unresponsive. Hardware: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.7.196-3.fc9 How reproducible: Start in runlevel 5 or rl3 and use startx. Failure wil follow. Steps to Reproduce: 1. boot computer 2. load up to gdm 3. problem happens before gdm loads. Actual results: Black screen with bluish bar. Mouse will move around. System fan starts to increase. System unresponsive. Expected results: X to work normally. Currently using the vesa driver for report. Additional info:
Created attachment 290531 [details] Xorg.0.log for problem launched system
Created attachment 290532 [details] xorg config with vesa driver change To boot I need vesa. radeon is specified when problem shows.
Changing title to describe loop
Created attachment 290533 [details] This is Xorg.0.old for no xorg.conf condition Without any xorg.conf file the computer locks at the same place.
I reverted the ati driver to xorg-x11-drv-ati-6.7.195-5.fc9 and X works again for the driver and does not stick in the endless loop. Attached is the current Xorg.0.log with xorg-x11-drv-ati-6.7.195-5.fc9 installed.
Created attachment 290589 [details] Reverted xorg-x11-drv-ati-6.7.195-5.fc9 log which works The latest driver does not work with my system. 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1
xorg-x11-drv-ati-6.7.196-5.fc9.i386.rpm fails during gdm process or X process in runlevel 3 xorg-x11-drv-ati-6.7.196-2.fc9 works normally
The previously mentioned driver does not work at all now. After upgrading to the latest ati driver, no screen is found as with the symptom for the previously working driver. I now have to use the vesa driver.
Created attachment 291486 [details] Confirming mieqEnequeue: out-of-order with new server and driver I captured another log for the problem with mieqEnequeue: out-of-order that is occurring. I obsoleted one log which was not related to problem since gdm locks up also, rhgb works oddly enough. The system becomes unresponsive with no way to break out of the loop. I tried alt-sysreq-b and various other terminal changes with no escape. Holding down the power button is the only escape. Also elevating severity level since the X server no longer works with older ati drivers. Bumping to medium though it is urgent in my view and an F9 blocker.
xorg-x11-drv-ati-6.7.196-6.fc9 was driver used. Server info is latest version.
please test with -7 which I've just built for rawhide a bug in the IGP chips slipped through..
Created attachment 292035 [details] With xorg-x11-drv-ati-6.7.196-7.fc9 no problem Thanks for the fix. I can now use the ati driver without the loop. The crispness compared to vesa are an improvement. The sharpness compared to previous ati drivers is better also but probably a user imagination perspective.
Created attachment 292046 [details] On reboot, problem still showed When I initially tested this fix, I edited the xorg.conf file and then logged out to the gdm. I then logged back in and figured all was well. Later, I shut down the system and when booting up into runlevel 3 the problem happened again. Attached is the old log for the lockup. Reopening bug but with additional information that it does not seem to happen if vesa is used first and then the driver is changed back to radeon. The login is succesful except for errors in the no problem log.
Reporter, does it help when you switch off rhgb (i.e., by removing rhgb from kernel lines in /boot/grub/menu.lst)? I can reproduce a lot of mess (not sure whether it is the same mess as your issue) when Xs are *restarted*, so when they are run only once, this problem (if it is the one) doesn't happen.
The problem happens also when I boot up in runlevel 3. I have not tried to boot up in runlevel 5 without using rhgb. rhgb works, the lockup is when gdm starts or if I type startx in a vt in runlevel 3. I'll give it a try though and report back.
It locked up hard without rhgb in runlevel 5. I am searching the web and found this thread on first hit. http://lists.x.org/archives/xorg-driver-ati/2007-October/002745.html The only problem is that this problem happens before X loads. I guess I can try the combination key suggested. ALT+PRTSCRN (Hold while pressing other keys) R E I S U B while the loop is happening.
Created attachment 292229 [details] No mieqEnequeue in latest checked logs Of course the keypresses did not work. Now for this log, there was no mieqEnequeue: out-of-order valuator event; dropping. in loop at the end of several logs. This one I had no mouse since I purposely changed the driver from synaptics to mice. The previous log using synaptics also lacked the mieqEnequeue: out-of-order valuator event; dropping. in loop entry at the end. However the synaptics pointer moved on screen with pad movement of fingers.
I decided to add Option "BusType" "PCI" as suggested in this thread. I don't know yet if it will work. http://groups.google.de/group/linux.debian.bugs.dist/browse_thread/thread/901aa4e3b15c45bb/08fd10bf4452d646
Created attachment 292233 [details] With ... "PCI" - no help Instead of excessively trying items and reporting if they fail or not, I will google to see if there is something that works. Please feel free to suggest possible solutions. mieqEnequeue s still there
I'm seeing this exact issue as well. X is unusable for me in rawhide-20080121 which is slated to become the F9 alpha release. 01:00.0 VGA compatible controller: ATI Technologies Inc RV380 [Radeon X600 (PCIE )] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Unknown device 0b02
Created attachment 292460 [details] Xorg.0.log.old showing mieqEnequeue messages I'm not sure these symptoms are specifically related to the mieqEnequeue messages or not. Sometimes I don't get the messages, but the symptoms are the same--corrupted lines of graphics at the top inch or so of the screen, mouse cursor looks fine and moves fine, but nothing else appears on the screen (no gdm login window) and the console locks up otherwise. Cannot change VT. rhgb works fine though. These look interesting: i2c write: 0x8, 0x3b (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xa, 0xb0 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xc, 0x89 (EE) RADEON(0): Unable to write to DVO Slave 112.
Created attachment 292461 [details] Xorg.0.log, no mieqEnequeue messages, same symptoms This time I was able to "killall Xorg" from a remote SSH session. Usually that doesn't work--nothing restores the console but rebooting. No mieqEnequeue messages here, but the same symptoms. Same strange i2c write errors too: i2c write: 0x8, 0x3b (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xa, 0xb0 (EE) RADEON(0): Unable to write to DVO Slave 112. i2c write: 0xc, 0x89 (EE) RADEON(0): Unable to write to DVO Slave 112.
Created attachment 292462 [details] xorg.conf with radeon driver generated by anaconda BTW, I'm testing with: xorg-x11-drv-ati-6.7.196-7.fc9 gdm-2.21.5-1.fc9
Why not upgrade to 6.7.197 as this reportedly fixes the problem for the user in the google groups thread linked in comment #18 ? Do you have a test build of 6.7.197 I could try? Thanks.
Are you sure that part of the bug some may be seeing is related to this one? https://bugzilla.redhat.com/show_bug.cgi?id=428813
xorg-x11-drv-ati-6.7.196-6.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-ati'
Comment 25: It doesn't matter for the kernel version o get this problem. I run kernel-2.6.23.14-107.fc8 and kernel-2.6.24-0.157.rc8.fc9 and both show this problem. It would not depend upon bug 428813 in my observation. Regarding comment 26: The last time that I grabbed an ati driver from updates-testing it did not work for rawhide. The X server between F8 and rawhide are too different. Can we have a driver for rawhide? Regarding comment 18 - it did not work. No difference with the server was noticed.
This time also the xorg-x11-drv-ati-6.7.196-6.fc8.i386 driver failed to get a screen as expected running rawhide. I tried it since someone reported that the fc8 server version did not detect a screen. I hoped that by a far chance that it would work and was stuck in updates-testing by mistake. I then upgraded to xorg-x11-drv-ati-6.7.196-7.fc9.i386 and ended up with the same lockup described above. To see if bug 428813 has any relationship to this problem I will rename libdri to broken as comment twenty one shows in this bug report. The MODULE_DEVICE_TABLE could just as well influence this error.
Actually comment twenty-two. The path for it was different. mv /usr/lib/xorg/modules/extensions/libdri.so /usr/lib/xorg/modules/extensions/libdri_broken.so One line and then try to startx
Created attachment 292719 [details] renaming libdri.so as broken allowed X to start. Renaming libdri.so seemed to work for now. I'm sure that the libdri.so has something beneficial to the environment. Attached is with libdri.so listed as broken.
you are just disabling dri moving that file aside, so you have a DRI problem, leave that file alone and try Option "DRI" "off". the upstream fix is what I backported into this driver (back in comment #11) You could also try Option "AGPMode" "4"
Thanks for the options possible. The renaming of libdri.so to broken was just a test to see if X would come out without a loop. Comment #11 worked one time before rebooting. I never got it to work afterward. I'll try Option "AGPMode" "4" and Option "DRI" "off" and report back, libdri.so was restored to its proper name.
Created attachment 292725 [details] With options added to xorg.conf libdr.so not renamed to broken With a normal libdri.so present and with both Options added, I can boot without the server hanging. Thanks for relaying the proper options needed to negate the lockup. I hope to see dri functional soon though. I rebooted system fully into runlevel 5 and both gdm and gnome loaded successfully. I did not want a one time yes it is fixed again for this report.
Dave, this is most likely duplicate of bug 428813. Which one should be closed as duplicate?
The problem is not specifically related to the kernel. It is a problem with the driver and apparently DRI. The suggested options worked to prevent server lockup. I get the error with the f8 kernel as well as with the f9 kernel. Comment #7 puts the breakage after xorg-x11-drv-ati-6.7.196-2.fc9 - Comment #6 definitely is true and is a 6.7.195 version. Probably a sort of accumulative bug written by Dave that puts all of the pertinent information in order for a resolution to be made would be wise. Mike Harris did something along those lines for an i810 driver bug and it worked out pretty decent. The problem was more serious because it involved the screen not refreshing but was eventually fixed. The help with adding the two options to the xorg.conf file pretty much stops the X server locking up. How a fix can be applied for alpha and keep it for F9 is the most important goals. I don't think the kernel is that much of a factor since the driver change killed X for me and no specific kernel was involved. This bug can be marked as worked around but it is not a duplicate. I would like to add that in gdm before the driver totally locked up the background would only show the lower portion of the background image about 20% up the screen. The rest of the background space was black. GDM worked otherwise, X worked good enough to play DVD's and Google Earth worked better than I have ever experienced with the program. Now I don't think DVD paying or google earth would be very functional. I have not tested them though.
By suggesting closing this as a duplicate, I meant it is a duplicate in the organizational sense of the word -- Bugzilla is from our point of view primarily a tool for organization of our work; apparently this is a mess somewhere between xorg ati driver and kernel DRI stuff (with Mesa somewhere in the mix possibly as well), so this all will probably have to be fixed in cooperation of Dave, Kristian, and kernel folks, so it could be seen as one issue. In that sense (and only in that sense) I would see it as duplicate. But this is all Dave's call, so I can just comment here now.
I see this was added to bug 428703 so at least it will have priority for resolution. It does sound like a lot of possible interacting elements are contributing to this type of failure, I understand how you can consider it a duplicate as meaning related in symptoms but differ in cause.
Unfortunately, the final spins for the Alpha have been done, and this didn't make it, I don't think. Proposing this for a relnote.
Created attachment 294475 [details] Log for GNOME, no visible panel Trying with the latest released driver after commenting out the DRI option I tried to load gnome. The desktop showed no panels but the updates available pop-up screen launched. I still have the AGP entry in the file. In KDE, I see all the elements needed in order to file an update to this report. xorg-x11-drv-ati-6.7.197-1.fc9.i386 installed.
Created attachment 294476 [details] xorg log while in KDE At least it works. I don't know if a reboot will result in the same and what exactly the AGP parameter does.
After a reboot, the system still comes up. The Gnome problem seems to be gone also. Excerpt from current xorg.conf - I'll try without "AGPMode" "4" before closing report. The kernel being used is still from fc8, 2.6.23.14-107.fc8 Section "Device" Identifier "Videocard0" Driver "radeon" Option "AGPMode" "4" #Option "DRI" "off" # Option "BusType" "PCI"
Created attachment 294527 [details] With no special options in xorg.conf I removed all special options from the xorg.conf file and successfully loaded X and gnome. The texture of the background seemed to be a lot better and looked less flat. Closing bug as fixed by latest update to xorg-x11-drv-ati