Red Hat Bugzilla – Bug 446395
X11 crashes when restarted
Last modified: 2009-07-14 13:40:42 EDT
Description of problem:
There seems to be a generic problem with X crashing when it is restarted. I
noticed this because gdm was crashing, and there are gdm bug reports which seem
to be related to this, but it seems to be a more generic problem
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Start an X server
2.Stop the X server
3.Start another one.
Screen freezes. Computer is non-responsive. Can't switch to virtual terminal,
can't kill X with Ctrl+Alt+Backspace
X starts again.
I first noticed this as gdm crashing on startup. If I started in runlevel 3 and
started gdm it worked. If I started in rl3 and did telinit 5 it worked. If
however I did telinit 5, telinit 3, telinit 5 then the machine would freeze the
second time. Other similar bugs have been reported (BZ#446307, BZ#446706).
I also found that if I took out rhgb then gdm wouldn't crash when starting. I
also found that if I started in runlevel 3 then I could do startx and it would
work, but if I logged out of that session and did startx again it would freeze.
The only errors I've seen have been in the gdm logs, the X11 logs don't (to my
eyes) show anything unusual, but I'll attach them all.
From what I've seen the reports which show similar symptoms to this have all
been nvidia hardware (as is my machine).
I've tried wiping out my xorg.conf and reverting to the original gdm custom.conf
file but with no improvement.
Created attachment 305358 [details]
Xorg log file
Created attachment 305359 [details]
GDM greeter log
Created attachment 305360 [details]
X log from gdm
error setting MTRR (base = 0xd8000000, size = 0x08000000, type = 1) Invalid
..which is the only error I've been able to find. If it's any help then
reg00: base=0x00000000 ( 0MB), size=65536MB: write-back, count=1
reg01: base=0xd7f00000 (3455MB), size= 1MB: uncachable, count=1
reg02: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
reg03: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
Another potentially useful bit of info is that when the machine freezes it seems
it's not just X which dies. It's not responsive to pings, and if I have an
active ssh session open it hangs. If I'm running top the last active process I
see is init (when I do init 5 to cause the hang).
Created attachment 305462 [details]
Log file from 2 consecutive runs of startx
This log shows 2 runs of startx, the first of which succeeds and the second of
which hangs, it was captured from an external connection so hopefully should be
I've also found that if I switch back to VC1 after issuing startx I can start
and stop it as many times as I like so long as I don't allow the display to
switch to the X-session. As soon as I switch to VC7 the machine immediately
This might be related that I even in FC8 hasn't been able to get the nvidia 3D
drivers to work - see http://www.nvnews.net/vbulletin/showthread.php?t=104229.
The crash reported in this thread have identical, unpleasant symptoms.
Cross-referencing: Possibly related to bug 446346.
I think the severity of this bug should be increased - it's actually a crash
requiring a reboot, which IMHO should be at least "high"
Although there may be some relation to the F8 problem, my machine was running F8
just fine before I upgraded, and had been doing so with both the nv and nvidia
I've tried some other drivers for my machine with mixed results.
Using the framebuffer caused the same crashes as with nv.
Using the nouveau driver I can get X to be stable as long as I only use 800x600
resolution. Above that I get the same freezes as with nv. I tried reducing the
resolution with nv but it still froze.
*** Bug 446346 has been marked as a duplicate of this bug. ***
This bug should probably be moved out of the nv driver section, since although
it's only been reported against (I think) Nvidia hardware on x86_64 I can
reproduce the crash using either the framebuffer or vesa drivers as well.
After updating (right now!) this seems to be fixed for me, I can do a init
3/init 5 cycle without any problems.
I've just done an update and my machine still crashes on the second launch of an
X server in a session.
I didn't have any xorg packages in the update though. Can you post a list of
the packages which were updated in order to fix this on your system please.
Certainly, if I just had any idea to get the list. I guess it's possible to make
an rpm query like "list all packages including some kind of date" and sort it -
but I don't know how to do it. Amy hint out there?
..list everything since the last time you know it failed.
Created attachment 306358 [details]
What's updated since last crash. Besides this, I have also messed around with
the startup priorities to resolve a hald issue, see bug 443602
Looking down the list I don't see anything significantly different to what I
have. You don't seem to have any updates I don't have.
Also, the only thing on that list which seems related to X is the
mesa-libGL-7.1-0.29.fc9.i386, and I have mesa-libGL installed already.
I also tried resetting the priorities as per your other bug even though my HAL
was OK - that didn't have any effect.
I thought I'd made some progress with this, but now I'm not sure.
I noticed that on the second launch of X it didn't die straight away. The
hatched screen with the X cursor appeared and it was only after the window
manager launched that it died.
I'd also forgotten that this machine has a soundcard (which is never used).
When I turned the speakers on I found that the X session died as soon as the
startup sound started to play (so that the sound got stuck in a look).
I've tried disabling sound all together but it still crashes on the second launch.
I've also tried just running twm. On the second launch of X this will start and
stay responsive, but as soon as you click the mouse to bring up the twm menu
then the whole system locks up. It seems therefore that there's something about
the first program to run under X which kills it, rather than the launching of X
Just to narrow this down to X I tried running from runlevel 1 and the crash
still happened, so I don't think it can be any of the accessory services, it
must be X itself.
Sorry to say, but I was wrong thinking the bug was gone. I was fooled by the
fact that the first init3/init5 cycle after a reboot succeeds (this might very
well have been the situation since the beginning). However, a new init3/init5
sequence still exhibits the bug. :-(
As I stated earlier, I have a running kernel and virtual terminals after the
bug. If anyone wants to propose something meaningful to do e. g., with gdb I'm
willing to try. For the moment, I have no idea what to look for, though.
I've just tried the newly released proprietary nvidia drivers (the Livna bundle)
on this machine and X works as it should again. I'd still like to be able to
get this to work with the free drivers, but for now at least I've got a workround.
I have tried installing the livna drivers, and the bug is still there. Have
tried 1.5's new autoconfiguration, limiting the xorg.conf to a single "driver:
nvidia" option, but it's still the same.
Using the nvidia package I can also provoke a bug just by starting glxgears -
this tosses the machine into a completely unresponsive state roughly a second
after the glxgears window is started.
Had a glance at dmesg and /var/log/gdm/0:log, but everything looks fine there.
Using nvidia-settings to disable-all state gives same result.
This is just so strange...
Upgraded another box with nvidia graphics to FC9. This box does not exhibit this
bug. So it's either something with the sw configuration on my and possibly
Simon's computer, or the specific hw in use.
My failing card is a nVidia NV43[ GeForce 6600GT] according to hwbrowser.
I too doubt that this is a very widespread issue otherwise there would have been
a lot more shouting about it.
My card is an nVidia NV43GL Quadro FX 550 (rev 2a).
Other things which might be relevant
4Gb memory (may be relevant since I'm getting MTRR errors)
I have 2G of ram and no MTRR errors.
Updated to today's state hoping things would improve. They don't.
Digging a little more. There is a pulseaudio related process gconf-helper which
is dead (zombie) when the login screen hangs. This process is up & running when
the login greeter works.
I have a bridged network configuration. After upgrade to F-9 this refuses to
restart cleanly, basically there are no network connections when going from rc3
to rc5. This might very well be the root cause, and another issue which needs to
be resolved. Stay tuned.
Found a walkaround for the network restart issue, see bug 450389. With this
fix, init 3 /init 5 now works as expected.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.