From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description of problem: The Blaster module for xscreensaver (3.33) totally locks up Xwindows and the entire system. The system is pingable, but telnet doesn't work. The mouse cursor is frozen and X cannot be killed. This is the only module that has a problem. I'm running on a Toshiba PIII-700 laptop (Savage S3/MX video) in 1024x768 True Color mode. Mouse is a Logitech USB. xhost is turned off (xhost +). The system had to be hard powered down twice because of this bug. I disabled this particular module and everything else is fine. There is a newer source for Xscreensaver (3.34), but I haven't tried to rebuild it. This bug doesn't appear in the changelog on the homepage. Note that I am using the JAPANESE version of Roswell and running Sawfish/Gnome in Japanese. Xscreensaver is all in English, so I doubt that the environment makes a big difference, but it might. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run xscreensaver & 2. run xscreensaver-command -prefs 3. Choose blaster module, click on "demo" Actual Results: System started screensaver, then X locked up totally. Expected Results: Screensaver runs normally. Demo ends with mouse movement. Additional info: Japanese environment and version of Roswell. Sawfish and Gnome (also Japanese). This is a severe bug, but it's easy to avoid--just turn off this particular module.
This is a problem with the X driver, most likely.
I'm sorry, it turns out that this is a documented bug in the S3 X driver, prior to the current version (1.1.20t). It's documented at http://www.probo.com/timr/savage40.html This issue can be closed (although it should be better documented by RH...)
Ok, I spoke too soon. I installed the new driver and tested Blaster. It no longer locks up the system, but it does totally screw up the X server, so that nothing at all can be seen on the screen. The driver won't properly redraw after the saver demo terminates. However, the mouse still works and if you succeed in logging out blindly (or telnet in and kill X), X restarts normally without the need to reboot. This is still an offensive bug, and this module probably ought to be disabled by default, if it's included at all. BTW, this bug remains unchanged in release 7.2
Is this problem present in the XFree86 4.1.0-15 update we released?
Yes. I updated RH 7.2 to the latest version of Xfree86 (and also the kernel and other updates) using up2date. I'm also using the latest S3 X driver. Although the system is fully patched, blaster still locks up X. If anything, it's worse than before. A "starfield" graphic comes up and then X totally locks up, including the mouse. It needs to be killed via telnet or a restart.
Approximately how long after starting up blaster until the system locks up? I presume it is right away, or at least fairly quick.
It was an extremely quick lock up--basically right away. Further information on this. I just upgraded to version 4.01 of Xscreensaver. This version has fixed the Blaster module problem, and Blaster now works properly with this video card etc. This bug can be closed with the fix being upgrade everything to the latest version (i.e. latest X11R6, latest S3 drivers and latest version of Xscreensaver).