Red Hat Bugzilla – Bug 56465
blaster module locks up X and system
Last modified: 2008-05-01 11:38:01 EDT
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):
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
Japanese environment and version of Roswell. Sawfish and Gnome (also
This is a severe bug, but it's easy to avoid--just turn off this
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
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).