I have recently installed RH 7.0 and the something is wrong with the screen saver. Twice I have returned to my office to see the screen saver frozen. The system doesn't respond at all. I have to do a hard reboot to get back. This is running under Gnome.
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.