Bug 55991 - xlock under XFree86 4.1.0 locks keyboard, video
Summary: xlock under XFree86 4.1.0 locks keyboard, video
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-09 22:10 UTC by Greg Bailey
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-24 15:46:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XFree86 4.1.0 log file (16.72 KB, text/plain)
2001-11-09 22:13 UTC, Greg Bailey
no flags Details
XFree86 4.1.0 configuration file (1.86 KB, text/plain)
2001-11-09 22:13 UTC, Greg Bailey
no flags Details
"top" output showing 100% CPU usage by /etc/X11/X (14.01 KB, text/plain)
2001-11-09 22:14 UTC, Greg Bailey
no flags Details

Description Greg Bailey 2001-11-09 22:10:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13 i686)

Description of problem:
I recently upgraded from XFree86 3.3.6 to XFree86 4.1.0 after I manually
specified the amount of video memory I had (see Bug #55052).  When I run
"xlock -mode random", I come back to find the console is frozen.  I am
unable to get the password dialog, unable to switch to a virtual console
(Ctrl-Alt-F2, etc.), and notice that the CPU usage is pegged at 100% by
/etc/X11/X (not xlock).

I have an Elsa Gloria Synergy card with 4M RAM in a Compaq AP350

I am able to connect remotely via telnet/ssh, and aside from the keyboard
being unresponsive, and the video frozen with the xlock mode (in the most
recent case, it was the colored trees), I am able to login and "do" stuff. 
When I kill X, xlock, etc., I see the CPU drop back to low usage, but the
video is still locked and the keyboard unresponsive.  I did not have this
problem with XFree 3.3.6.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Configure XFree86 4.1.0
2.  Run "xlock -mode random"
3.  Go away and come back.  See monitor frozen

Actual Results:  The keyboard is dead and the monitor shows a stuck xlock

Expected Results:  I should receive a password prompt, followed by a
restored X session.

Additional info:

I selected "sometimes, but not always" because I can manually invoke xlock
and then type my password right away and restore it.  It seems to occur
when I leave it running for a bit.  It has failed with different xlock
modes.  (Not GL ones, by the way)

Comment 1 Greg Bailey 2001-11-09 22:13:06 UTC
Created attachment 37121 [details]
XFree86 4.1.0 log file

Comment 2 Greg Bailey 2001-11-09 22:13:45 UTC
Created attachment 37122 [details]
XFree86 4.1.0 configuration file

Comment 3 Greg Bailey 2001-11-09 22:14:31 UTC
Created attachment 37123 [details]
"top" output showing 100% CPU usage by /etc/X11/X

Comment 4 sahag 2001-11-14 23:16:20 UTC
I have exactly the same problem.
The difference is that in my case it's xscreensaver and not xlock.
When I leave my GNOME desktop for some period of time it _completely_ freezes.
After I disabled the screensaver it works fine.

I believe one of the screensavers completely freezes the system.

Comment 5 Harald Hoyer 2001-12-13 14:53:13 UTC
I think, this is because you do not have 3D hardware acceleration. you may try:
$ xlock -mode atlantis

and if that shows up your problems you may want to avoid software 3D (opengl) 
in your screensaver

Comment 6 Harald Hoyer 2001-12-13 14:54:04 UTC
oops, did overread your comment: (Not GL ones, by the way)

Comment 7 Harald Hoyer 2001-12-13 14:56:03 UTC
mharris? comments?

Comment 8 Harald Hoyer 2002-01-11 16:53:53 UTC
may you specify the xlock modes where it failed?

Comment 9 Mike A. Harris 2002-01-11 18:41:33 UTC
I'm curious if the problem exists still with XFree86-4.1.0-14
which is about to be released as errata.


Does this fix the problem?  Also, be sure to be using the latest
official Red Hat kernel release.

Comment 10 Mike A. Harris 2002-01-11 18:48:02 UTC
Another thing worthy of noting is that you are using a resolution
of 1600x1200 in 16bit depth.  That is 3.8Mb of video RAM, not
leaving much Video RAM for anything else such as pixmap cache, etc.
When XFree86 is in tight RAM constraints, it often does not warn the
user, and instead just acts erratically.  You might want to try 1024x768
just for test purposes.  If the problem is reproduceable at 1024, it
would be useful data to know.

Comment 11 Greg Bailey 2002-01-25 18:15:48 UTC
OK, I upgraded to kernel-2.4.9-21 and XFree86-4.1.0-15 (errata as of 1/24/2002)
and still have the same problem.

I've switched to 1024x768 just to verify that the problem doesn't occur.

Re: your tight memory constraints comment, I assume that implies that XFree86 v3
and XFree86 v4 differ significantly in handling memory; I didn't experience this
at all with the XFree86-3DLabs-3.3.6-42 RPM.

By the way, is there any way to reset the text mode once XFree has wedged it? 
(i.e. do some kind of hardware reset/change video mode?)

Comment 12 Greg Bailey 2002-01-25 22:48:10 UTC
Interesting...  the resolution doesn't appear to be the problem as xlock has
frozen XFree86 sometime in the last 4.5 hours, even at 1024x768.

I'm not sure which mode was running...  I don't get a video signal--I'm assuming
some sort of screen blanking routine came on?  As before, I can still login
remotely and see /etc/X11/X consuming 100% CPU.

Anything else I can try?

Comment 13 Harald Hoyer 2002-05-02 15:38:27 UTC
 I don't get a video signal ... could that be dpms???

Comment 14 Greg Bailey 2002-05-15 19:06:23 UTC
I've since reloaded this same hardware with RedHat 7.3

I again experienced the same problem with XFree86-4.2.0-8.  Again, I've
downgraded to XFree86-3DLabs-3.3.6-44 to alleviate this problem.  Would be
interested in hearing any other suggestions/ideas to try...

Comment 15 Greg Bailey 2002-08-27 18:10:34 UTC
We have a whole slew of Compaq AP200 Workstations which all seem to have these
3D Labs video cards.  I've loaded one with RedHat 7.3, and set the resolution to
1024x768, 16 bit.

Using XFree86-4.2.0-8, it locked up with the xscreensaver under mode "laser". 
Any ideas with this one?  I'd hate to not be able to upgrade to RH 7.X, 8.X or
whatever just because XFree86-3.X got dropped!  :-(

Comment 16 Mike A. Harris 2003-01-24 15:46:57 UTC
If there is a real bug present here in XFree86, which is entirely possible,
it would require having both the video card itself, and the specifications
for the video card in order to fix.  Unfortunately, I have no 3Dlabs hardware
or documentation, and am ultimately not able to provide any solution.

The upstream driver maintainer Alan Hourihane should be notified of this
problem if it still persists in XFree86 CVS.  He is about the only person who
knows anything about this hardware, and is capable of troubleshooting and
fixing the driver.

I'm closing this issue as WONTFIX right now because there is not a way
that we can realistically provide a fix for this.  This driver is
ultimately supported by community knowledge.

Note You need to log in before you can comment on or make changes to this bug.