Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158013 - X screen flashes until I go to & return from text virtual terminal
Summary: X screen flashes until I go to & return from text virtual terminal
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 4
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-17 20:09 UTC by David Kewley
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-28 23:11:15 UTC

Attachments (Terms of Use)

Description David Kewley 2005-05-17 20:09:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; en_US) KHTML/3.4.0 (like Gecko)

Description of problem:
I have found a handful of times that my X screen is flashing randomly, that    
is, going blank then returning the image within a second.  The timing and    
intervals appear random, with no obvious cause.  The interval between    
successive flashes can be as little as <1sec, but other times it's 10s of    
The workaround I discovered is to change to text VT1, then back to X VT7.     
After I do that, the X screen no longer flashes.    

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

How reproducible:
Didn't try

Steps to Reproduce:
1. N/A; see description in "Additional Information" below  

Actual Results:  X session display (KDE) blanks out (goes black) for ~1/4 second, then comes 
back.  It does this continuously until stopped, with intervals between flashes 
varying from <1sec to 10s of seconds. 

Expected Results:  A rock solid display. 

Additional info:

I just installed this machine three days ago, and did not see the problem at    
first.  I use KDE, and have the screensaver set to "blank screen" and "make   
aware of power management".  I have the display power control enabled, with  
standby disabled, suspend after 10 minutes, and power off after 60 minutes.  
My most recent citing of the flashing was when I first came in today (an hour  
ago :), powered on the Dell LCD screen (DVI-D input) hit a Ctrl key to wake up  
the lockout password prompt, and typed in my password to reopen the X display.   
From the moment my X session reappeared until ~10 minutes later when I  
switched VTs, I saw dozens of X screen flashes (blanks really).  In the ~hour  
since I switched VTs, I've seen no flashes.  
This is a new Dell Precision 370 workstation, and FC4t3 is the first OS I've    
installed on it, so it's possible that it's a hardware problem.  The reason    
I'm filing a bug is because there appears to be a "software" fix -- changing    
VTs and back.  Of course even this "software" manipulation could have changed 
hardware state in such a way as to work around a hardware problem.  Let's see 
if anyone else confirms this bug report. 
If I discover any other patterns in the onset of flashing, I'll update this 
bug report. 
I'm a sysadmin and have seen hundreds of machines.  I've only heard of one 
other machine with behavior like this -- a dual-headed (via nVidia card) Dell 
Precision 670, on which one of the output channels flashes similarly to mine. 
This is a current problem, and so far in his testing, my colleague suspects a 
hardware glitch (he has already ruled out the display & cable),  Replacing the 
gfx card did not fix it, but on Thursday we'll see if a replaced mobo & gfx 
card fix it.  Note that my Precision 370 has an ATI card, different mobo, and 
different rocessor, so if it's hardware, the two "flashing" problems are 
unlikely to be identical.

Comment 1 David Kewley 2006-11-09 20:08:21 UTC
I saw ncunning added to the Cc: list for this bug, and that reminded me of its 
existence. :)

An update: This issue also happens with FC5.  My intuition at this point is 
that the video timings throw off this particular 20" Dell LCD display.

I no longer believe this is an xscreensaver issue.  This bug has not received 
any attention since I opened it (it appears), and I'm soon going to lose 
access to the hardware platform on which the problem appears, so I am 
considering closing this bug, perhaps with status INSUFFICIENT_DATA.

If anyone objects to closing this bug with that status, speak up now.

Comment 2 Ray Strode [halfline] 2006-11-09 20:45:20 UTC
ah this assigned to the wrong component.  Let me move it to Xorg.

What type of ati card is it?

Comment 3 David Kewley 2006-11-09 21:12:15 UTC
lspci -vvvv says:

01:00.1 Display controller: ATI Technologies Inc RV370 5B64 [FireGL V3100 
(PCIE)] (Secondary) (rev 80)
        Subsystem: ATI Technologies Inc Unknown device 0103
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size 10
        Region 0: Memory at dfdf0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <128ns, L1 <2us
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <128ns, L1 <1us
                Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
                Link: Speed 2.5Gb/s, Width x16

/var/log/Xorg.0.log says:

(--) PCI:*(1:0:0) ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)] rev 
128, Mem @ 0xd0000000/27, 0xdfde0000/16, I/O @ 0xdc00/8, BIOS @ 0xdfe00000/17
(--) PCI: (1:0:1) ATI Technologies Inc RV370 5B64 [FireGL V3100 (PCIE)] 
(Secondary) rev 128, Mem @ 0xdfdf0000/16
(--) Chipset ATI FireGL V3100 (RV370) 5B64 (PCIE) found
(--) RADEON(0): Chipset: "ATI FireGL V3100 (RV370) 5B64 (PCIE)" (ChipID = 

Comment 4 Christian Iseli 2007-01-22 11:57:31 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 5 Matthew Miller 2007-04-06 15:22:36 UTC
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest
this issue on a current release or on the latest development / test version, we
would appreciate that. Otherwise, this bug will be marked as CANTFIX one month
from now. Thanks for your help and for your patience.

Comment 6 Nigel Cunningham 2007-05-28 23:11:15 UTC
Given the previous comments, I'm closing this bug as CANTFIX. Please reopen if
something has changed and you think that's the wrong thing to do.

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