Added Comment -
I haven't seen anything in the logs to indicate what it might be (I looked- it
all looked normal to me, and then the new boot messages from my reboot), but
before I go to bet- I'll turn xscreensaver back on, and have a cli script
echoing the time to a log file.

Theoretically that will make it easy for me to identify exactly where to look in
the logs beyond question (I assume that if the machine is not even pingable that
it has crashed and any script will die)

--Could the gnome crash bug that is being reported really be this?

Probably an issue with the DRI/DRM drivers.

The system didn't crash on me - but it did dump me down back into console.

I went out for a bit - here are the messages that are relevant:

*blah about modprobe and sound-slot*
Nov 14 13:40:33 mpetershomenetwork modprobe: modprobe: Can't locate module
sound-slot-0
Nov 14 13:40:34 mpetershomenetwork modprobe: modprobe: Can't locate module
sound-service-0-3
Nov 14 20:52:51 mpetershomenetwork gconfd (mpeters-3178): Received signal 1,
shutting down cleanly
Nov 14 20:52:59 mpetershomenetwork gconfd (mpeters-3178): Exiting
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): starting (version
1.2.1), pid 18746 user 'mpeters'
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readwrite:/home/mpeters/.gconf" to a writable config source at position 1
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2
Nov 14 21:32:36 mpetershomenetwork xinetd[18749]: warning: can't get client
address: Transport endpoint is not connected
Nov 14 21:32:57 mpetershomenetwork su(pam_unix)[18782]: session opened for user
root by (uid=999)

-=-
At 20:52 when gconf-d exited I wasn't home.
At 9:32 when gconf-d started is when I found myself in console and started X.

I don't know if this is the same bug, but if it is- then it is a local physical
security issue, as the screensaver requires a password to exit but this dumped
me into the console I started X from.

note - when I said 9:32 read 21:32 ;)

It's crashed twice for me now - not just X shutting down - nothing about gconf-d
in the logs on the hard crashes.

So I don't know if the gconf-d problem where X abnormally exits and the hard
crash are the same thing.

For now I'll just be patient and not run xscreensaver and hope Red Hat 8.1 (the
.1 releases are always better) will make it all better.

I don't know if it is related, but I have a similar problem with a laptop.

The chipset is an I 830M

When a screensaver using OpenGL is started, the display first freeze (does not
even respond to CTRL-Alt-Del), but still respond to network : a kill of the 
screensaver or the X server does not solve the problem.  Eventualy, the system
freeze completely and does not even respond to network.

The same thing happen with an other OpenGL application such as "tuxracer".
I usualy use the Gnome desktop, and did not try with an other environment.

This problem did not happen with RH 7.3, and does not happen on other hardware 
(ATI radeon, for example).

Dear Ladies & Gentlemen: 
The Red Hat 9.0 OS locks up if the screensaver is on after a certain length of
time.   A guess is fifteen (15) minutes.   I did not load KDE when I loaded Red
Hat 8.0.  Some time (a few days) After Red Hat 9.0 was installed, I finally
managed to install KDE (I have not yet figured out how to "restart" KDE - I am a
mouse 'point and click' user, not a programmer).  
The screen did show the following message (yellow on a black background):
xscreensaver: 10:51:48: -1: unrecognized client message :NET_WM-STATE" received
xscreensaver: 10:51:47: -1: for window 0x4009bc ((null)/(null))
The two lines above were repeated once (as typed above).
Please tell me how to fix this opportunity (point and click). 
Martin J. Kehoe 
From: mjkehoe

This bug was opened by me.
I'm not sure what the problem other people are having, but mine was a bad cpu,
and not a bug with Red Hat. I know this because when the cpu abruptly died - I
used the same hard drive in a different box w/ via chipset and same rating cpu
and same video card and there were no problems ever again.

I'm guessing that other people with this problem should try to run memtest86 for
several hours (start it before you go to bed) - as memtest86 will likely have
errors if the problems if the cpu and/or ram has problems.

I really recommend this - with me, I only had problems in XScreensaver at first
- for weeks, everything else was fine. Then occasionally I would get I/O errors
when compiling. But rarely. Then oggenc would occasionally core dump and
occasionally lock the system. Then one day the system would not boot at all.

So if you have a problem with XScreensaver - while it might be a bug, I would
recommend running a diagnostic like memtest86 for awhile to make sure its not
hardware.

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/