Red Hat Bugzilla – Bug 161463
X locks up on SuperSavage IX/C when loggin out from GNOME
Last modified: 2007-11-30 17:11:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Epiphany/1.6.1
Description of problem:
When logging out from a GNOME session, X locks up frequently regardless of shutdown, reboot or logout option being chosen. The computer is completely unresponsive at this point. Typing "ctrl-alt-del" or "ctrl-alt-bspc" has no effect. The machine - an IBM Thinkpad T23 - needs to be powered off.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log in to GNOME.
2. Log out.
Actual Results: A colourful pattern of vertical stripes gets displayed, sometimes the display is just black.
Expected Results: The GDM login panel should appear or the machine should shut down/reboot according to the user's selection.
Adding the device option "ShadowStatus" "true" to xorg.conf appears to be a remedy to this problem. There might be a connection to the fact that DRI is disabled by default for the "savage" driver.
(In reply to comment #0)
> From Bugzilla Helper:
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513
> Description of problem:
> When logging out from a GNOME session, X locks up frequently regardless of
> shutdown, reboot or logout option being chosen. The computer is completely
> unresponsive at this point. Typing "ctrl-alt-del" or "ctrl-alt-bspc" has no
> effect. The machine - an IBM Thinkpad T23 - needs to be powered off.
Please have a look at bug #161242 which is a probable cause for this problem,
and test the workaround there and provide feedback as to wether it works
around the problem.
> Additional info:
> Adding the device option "ShadowStatus" "true" to xorg.conf appears to be
> a remedy to this problem.
If my suggestion above doesn't solve the problem with this option disabled,
then it is probably a Savage specific issue. I'll wait for you to test
the above first though. Please attach your X server log and config file
to the report as individual uncompressed file attachments.
> There might be a connection to the fact that DRI is disabled by default
> for the "savage" driver.
Nope, there is no connection. DRI is not and has never been supported
on Savage hardware by X.Org X11 or XFree86 in any official release to
date. Experimental support for DRI on Savage hardware exists in CVS,
but is disabled by default due to security issues and instability the
last time I checked.
DRI (or lack therof) is definitely not involved with the problem you're
Hope this helps.
Substituting "libvgahw.a" by the original FC3 (update) version provided at your
FTP directory changes the behaviour in a way that now the Mondrian like patterns
on the text console are black and white only. The weird thing is that even
setting the X driver to "vesa" does not cure the problem. Sometimes the system
already hangs after the graphical boot when switching to X. I finally also
managed to achieve X lock-ups when "ShadowStatus" is enabled. I thus need to
correct myself in this respect.
I have not been able to reproduce the lock-ups with alternative OS or various
live CDs, so a hardware problem is not very likely.
Created attachment 116320 [details]
IBM Thinkpad T23 vesa driver xorg.conf
Created attachment 116321 [details]
IBM Thinkpad T23 vesa driver Xorg.0.log
Upgrading to xorg-x11-220.127.116.11-3 allows to get rid of these annoying
lock-ups - even with DRI being disabled/broken ;)
Your problem should be fixed in xorg-x11-6.8.2-44.
Can you give it a try?
After DRI problems with a customized xorg-x11-18.104.22.168-3, I reinstalled
FC4 from scratch and installed all available updates as of July 31st in
a first step. Already in this configuration featuring xorg-x11-6.8.2-37,
the system was stable again. xorg-x11-6.8.2-44 needs a different GLIBC
version than the one provided by FC4 and I did refrain from rebuilding
the binary packages. However, in the short time before upgrading to
xorg-x11-22.214.171.124-0.homebrewn, no lock-ups were observed for the current
FC4 update RPMs anymore. It looks like the responsible bug that had caused
the problem got ironed out in the meantime ("SELinux" is the principal
suspect). It is not the first time, that successive updates do not lead
to the same result for me as the full install of an updated distribution.
Currently, my experimental xorg-x11-126.96.36.199 server works flawlessly.
Even direct rendering works correctly albeit delivering a fairly modest
3D performance. Thanks for your comment!
Since even the reporter cannot reproduce his own bug, I'm closing this report.
Joachim, if you happen to have the problem again, fell free to reopen it.
Also, note that an FC4 update is now available (6.8.2-37.FC4.45).
For a fully updated FC4 keeping the original "xorg-x11-6.8.2-31", the system
definitely hangs frequently. I have rechecked this recently. Only after
replacing "libvgahw.a" by the FC3 (updates) version, the system seems to behave
normally. For "xorg-x11-6.8.2-37" and later, this tweak is not required anymore.
My original report both covered "xorg-x11-6.8.2-31" and "xorg-x11-6.8.2-37". Bug
status hence changed to "errata".