Bug 57415

Summary:	Blank screen on any logout or reset from KDE or Gnome
Product:	[Retired] Red Hat Linux	Reporter:	paul <ptczerni>
Component:	XFree86	Assignee:	Mike A. Harris <mharris>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2	CC:	bruce
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-02-09 20:02:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description paul 2001-12-11 23:21:17 UTC

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.

Comment 1 Bruce Garlock 2001-12-13 11:41:29 UTC

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.

Comment 2 Bruce Garlock 2001-12-13 16:17:03 UTC

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.

Comment 3 paul 2001-12-14 22:33:03 UTC

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...

Comment 4 Bruce Garlock 2001-12-14 23:05:11 UTC

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!

Comment 5 Mike A. Harris 2002-01-24 23:43:21 UTC

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.

Comment 6 Mike A. Harris 2002-02-09 20:02:38 UTC

Does the new kernel, etc. solve the problem you've reported?

Comment 7 Mike A. Harris 2002-07-30 02:01:04 UTC

Not reproduceable in rawhide on any hardware I've tried.