Under Redhat 5.2, XFree86-184.108.40.206-1, the X server will
sometimes (maybe one time in ten) crash upon a server
reset. Hardware is an S3 Virge DX with 2MB ram, running in
1024x768 16bpp. Kernel 2.2.7, SMP system. The X server is
otherwise extremely stable through starting, stopping, and
heavy vc switching.
This manifests when gdm resets the display after a logout.
Normally, after logout, the running X server is killed
(screen goes blank), a new X server is started (screen shows
default X background with an X cursor), the new X server is
reset (screen goes blank, screen comes back) and then the
Init/Default and the greeter are run.
When the bug decides to happen, the system does not recover
when the new X server is reset. The graphics mode is there,
as my monitor reports a proper sync, but the screen remains
blank. Occasionally, the screen will show blue vertical
lines from top to bottom; this is rare though. The keyboard
is totally dead. I have not had the oppurtunity to test a
network connection. After waiting for a reasonable amount
of time then hitting the reset switch, the fsck at boot has
on two occasions shown some fs damage (stuff ends up in
/lost+found) of recently-modified files; this may imply that
the crash is pretty hard.
Diving into the source, around line 200 in gdmserver.c, it
does this reset by sending a HUP signal to the X server.
The comment suggests that XCloseDisplay could be used, so I
but the crash still happens (though it seems, _perhaps_, to
happen less often; only once so far). Removing this line
entirely, as you would expect, prevents crashes but messes
gdm up pretty badly.
Thanks, let me know if you need more information.
Just upgraded to RH6, and the problem persists. It is almost certain
that the source change of using XCloseDisplay instead of a HUP signal
reduces the number of crashes. With the source change under RH6, it
has not yet occured but I believe it eventually will.
This issue has been forwarded to a developer for further action.
*** Bug 4132 has been marked as a duplicate of this bug. ***
This lock up happens 100% of the time when I select a screen
saver called 'Halo' under Gnome's desktop settings.
This lock up also happens occasionally when I reposition my
However, when the colour is reduced from 16b to 8b (YUCKS!)
everything works fine.
If I want 16b colour, I have to make do with 87Hz Interlaced
mode for my monitor (YUCKS!).
I have a monitor capable of doing 1600x1200@70Hz NI.
------- Additional Comments From 09/03/99 09:07 -------
I have had this exact problem with a Virge VX 4MB card using rpm
XFree86-S3V-220.127.116.11-52 and earlier. I switched from using gdm to kdm
and thought the problem had gone away, but my machine just locked up
as I was logging out and kdm was grabbing control of the console
again. This time the screen was covered with all sorts of random color
stripes. I seem to have better results if I kill my X server
(ctrl-alt-bksp) rather than logging out of KDE gracefully.
Several fixes for Virge cards were made in XFree86 3.3.4/3.3.5.
Please re-open this bug if you continue to have crashes with the new
XFree86 packages which are available as errata.
This seems to be a very persistent bug in the S3V server. I can report to have
seen it happen frequently on two entirely different linux boxes whose only point
in common is the S3Virge graphics card. Typical phenomenon is a screen with
vertical stripes, ususally blue and reddish, after logging out from X. Seems to
completely lock up the machine, as for instance terminals logged in on a serial
port are dead as well; I guess the kernel really hangs. One can still use the
reset button (but not a keyboard chord reset), and that's about all that still
works. Oh yes, if you are playing an audio CD to the sound card, that still goes
on (but that also is the case on a shutdown without poweroff, so I assume it
bypasses the CPU altogether). By the way, I always just use xdm. I hoped it
would go away in an update of the X server, but alas, I've had it happen with
XFree86-S3V-3.3.5-3.i386.rpm as well. Because of this problem I don't actually
log out from X very often; I prefer to start multiple X screens, and at the end
kill them all by doing a reboot. The latter procedure has never crashed the
machine; this might help locating where the crash really happens.