From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; rv:0.8.1+) Gecko/20010429 I do not know if this is xscreensaver or X. About the time that the screensaver should kick the screen off, it hangs and leaves X unusable. SysRQ keys don't do crap, though I can get it to switch to another console and use shutdown -r now. Nothing else works. Reproducible: Always Steps to Reproduce: 1. Start X 2. Set Screensaver up (using gnome's control-center) to use APM 3. Sit and wait Actual Results: X becomes 'locked'. It is totally unusable and alt-ctrl-backspace doesn't kill it. Screen saver appears frozen, screen is on. Expected Results: Screen should turn off. After mouse move or keyboard event it should turn back on to the screensaver asking for my password. This happens on my system, and others I have talked to (some on LKM). It doesn't happen on my wife's. We are both using RedHat 7.1. Both have all good hardware (I have checked several times). Her computer uses the "nv" driver from XFree 4.0. Mine uses the "glint" driver. Mine does this with either APM, ACPI, or without both. It does seem to only happen with APM on. Her computer used to be mine and used the "glint" then. It seems the "nv" server doesn't have this problem but that "glint" and others do. I attached gdb to the X server and xscreensaver tonight to see what happened. X gets locked into a loop where all I see is signal actions with strace. If you move the mouse or hit a key you see a bit more... a few selects, gettimeofday, and thats about it. It is elapsing around 75% real time rate in ps x. About every 5 seconds it will say 3 to 4 seconds has elapased in ps x for process accounting time. xscreensaver under strace only shows select. It just sits there. gdb on both shows no crash. It should be noted several days ago I ran only strace -ff on xscreensaver and X. I only saw one thing of interest. SIGSEGV being delivered to xscreensaver or its child. Tonight, I didn't see any xscreensaver modules running after the 'lock' point. I only saw xscreensaver and X. I believe it is the actual screensaver modules that crash. It seems like nearly everyone does. This problem doesn't happen under 3.whatnot versions of XFree86 (under 7.0 or 7.1 this problem occurs with XFree 4.0 but not less than that). This also happens on any late 2.2.x kernel, through 2.3.x, on into any 2.4.x kernel I have tried. Final note: If X isn't the active virtual terminal, this crash doesn't happen no matter how long the computer is left inactive. At least here on my system.
Created attachment 16806 [details] Xfree86 log file
I too have seen similar problems on 2 different machines. One machine has a Permedia2 video card, the other a Matrox Mystic G450. The Permedia machine if left with the screensaver running overnight will be found locked up with some leftover garbage from the screensaver on the screen. Ctrl-Alt-Bksp and Ctrl-Alt-Del do nothing. I can ssh into the box just fine, but init 3 does nothing. Twice I've recovered this machine with init 6. Yes, a complete reboot just to kill X. This machine is being left logged in, but with xscreensaver disabled, overnight tonight. I'll post if it is found crashed or not tomorrow. The Matrox machine has been running fine for about a week until today. It was left on screensaver and I found it locked this afternoon. This time it wasn't garbage on the screen but a clear screen shot of when the screensaver died. Same thing with Ctrl-Alt-* and init as the Permedia2 machine.
The Permedia2 machine I mentioned above has run fine with no Xserver crashes no 2 days with xscreensaver disabled.
Your log shows that you use 1024x768x32bpp (>3Mb) on a 8Mb card. I think you also have DRI enabled. If so, you don't have enough memory to do so at this resolution/depth, since DRI requires a lot more memory and 3d-xscreensavers try to use that. Can you attach glxinfo output too? Anyway, try reducing resolution and/or color depth (to 16 bpp). Report the results.
DRI isn't supported in the glint driver anyway, so it should be disabled. Try disabling APM completely. I believe that this is likely an APM bug, and not an X bug.
Bill, what is your opinion on this?
Ok, first off, if the card is AGP and the kernel is compiled to use it, why isn't 8 meg enough? Second off, how can I disable DRI? Third, as requested glxinfo to follow. I will try it at 16 bit depth, but that is just crappy. Maybe it should be possible to use only normal screensavers? Also, why does it crash on non-3d screensavers if this is the problem?
Created attachment 17346 [details] glxinfo from T. Adams
As I tried to say in my bug report, I have tried it with both APM and ACPI turned off. I have tried it with either one (but never both) turned on in the kernel. Doesn't seem to make a difference. I will try to test again this weekend. The rest of the system is still around you know.
I think this is related, somehow. APM never puts the screen in suspend mode, even though I have it set in the gnomecc. This is on a Compaq deskpro EN, and can reproduce it on a Deskpro EP with a different graphics card. If, however, I use KDE instead of gnome, KDE starts the screensaver, and then the screen is put in suspend mode just like it should. Jeff Welty weltyj
I have the same problem. To reproduce it: xscreensaver-demo Demo "Laser" This locks X up fundamentally within 30 seconds. Yet other Demo's run for hours without a problem. I also noticed that the Demo 'Hypercube' leaves trash on the screen. And 'Halo' and 'Moire2' seem to 'blink' badly on the affected computer. This problem appears to be in the interface between XFree-4.0.3 and external drivers like XFree86-3DLabs-3.3.6. I cannot get the problem to manifest itself on either of my other systems (RH7.1) which use native XFree-4.0.3 drivers. I think that perhaps a screen writing call is off by a byte or word. When X "locks up" 'top' shows X at 98% CPU. The only fix I have found is 'shutdown -r -t 6 now' from an ssh login. I can kill other processes successfully, but I can't regain control of the screen or keyboard. Current system (with problems): RH7.1 XFree86-4.0.3-(5 and 15 from Rawhide) XFree86-3DLabs-3.3.6-35 AfterStep-1.8.8-3 xscreensaver-3.(29-3 and 32.1 from Rawhide) Just upgraded from: RH6.2 XFree86-3.3.6-20 XFree86-3DLabs-3.3.6-20 AfterStep-1.8.8-1 xscreensaver-3.28-2 xscreensaver-gl-3.28-2 Which I ran for over a year on this same computer, same color level, without a single problem in this area (thru many upgrades of AfterStep and xscreensaver).
Ok, back to this. APM on or off in Kernel or X or both (option "dpms" removed for off in X) does not make a difference from what I can tell. Color depth also doesn't seem to affect it.
kernel APM is *irrelevant* to DPMS.
notting You know, I did ask for information on exactly how you all wanted me to debug this. Having turned off APM and DPMS in the kernel and in X and having said that way at the beginning and still being told to try it, I can just say that your comments are rude and irrelevant. If what I say is some how bogus, then answer when I ask for help. Also, refer to mharris's comment above on why I said APM and referred to it.
I have rerun the test. With dpms turned off things do seem to be much better. However, you must also disable Flow and Laser screensavers or else it still crashes within 30 seconds (on my 800Mhz it is under 15) of them starting. This is why I reported dpms didn't make a difference. I find it odd that it is only particular to the glint driver in 4.0.x. I thought 4.0.x was supposed to have most of the code shared... or is dpms chipset specific? How can I help fix this?
I have done some more checking. The following screensavers are "bad actors": Distort, Hypercube, Hyperball, Halo, Moire2, Lightning, Laser, Penrose, Swirl, Vines, Flow, Squiral, XSpiroGraph, NerveRot (all forms), XRaySwarm. There may be others, but these definitely cause X lockups or screen scrambles. I have to retract the comments about native 4.03 vs. 3.3.6 drivers. I found an IBM laptop using native 4.03 drivers which displays this same problem.
The reason I mentioned kernel APM being irrelevant is that the DPMS hooks in X don't have anything to do with the kernel's APM settings; they're done completely independent of each other. (DPMS in X will kick on even if APM is disabled, etc.) It's certainly possible that the screensaver does something when it's enabled that screws up the X server, though.
notting, I appologize. The more I dig into this the more it seems to be the fault of the Xserver (sans those savers that crash it without doing into DPMS). In particular I think this is a problem with the glint driver in the Xserver. I am wondering if this problem still exists in the rawhide (4.1.x) Xserver. I cannot check myself as I have to keep my machine in sync with the one at work (and that is hard as we are currently moving from RedHat 6.1 to 7.1 and the decision was just made that we had to be able to develop at home - including making binaries to push). Also, other than that stated move at work, I would have time to look into the code for glint and see what is up, but ....
The problem described by nighthawk is still occuring in RedHat 7.2. I have used the majority of the screensavers in both KDE and Gnome. This problem seems to definately be related to Gnome. In KDE the screen will poweroff but will awake upon a simple movement of the mouse. I have left KDE running with a variety of screensavers overnight with no trouble. However, I have not had Gnome stay running overnight once yet. After the screensaver comes on it seems that when the monitor attempts to poweroff it is freezing X. No sequence of escape keys will unlock it. The only solution is to do a hard reboot.
Can you try XFree86 4.2.0 in Red Hat Linux 7.3 and provide a status update on this bug report?
I haven't yet seen this happen. But as I reported originally, only some of the screensaver modules seem to cause it. It was funny though, Ximian's version of xscreensaver on RedHat 7.2 didn't seem to barf as often or as hard. I will try this out for about a week and see what happens.
This is believed to possibly be a DRM bug which is common to all hardware. A fix is present in out latest rawhide kernel for testing. Once I've tested it well enough personally, I'll formalize it across all open screensaver/GL related bug reports, and co-relate them/dupe them closed hopefully.
Please test the latest rawhide X and kernel, and if the screensaver issue persists, please undupe/reopen. *** This bug has been marked as a duplicate of 73827 ***