Hide Forgot
Under Redhat 5.2, XFree86-3.3.3.1-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 tried changing kill(d->servpid, SIGHUP); to XCloseDisplay(d->dsp); 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 terminal window. 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. Any suggestions/help?? Thanks. ------- Additional Comments From 09/03/99 09:07 ------- I have had this exact problem with a Virge VX 4MB card using rpm XFree86-S3V-3.3.3.1-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.