Hide Forgot
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): How reproducible: Always 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 terminal mode Additional info: 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 anything. Other posible points: There are errors in some of the log files, and couldn't find anything about them online: 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: /etc/sysctl.conf: # 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: http://www.linuxgazette.com/issue51/tag/4.html Notice that article explains that you should disable the fb, also, so that *might* help. Good luck!
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.