Red Hat Bugzilla – Bug 158013
X screen flashes until I go to & return from text virtual terminal
Last modified: 2007-11-30 17:11:06 EST
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):
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.
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
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.
I saw ncunning added to the Cc: list for this bug, and that reminded me of its
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.
ah this assigned to the wrong component. Let me move it to Xorg.
What type of ati card is it?
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:  Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities:  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
(--) 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 =
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 ?
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.
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.