re-assigning to x-screensaver package

Same problem to me. I even tried the Pinstripe kernel 2.2.16-22 - as successed
in another bug report - and the vanilla version with the latest prepatch #15
from Alan. With all three kernels, the X-screen gets frozen.

The machine is not absolutely dead, I can't switch over to a VC, but I can log
in via ssh from another host.

In the logs the following message appeared:
Oct 13 07:47:09 kahless kernel: [drm:drm_release] *ERROR* Process 863 dead,
freeing lock for context 1
Oct 13 08:34:20 kahless kernel: [drm:drm_release] *ERROR* Process 869 dead,
freeing lock for context 1
Oct 13 14:47:59 kahless kernel: [drm:drm_release] *ERROR* Process 2205 dead,
freeing lock for context 3
Oct 13 15:17:59 kahless kernel: [drm:drm_release] *ERROR* Process 2231 dead,
freeing lock for context 3
Oct 13 16:27:59 kahless kernel: [drm:drm_release] *ERROR* Process 2269 dead,
freeing lock for context 3
Oct 13 17:07:59 kahless kernel: [drm:drm_release] *ERROR* Process 2282 dead,
freeing lock for context 3
Oct 13 21:18:00 kahless kernel: [drm:drm_release] *ERROR* Process 2441 dead,
freeing lock for context 3
Oct 14 05:30:21 kahless kernel: [drm:drm_release] *ERROR* Process 1066 dead,
freeing lock for context 3
Oct 14 06:40:21 kahless kernel: [drm:drm_release] *ERROR* Process 1104 dead,
freeing lock for context 3
Oct 14 08:00:21 kahless kernel: [drm:drm_release] *ERROR* Process 1145 dead,
freeing lock for context 3
Oct 14 10:30:21 kahless kernel: [drm:drm_release] *ERROR* Process 1241 dead,
freeing lock for context 3
Oct 14 13:30:22 kahless kernel: [drm:drm_release] *ERROR* Process 1346 dead,
freeing lock for context 3
Oct 14 13:40:22 kahless kernel: [drm:drm_release] *ERROR* Process 1349 dead,
freeing lock for context 3
Oct 14 18:10:22 kahless kernel: [drm:drm_release] *ERROR* Process 1498 dead,
freeing lock for context 3
Oct 14 20:04:04 kahless kernel: [drm:drm_release] *ERROR* Process 1589 dead,
freeing lock for context 5
Oct 14 20:24:04 kahless kernel: [drm:drm_release] *ERROR* Process 1611 dead,
freeing lock for context 5
Oct 14 20:34:04 kahless kernel: [drm:drm_release] *ERROR* Process 1615 dead,
freeing lock for context 5

and so on. The time intervalls might be interessting...

Hardware of this machine: BX-chipset, Pentium III 800 MHz, 128 MByte RAM, ATI
Rage 128 RF
with r128 in XF86Config file. I suggest that the hardware accelaration within
the kernel freezes the xscreensaver process.

Andreas J. Bathe
merconic GmbH, Berlin

OK, it's a DRM problem. If you try the 2.2.18pre16 kernel,
does the situation improve?

Oops, re-read that. You did try 2.2.18pre15, correct?

Correct, I tried the 2.2.18pre15. Realized that the pre16 seems out since
Sunday. I will try the 2.2.18pre16.

Well, after testing 2.2.18pre16 and 2.2.18pre17 I might state that the
xscreensaver did not freeze again on these kernels. I will test the machine for
some days with the last pre-patch, but it seems that the bug went away although
the [drm:drm_release] *ERROR* still ocures in /var/log/messages.

Andreas J. Bathe
merconic GmbH, Berlin

I apparently am in the same situation.  I am also using the 2.2.16-22 kernel. 
Where can one of the newer kernels be obtained?

I'm running 2.4.0-test10 (final?) from kernel.org, and the problem occurs with
it as well.  I did notice that it only occurs when the screensaver is set to
random screensaver mode.  When I pick a particular screensaver instead, the
screen freezes don't happen.  (I don't claim to have tried them all, however.)

Reassigning to kernel ; this is an issue with the kernel DRM drivers.

I would suspect this has to do with hardware OpenGL support kicking in when a
random OGL screensaver is displayed.  The 3dfx drivers applied in 6.2 did the
same thing because the driver didn't switch out of OGL mode when the screensaver
exited.  The solution is to not use an OGL screensaver until more robust DRI
drivers for XFree86 4.0 are released.

Today two workstations froze again (one machine with stock rh kernel 2.2.16-22,
the other with 2.2.18pre17). The screensaver was sproingies and activated and
locked, they run until the users moved the mouse. Maybe this might help to track
down this dump bug...

Andreas

Most of the DRM drivers seem unable to be unloaded and then loaded again.
Now, the /etc/cron.d/kmod file specifies for unused modules to be unloaded
automatically.
Could any of you try (re)moving that file and then restarting crond and see if
that helps ?

I have the same bug that started after I upgraded to rh7.0. The box is stuck
with the screen saver frozen. I don't remember which screen saver was running
the first time but the last two times it happened the same screen saver was on
the screen. I think it was the 'Bubbles' saver. This happened in Gnome and KDE
both but hasn't happened since I turned off the random X screensavers. I am
going to try running the saver again with Bubbles disabled.

Forget about the bubbles theory. The problem still occurs with bubbles disabled.

I too have experienced this machine lock-up with 7.0, but never had these
problems with 6.2.  If it helps, the first few times the screensaver came up it
worked ok and let me back in.  After those first few times, it began locking up
the machine forcing a hard reboot as remote access did not work. It is a bit
frustrating to see that this bug was reported many months ago and has yet to be
resolved.

We're having this same problem in our testing lab.  So far, we've had this happen in 6.2 & 7.0 and every time it's been on the "rocks" screensaver.  Only 
seems to happen in random screensaver mode, however.  I ran "rocks" by itself and didn't get the problem.

The kernel DRM has had a very very very long time standing bug which
was just recently fixed which affected mainly OpenGL screensavers,
but could potentially affect any OpenGL software.  Due to the way
DRM locking was done, it was possible for a client to die with locking
held, and then cause the system to crash.

This is fixed in current rawhide, and will be in our next release.