Red Hat Bugzilla – Bug 57415
Blank screen on any logout or reset from KDE or Gnome
Last modified: 2007-04-18 12:38:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Description of problem:
If I boot the system to runlevel 5, I can log into KDE or Gnome, etc. and
the system works as expected. However, if I try to logout, shutdown (halt
or reset), or switch to a terminal mode session, the screen goes black and
requires a hard reset. If I start the system in runlevel3 and then
proceed with startx, the problem does not appear.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start linux in runlevel 5
2. Log into KDE/Gnome
3. Attempt to shutdown/logoff/switch to terminal mode
Actual Results: Screen goes black, requires hard reset
Expected Results: Should have successfully logged out/shutdown/gone to
Not sure about severity of this problem - does crash, but if it just the
difference in having to logon and use startx, not a big deal. Concern is
that something is wrong with X configuration or system, and that errors
might be introduced in future work on development for GUI programs.
Attempted to solve problem through Redhat email support - tech could only
suggest applying pam updates, which did not fix the problem. He then
suggested submitting problem here.
I have had a similar issue like this. I boot into runlevel-3, and I had a X
crash, which I was able to ssh into the machine, and kill off X. When I did, I
had a blank screen on the console, and I could type commands, and even start X
back up again. I'm not sure if you were able to do something similar, but I am
in the process off tracking down how to recover from that blank screen. I'm
guessing the video card got stuck in some mode that the monitor didn't
understand. I have a Matrox G400.
I posted a comment on Matrox's web forums about this issue, and received some
things to try.
1) add vga=normal to /etc/lilo.conf (rerun it of course, and reboot)
2) disable FB support in the kernel
FB support is experimental still, so that could likely be the culprit.
Not sure how to add vga=normal to grub.
Hope this helps the situation.
Thanks for the info, I set vga to normal in grub.conf, with no luck. I haven't
attempted the framebuffer fix yet (how would the fb work with level 3 and
startx, but not with level 5/xdm?), but have found some interesting additional
information. (btw, I have a Number Nine Iagine 128 Series 2 video card, NEC
MultiSync 5FG monitor, Pentium 166)
The crash will occur:
1) if I boot to runlevel 5, then any ctrl-alt-f commands, logout, or shutdown
2) if I boot to runlevel 3 then telinit 5 (same as 1)
3) if I boot to runlevel 3, then xdm. Now I have a second login screen (not
the same as with runlevel 5, telinit has no login screen, as Im logged in
already) I can use ctrl-alt-f* at this point. If I login to the xdm screen, I
can still function (ctrl-alt-f*). If I logout from that screen - I get the
initial xdm login screen again. If I ctrl-alt-f* now, crash. If I login, I
can successfully login, but any ctrl-alt-f* = crash.
The amazing part about this to me is that it is (so far anyway) always
reproducable. I have restarted, tried it on different days, etc., so there
seems to be something here, but not sure if this new info points directly to
Other posible points:
There are errors in some of the log files, and couldn't find anything about
in the XFree86.log file there are lines such as:
Symbol __glXMalloc from module (path)/libGLcore.a is unresolved
Symbol __glXFree from module (path)/libGLcore.a is unresolved
Not sure if this helps either...
You might want to attach your /etc/X11/XF86Conifg-4 file, and maybe someone
might spot something in your configuration.
I have added the vga=normal to /etc/lilo.conf and disabled the fb in the kernel,
so I guess I have to wait for X to crash before I can troubleshoot some more.
Can you do a Ctrl-Alt-+/- to try and force X to change resolutions when it
crashes, or does your whole machine lockup? (try and turn your num-lock on and
off, and if the light does not change, then you have a hard lockup) If you do
have a hard lockup, and you have "magic-SysRq" support:
# enable the magic-sysrq key
kernel.sysrq = 1
then, maybe you might be able to get the keybord back. For more information on
the "magic-sysrq", go here: /usr/src/linux/Documentation/sysrq.txt
Here is a nice explanation, too:
Notice that article explains that you should disable the fb, also, so that
This sounds like a VT switching problem which might actually be
a kernel console locking bug which has been fixed.
Please upgrade your kernel, and XFree86 to our latest erratum releases,
and update the bug report.
Does the new kernel, etc. solve the problem you've reported?
Not reproduceable in rawhide on any hardware I've tried.