Bug 427000
Description
Jim Cornette
2007-12-29 20:24:12 UTC
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
|