Description of problem: How reproducible: a bug that forces me to reboot my server really gets my goat. i lock the server with xscreensaver to keep the kids from wreaking havoc on it. numerous times/week xscreensaver freezes, either by itself, or when hitting a key. usually i can get going (via ssh) by killing xscreensaver or just its subprocess, but often X dies, sometimes the virtual terminal remains frozen, and sometimes even chvt can't free the console, leaving me no option but reboot. when X dies, that's either an X or a kernel problem, you can't just blame that on xscreensaver. a stuck console also implies bugs in the kernel console and/or virtual terminal handlers. this was happening before, but now seems to happen more often with, the latest xorg packages. after killing xscreensaver and/or the current xscreensaver subprocess, sometimes merely ctl-alt-keypad-/ or ctl-alt-keypad-* will free it up. meanwhile chvt (via ssh) will sometimes be able to switch away from the frozen session, and sometimes not. sometimes the chvt will finally complete after xscreensaver is finally killed. often X will die, either right when xscreensaver is killed, or perhaps not until receiving its next keystroke. and sometimes after X has died, the virtual terminal it was running in remains frozen, such that the next X session lands in a new different virtual terminal, and if by habit i switch to the stuck vt the keyboard is again dead to any further virtual terminal switching, requiring to resort to chvt via ssh again. but interestingly, after a subsequent similar X death, the erstwhile frozen virtual terminal may once again be responsive and host the next X session. today the xscreensaver processes are gone after a mere kill, but, not as per usual, chvt remains hung, with the frozen xscreensaver image still showing, X wouldn't die with ctl-alt-backspace but remained stuck in a loop: Cpu(s): 1.0% us, 99.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si PID nFLT SHR VIRT SWAP RES %MEM TIME %CPU S COMMAND 3707 18k 4980 90936 75m 13m 1.8 454:47 96.9 R X :0 only kill -KILL would stop X from consuming the CPU, but my console remains stuck, chvt won't work, i don't know any way out other than reboot and that gets my goat. Steps to Reproduce: 1. wait for xscreensaver to lock 2. hit a key 3. if xscreensaver freezes, try chvt (via ssh) 4. find xscreensaver subprocess, kill -9 5. if necessary kill -9 main xscreensaver process 6. X may or may not die, vt may or may not freeze 7. if frozen, chvt may or may not get you out 8. if X is gone and chvt won't work, what's left other than reboot? Version-Release number of selected component (if applicable): kernel-2.6.9-55.EL xorg-x11-6.8.2-1.EL.31 xscreensaver-4.18-5.rhel4.14
If you set the screensaver to blank screen do you still get lock ups? There have been reports of buggy 3D drivers causing this sort of thing when an OpenGL screensaver gets played.
i'll try that. and if you mean i should just do my best to avoid the bugs that's fine, tho i'm happy to help with bug catching, i guess i expect a bug that forces a linux reboot would be high on sombody's squashing list.
Hi, I'm just suggesting a potential workaround, and an avenue to help debug the problem.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.