Red Hat Bugzilla – Bug 24780
Last modified: 2008-05-01 11:37:59 EDT
I have Redhat Linux 7.0 installed on an HP Visualize Linux workstation
model XL866 with dual CPU's and 1 Gbyte of RAM. It has a Matrox G400 dual
port AGP display adapter and two monitors. I am running XFree86 4.0.1,
WindowMaker, and KDE.
The problem I have observed and can repeat on this box is that when xlock
is invoked via the
WindoMaker root menu, it will run for a while and eventually hang while
displaying something that looks like a mal-formed cube. It then requires
someone to rlogin as root and kill xlock to free the session for the user.
I have run xlock manually and stepped through its whole list of themes but
have not been able to find one that looks like what is displayed when it
I have tried to duplicate this problem on another Visualize workstation,
this one is a PL600 with a single CPU and 256 Mbytes RAM. On the PL600,
xlock runs for a while then just quits.
DRI is hanging, almost certainly.
Does any GL program function properly? Maybe you should turn off
in /etc/X11/XF86Config-4 if it doesn't.
You may test GL functionality with /usr/X11R6/lib/xscreensaver/atlantis
contained in the xscreensaver package.
OK. We ran atlantis for over an hour on the box where xlock hangs. It seemed
to run fine.
Try running xscreensaver manually from the commandline or
xscreensaver-demo and go through each one one at a time to try and
track down the offending screensaver.
The problem is with xlock, not xscreensaver. xlock does not appear to invoke
As I mentioned earlier, I have already run xlock manually going through each of
the themes listed in the man page. I did not find one that appeared to be the
same as what is on the screen when it locks.
Is there someone at Redhat who is familiar enough with xlock to suggest where it
could be modified easily to log as it switches themes? I could do it myself,
but I would rather not take the time to reverse engineer it if someone is
already familiar with the code.
Try commenting out "GLcore" and "dri" in your config. Does this help?
Commenting out GLcore and dri results in xlock running for a few minutes and
then dying . It doesn't appear to leave a core file.
Hmm. I'm not familiar with xlock right now myself, however it is likely
best to have the proper package maintainer look into it even though it is
very likely an XFree86 bug. I'm going to reassign to see if we can
track it down.
To the original submitter - can you try out the latest XFree86 packages from
rawhide, as well as the latest xlockmore and xscreensaver packages and
see if the problem goes away. Not much sense in us taking too much time on
this one if by chance the problem you're experiencing is fixed now.
I am, even as we speak, working on packaging XFree86 4.0.3 for installation on
all of our Linux boxes. I will run xlock and see if it hangs up still.
I think you mean this mode:
xlock -mode morph3d -inwindow -nolock
I have now run xlock without arguments, which, I'm pretty sure is how
WindowMaker runs it when you select the lock menu function. I have also run it
in windowed mode as you specified. With XFree86 4.0.3, it no longer hangs. It
was pretty reproduceable before, so I think it is safe to say that the problem
Beauty, I'm closing it as fixed in rawhide.