Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 55265 - xscreensaver locks up the screen
xscreensaver locks up the screen
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.2
All Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2001-10-28 13:56 EST by Neil McNeight
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-29 00:12:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Neil McNeight 2001-10-28 13:56:54 EST 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901

Description of problem:
When xscreensaver runs certain modules, it locks up the keyboard and screen
while allowing the mouse pointer to still move. Specific modules I've
verified do this are Atlantis, Bubble3D and Cage. All three modules have
also been observed taking up all available CPU time. 3D Clock seems to work
fine.


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


How reproducible:
Always

Steps to Reproduce:
1. select an xscreensaver module from the screensaver control panel
 or
2. set xscreensaver to "Random Screensaver" and wait for it to hit a buggy
module
3.
	

Actual Results:  Screen locks up. No screen saver shown. Keyboard doesn't
work. Mouse and pointer still function, but will not select/drag/click
anything.

Expected Results:  xscreensaver should have worked, and then stopped when
no longer needed.

Additional info:

See also bug #49569. It might be the same bug escaped into 7.2.

Under all circumstances, the machine is accessable from the network and if
the process is killed off quickly enough, the machine returns to normal.

Also, all occurences of this bug have happened using GNOME (default
packages, not Ximian). Untested with KDE.
Comment 1 Bill Nottingham 2001-10-28 16:07:17 EST 
Sounds like a bug in the DRI support for your graphics card. What card are you
using?
Comment 2 Neil McNeight 2001-10-28 16:35:30 EST 
ATI Expert 128 AGP with 16 Meg of RAM. This might also explain why chromium
locks my system up as well (haven't reported that bug yet...).
Comment 3 Neil McNeight 2001-10-28 18:36:20 EST 
I'm not going to close the bug just yet, but it seems that this is disturbingly
similar to bug #33581. I am using an ATI r128 chipset with 16 meg of memory,
running at 1280x1024x24 with DRI enabled.

I guess the only remaining question is why Xconfigurator still allows this
borken behavior?
Comment 4 Mike A. Harris 2001-10-28 23:41:06 EST 
Yes, you absolutely can not use DRI on a 16Mb card with such a setup.
Xconfigurator allows it, because ultimately it is a video driver
problem.  If the drivers are fixed to allow dynamic reallocation
of video resources, and Xconfigurator is written to disallow such
setups, then Xconfigurator will not work in valid setups in future.

The real fix, will be when XFree86 matures to disable DRI on its own
(in the short term), and handle the situation more like Windows does
in the long term.

DOes using 1024x768x16 fix the problem?
Comment 5 Neil McNeight 2001-10-29 00:12:19 EST 
I went to 1280x1024x16 w/DRI, and all seems well. All of the previously
mentioned xscreensaver modules work OK, and chromium now works as well.

I suppose this bug should be left open until fixed once and for all, but I
believe that this problem is solved for my specific case.

Thanks!
Comment 6 Mike A. Harris 2001-10-29 00:38:17 EST 
Ok, I'm closing the bug then.  The issue is very well known, and
there are numerous bugs open still that document it.  Xconfigurator
is planned to default to not allowing known DRI problematic configs
in the future, however as stated already, it is an X video driver
problem, in combination with a resource allocation issue.  They are
not small bugs, but rather a core X design issue.  They'll likely
be addressed in the 4.3.0 era of XFree86.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.