Red Hat Bugzilla – Bug 138503
System freezes while it tries to switch from rhgb to gdm (Xorg)
Last modified: 2007-11-30 17:10:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
I had several problems with rhgb:
1. When the mountpoints have incorrectly been unmounted last shutdown,
rghb freezes while it's showing the label "Setting hostname".
2. When an USB mouse is connected, rhgb hangs at random locations.
Perhaps once you move the mouse for the first time?
3. WHen an USB mouse is not connected, rhgb hangs right before it's
going to switch to gdm (the X-server).
When 3 happens, I can still login using the network (ssh). It depends
whether or not the network is already loaded if I can login when 2
happens, of course. I can't login using the network when 1 happens.
When 3 happens and I logged in using the network, and I try to recover
the system using commands like init 3, init 5, etc etc .. it hangs the
complete system when the X server is going to get started. This means:
nomore network login. I think that the kernel has died or something.
When I disable rhgb, everything works normally.
This is a Acer Travelmate 8000 with a Radeon mobility 9600.
This is my xorg.conf file:
There was no second monitor attached during these tests/sessions
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Startup (with rhgb)
2. Wait for the system to get switched to gdm
1. Disable rhgb
2. Everything works
Actual Results: Keyboard and mouse are no longer responding. You can
still login but the complete system will hang if you try to restart
Expected Results: Even with rhgb, the system should boot
I've seen similar problems with a HP nx7010 laptop using:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf
[Radeon Mobility 9000 M9] (rev 01)
cp /etc/X11/xorg.conf to /etc/rhgb/ and disable DRI in the later,
then retry... I though DRI issues and multiple instance of X
had been taken care of both in recent rhgb and xorg.x11 packages
though, that should not crash.
I encountered this problem as well, with an ATI Radeon 9000 and a dual
display setup. If /etc/rhgb/xorg.conf is set up with a single head
layout the problem goes away.
Would a symbolic link [/etc/rhgb/xorg.conf] to [/etc/X11/xorg.conf]
introduce more problems if it where to be put in the rhgb-package? I
can imagine the problems one could be having with rhgb if his/hers
xorg.conf aint working.
If a small switch from graphical boot to console to graphical
loginscreen is needed, I don't really see the point in supporting
dualhead in rhgb. My idea about dualhead is that a lot current
dualhead configurations are known to cause hardware problems with
videocards if tampered with to much. I've had hardware-crashes with
radeon dualhead configurations after switching from console to X and
vica versa. For that reason I've always disliked the fact that rhgb
was indeed supporting dualhead (which I noticed because during the
boot I could move my mouse from one screen to the other).
I wonder whether or not it would be possible to bypass any switching
from rhgb to the X session used for gdm. What is so wrong with the X11
instance created for the bootup? Why shut it down and restart it for gdm?
So or your graphical setup fails and you boot in text, or your
graphical setup succeeds and once that X-server is started, it remains
running. Why not? (I don't see the reason for that one flikker from
graphical boot to console to graphical login-screen).
the symbolic link doesn't sound a good idea to me. rhgb will
use /etc/rhgb/xorg.conf only if the file is present, otherwise
it will let X use the default configuration file whatever it happens
to be. The symlink sounds like a recipe for a disaster.
The X11 created for the bootup cannot be reused because at the
moment it is started from a tempfs memory filesystem because x.org
need a filesystem mounted read-write to start and when rhgb start
you only have root mounted read-only available.
read /usr/share/doc/rhgb-xxx/HOW_IT_WORKS to try to get some basic
context needed before making suggestions.
copying the file to /etc/rhgb/ didn't solve the problem here. I can,
however, start multiple X instances and switch to them. I can shutdown
and restart X manually with no problems. But I can't bootup the system
using rhgb. It's crashing during the switch to the new X instance. The
last message I can see is about starting the HAL-deamon (in rhgb).
Oh wait, I can't switch to a console-window (nor can go back to X11).
It's very unstable. When I press alt+ctrl+f1 (for example), the
mouse/X11/keyboard freezes. When I use another host to login using
ssh, I can killall X and init 5 to get everything back to normal.
Note that I am using the radeon xorg driver as shipped with Fedora
Core 3 (I am not using a thirth party driver).
I am experiencing the same problem. I have an ATI Radeon 7000 dual
head configuration. rhgb-0.15.1-1.FC3 is installed.
Using the suggestion above of creating an /etc/rhgb/xorg.conf file
with a single head configuration has circumvented the problem for me.
I am also having this problem with a radeon 7500 and dual head.
Note that I also have a dualhead config. I assume that this is a bug
in the dualhead implementation for radeon? Switching from X to console
and back to X seems to hang the keyboard and mouse and the instances
Yes, I believe Philip is correct. I have just up2date'd and gotten
the rhgb-0.16.1-1.FC3 that was released today. It doesn't fix the
I have also completely removed rhgb from the grub.conf file and that
way, I can boot up and my dualhead X will start and will work, but if
I attempt to switch from X to console, the mouse/keyboard is
immediately hung. So, if rhgb isn't specified in grub.conf and
switching from X to the console still hangs the display/keyboard/mouse
(although I can still SSH in and -- can it really be rhgb that is
causing the problem?
I have in fact, ssh'd in, become root, and killed off gdm, it
restarts, but the display/mouse/keyboard is still hung tight, in fact
the gdm-binary has spawned off the /etc/X11/gdm/XKeepsCrashing script
to attempt to communicate with me, but the display is still stubornly
showing the same X display from when I attempted to switch to the console.
What other information would be helpful?
I have confirmed (at least for my manifestation of this problem) that
it is absolutely something in the dualhead support.
Having reconfigured (system-config-display) my system to not use dual
head support, I can boot up with rhgb and switch back and forth
between X and the console to my heart's content...
I did notice that when rhgb quit and X started up the first time that
both screens were behaving as the one (may be normal, dunno), but
after I switched to the console and back, only the one screen is
showing the X system (although the second screen is still getting a
signal of some sort because the light is green instead of orange).
Experiencing the exact same problem here. Default radeon driver, dual
head support causes rhgb to "hang". Even if I disable rhgb, using
CTRL-ALT-SHIFT-F1, for example to get a console, X will will become
unresponsive (still show the same window, but no mouse movement or
keyboard control), and attempting to switch back to X with ALT-F8 does
not work. CTRL-ALT-DELTE is still caught and reboots the system when
this occurs though.
If I reconfigure xorg.conf to only have one monitor, everything works
Since there is no working proprietary driver available from ATI for
the newer Xorg releases yet, I hope someone is able to figure out a
solution to this one.
If you can't switch from X to a text console and back, then
this is an xorg-x11 problem. The fact that recent rhgb runs
2 xservers at the last steps of the boot process is certainly
related to the problem you're seeing. It can only be fixed by
keeping the same X server from boot to the user session and
that will require a lot of changes on both side, so don't expect a
quick fix for this.
*** Bug 139797 has been marked as a duplicate of this bug. ***
For now, as a quickfix, I'd try to make sure that the rhgb xorg.conf
file ain't trying to support dualhead configurations (and that there
is one, in stead of using the xorg-generated config). I suppose this
can easily be done by a script that checks whether or not there's two
Device sections and/or the ServerLayout section is talking about
In which case a text-dialogbox-warning could explain the problem (and
if applicible to the situation of the user, how to get rid of it
--perhaps some button that will revert the /etc/rhgb/xorg.conf to a
standard non-dualhead setup--).
I can imagine the frustration many (non investigative) users are
having at this moment :-(
It's not just rhgb. I've turned that off (which at least lets me boot
properly), but switching to a text console is still unavailable and
appears to "lock" the system (not really, since CTRL-ALT-DELETE still
responds, but nothing is viewable on X except for the last viewed
screen with no mouse).
Definately an x.org problem with the radeon driver in dual head in my
opinion, but I haven't had a chance after the freedesktop.org lists
came back online to see if they have acknowledged the problem yet.
The bug should probably be switched to x.org instead so we can get the
proper maintainer on this one.
If this does get turned into a "xorg locks up when switching to text console"
bug, please can someone also look at bug 141500 which is reporting the same thing
I also have the problem of FC3 screen locking up when rhgb is enabled
(ctrl-alt-f1 does not work either). This (old) system operated
correctly under FC2. When I loaded FC3, I erased all partitions and
loaded all packages.
1) If I edit /etc/inittab to boot into run level 3, boot, and then
manually do a /sbin/init 5, it works correctly.
2) If I remove "rhgb quiet" from /boot/grub/grub.conf, it works correctly.
model name : Celeron (Mendocino)
cpu MHz : 334.159
VendorName "Videocard vendor"
BoardName "Matrox Millennium G200"
This old card only supports one monitor.
Comment #20: Are you saying that if you start in run level 3 and then
switch to run level 5 and do not have rhgb running that you are then
able to successfully switch (via CTRL-ALT-F1) between the console and
the XWindows display?
Comment #21: I'm not sure whether or not in Mike Potts situation this
works. In my situation, however, it ain't working. I can also startup
an XServer manually (for example as root) using startx, switching to
the console while the server remains running will make the system
Killing the server or doing ALT-CTRL-BACKSPACE will, however, drop me
successfully into the console. My situation is the ATI Radeon 9600
with the Acer TravelMate 8000 laptop. Using the default (with Fedora
Core 3 shipped) radeon drivers (not the one which ATI is distributing,
Comment #20 / Comment #21 : Oops. Either 1 OR 2 will fix this problem,
I do not need to do both.
Those of us with dual-heads still have the problem even after 1 AND/OR
2 in #20.
Even with rhgb completely disabled and starting from runlevel 3 and
bringing up X, switching to the console will cause the X display to
freeze. ALT-F8 from the "unviewable console" doesn't bring it back
either, and CTRL-ALT-SHIFT-BACKSPACE is unresponsive, though
CTRL-ALT-DELETE still starts up runlevel 6 like it should.
I also had the same problem, though I do not have a dual head graphics
I configured GDM to serve XDMCP and decided not to have any local X
Server run to save memory.
Configuration in gdm.conf which caused the problem:
After I did this, X would freeze after the HAL service has
successfully started (sshd worked).
If I set the X server to run (ie. 0=Standard default configuration)
the problem would go away.
I presume there is some problem switching between the X session for
boot (RHGB) and the new GDM process.
I disabled GRAPHICS in /etc/sysconfig/init and all works fine now.
Some more information...
I've posted some comments over on bug 140435 and been looking into
this on my Dell D600 with Radeon Mobility 9000 controller.
I tried disabling DRI - no help, no joy.
Tried disabling hardware acceleration. Problem eliminated. Graphics
speeds (especially switching desktops or scrolling Mozilla) sucks, but
I can now switch between X server instantiations on different VCs or
switch to a terminal mode VC. Looks like the problem may be related
to hardware acceleration with the dual head modes.
I added this to the "Device" sections (Driver "radeon"):
Option "NoAccel" "on"
Now it works. Comment it out and restart X and X once again freezes
if you try and switch away from an instantiation in a dual head mode.
This issue also exists when you are running only one screen. My
system freezes at any resolution above 640x480 with a Radeon 7000.
Any updates on this issue?
If i set it at 8bit color the login screen does come up at 1024x768,
however during the gnome desktop startup it goes back to 640x480.
Created attachment 109704 [details]
Xorg log file
I have the same issue with Ctl+Alt+F1 but only when using Xinerama. Since I
didn't see anyone else post their xorg log files, here's mine which clearly
shows a problem with the radeon driver resetting over and over when I do this.
X apparently freezing up is that it's using 100% of the CPU when this happens.
Please upgrade to xorg-x11-6.8.2 from fc3-testing, reboot your system to
cause a full hardware reset cycle to occur, then try to reproduce the
problem initially reported. After doing this:
To the original bug reporter:
(and anyone else experiencing the 100% exact same issue reported in the
initial comment. All other issues reported by other people here, may
be completely unrelated bugs. We will focus our efforts here on the
bug initially being reported.)
Does disabling DRI by commenting out the Load "dri" part in the xorg.conf
allow X to load after rebooting?
If you disable acceleration by adding Option "noaccel" to the device
section of the xorg.conf, does the problem go away after rebooting?
To all other people who have added comments about possibly similar issues:
If you are not experiencing the *exact* same issue reported by the original
bug reporter, please file your own new bug report(s) to track the issues
you are having. If it turns out it is the same issue later on, we can
then resolve them as duplicates, however if they are different issues,
when this bug gets closed, your problems may just get lost.
I also very strongly recommend reporting the problems directly to X.Org using
the freedesktop bugzilla, as this will maximize the number of X.org developers
who see the issue, which may lead to a faster fix:
http://bugs.freedesktop.org in the "xorg" component.
Once you've reported the issue in X.Org bugzilla, paste the bug URL here
and we will track the issue there as well.
Thanks in advance.
Setting status to "NEEDINFO", awaiting status update from using 6.8.2 and
testing with information in comment #30 above.
Having installed the 6.8.2 version from fc3-test, I will report that using rhgb
no longer hangs my dual headed system. I can also use the Ctrl-Alt-F1
combination to switch from X11 back to the console. However, when I switch back
to X11 (using the Alt-F7 combination), the second display is not refreshed. I
have to log out of X and log back in to get the second display to work properly
commenting out the 'load "dri"' line and restarting the X server (kill -1) did
not change this new behavior.
Adding 'Option "NoAccel"' to the two device sections that describe the two
screens made no difference.
Commenting out the load dir and having the NoAccel option set for both screens
made no difference.
So, the rhgb problem is fixed for me. However, there are still problems with
dual head support on the Radeon card.
Frank: Thanks for the update. Please report the new bug you're
experiencing in a new bug report in X.Org bugzilla at http://bugs.freedesktop.org
in the "xorg" component, with the full details, and attach your X server log
and config file to the bug report. If you file a tracking bug in our
bugzilla and paste the URL to the X.Org bug report in the tracking bug,
we'll track it in the upstream bugzilla as well. That will maximize
the number of eyes on the problem, and expediate a resolution.
Thanks in advance.
Setting status to "RAWHIDE", although a new errata for FC3 will be out in
the next week roughly with this as well. Please reopen the bug if the
original problem recurs, and we'll reinvestigate.
Thanks again everyone!