From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; rv:0.8.1+)
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.
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
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.
I have the same problem. To reproduce it:
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):
XFree86-4.0.3-(5 and 15 from Rawhide)
xscreensaver-3.(29-3 and 32.1 from Rawhide)
Just upgraded from:
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.
firstname.lastname@example.org 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 email@example.com'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.
firstname.lastname@example.org, 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 email@example.com 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 ***