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.
Bug 83534 - GFlux (grab) causes X to freeze display
GFlux (grab) causes X to freeze display
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: Triaged
Depends On:
Blocks: FC4Target
  Show dependency treegraph
Reported: 2003-02-05 07:56 EST by Gene Czarcinski
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-22 05:58:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/XF86Config (3.16 KB, text/plain)
2003-02-05 09:32 EST, Gene Czarcinski
no flags Details
/var/log/XFree86.0.log (42.04 KB, text/plain)
2003-02-05 09:33 EST, Gene Czarcinski
no flags Details
lspci -vvn (7.46 KB, text/plain)
2003-02-05 09:34 EST, Gene Czarcinski
no flags Details

  None (edit)
Description Gene Czarcinski 2003-02-05 07:56:26 EST
Description of problem:
I am reporting this against XFree86 rather than GFlux (grab) because I believe
that there is nothing a screensaver should be able to do to freeze the display.

Hardware: ATI Rage 128 RF/SG AGP

01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
(prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Rage Fury/Xpert 128/Xpert 2000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Region 1: I/O ports at d800 [size=256]
        Region 2: Memory at de800000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at dffe0000 [disabled] [size=128K]
        Capabilities: [50] AGP version 2.0
                Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1
        Capabilities: [5c] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Although not found via preview, I have been able to cause the problem via
screensaver preview.  Select the GFlux (grab) saver and hit preview ... let it run.

From another system, ssh to the system under test and run top.  You will see
gflux running and then disappear after a while.  X will now be using 99% of cpu.
 The display will be frozen and the keyboard unresponsive (can't switch to VC)
on the system under test.

Version-Release number of selected component (if applicable):
8.0.93 + rawhide as of Feb 4 2003

xscreensaver 4.06-5
kernel 2.4.20-2.33

How reproducible:
every time

I can create this at will so whatever logs, etc. you need can be provided.
Comment 1 Gene Czarcinski 2003-02-05 08:44:39 EST
I tried running (GFlux Preview) on an ATI Radeon RV200 [Radeon 7500].  After
about 30 minutes, I gave up ... it does not have the problem.

On the system with the problem, it usually took about 10 minutes to happen (800
MHz P-III cpu).
Comment 2 Gene Czarcinski 2003-02-05 09:32:10 EST
The system using the r128 driver seems to have the problem.  I could not get it
to occur on systems using the radeon driver.
Comment 3 Gene Czarcinski 2003-02-05 09:32:58 EST
Created attachment 89865 [details]
Comment 4 Gene Czarcinski 2003-02-05 09:33:51 EST
Created attachment 89866 [details]
Comment 5 Gene Czarcinski 2003-02-05 09:34:53 EST
Created attachment 89867 [details]
lspci -vvn
Comment 6 Gene Czarcinski 2003-10-27 14:24:00 EST
I believe this problem is still there.  This has aged so long that I am closing
it and will open a new bug if (or when) I get around to looking at the problem
Comment 7 Mike A. Harris 2003-10-27 14:59:42 EST
If the problem is still present, there is no need to close it.  If nobody knows
a bug is present, then nobody will ever fix it.  It's generally a good idea
to file bug reports in XFree86.org bugzilla also, as there's only 2 people
here working on XFree86 with limited resources.  We can't possibly fix every
single bug reported, but we still want to know that bugs exist, and for them
to be left open as long as they are relevant.  Someone out there might have
a patch, or have the time to debug a problem further, that we haven't had the
time to investigate yet.

I don't think I've had a R128 card plugged into one of my systems since
before this bug was even reported, to even attempt to reproduce the problem.
Before I'd close it personally as WONTFIX, I'd at least be making an attempt
to reproduce it myself and determine wether or not it is worth spending
further time on, be that debugging manually, or surfing through upstream
CVS for fixes.  Plus, once I start testing R128 hardware again, I'll probably
be going one R128 bug at a time through bugzilla and trying to handle them

Also, since Fedora Core is now a community project, there are likely to
be more people out there spring up to volunteer to help reproduce and fix
problems like this.

So if you've lost interest in a bug, or no longer have the hardware, feel free
to update the report to indicate that, but please don't close reports
prematurely unless you can confirm a newer relase fixes them or somesuch.

Comment 10 Mike A. Harris 2005-03-22 05:58:26 EST
I've tested an R128 card with DRI enabled to see if this problem still exists
in X.Org 6.8.2, and was unable to reproduce it.  A few people in IRC also
were unable to reproduce with R128 hardware.

I think we can safely assume the problem is resolved in 6.8.2, and quite
possibly earlier releases as well.

If anyone can still reproduce this problem on an R128 variant however, please
reopen the report and attach your X server log, config file, and the
/var/log/messages file, and we'll re-investigate the issue.


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