Red Hat Bugzilla – Bug 533315
KMS:RV280:Radeon 9200 PRO Display is randomly blanked when system is not idle
Last modified: 2010-06-11 15:51:29 EDT
Created attachment 367775 [details]
Xorg.0.log from a freshly started X server but after an experiment as described in the report.
Description of problem:
A display blanks for a few seconds in random intervals when it definitely should not.
Version-Release number of selected component (if applicable):
Using instead released packages for xorg-x11-server-1.6.4-0.1.fc11 does not change the picture. 1.6.4-0.3.fc11 is currently from updates-testing.
All the time although in a non-predicatable manner
Steps to Reproduce:
Work for a while as usual and it will happen. Still the following seems to provide an easy way to repeat:
1. Create a bit bigger text file. Say with the following script:
for n in $(seq 100) ; do
echo "just some text just some text just some text just some text"
done > /var/tmp/sample.txt
2. Load that file on a desktop into emacs and use a slider bar on a side to move, rather fast, that text repeatedly up and down.
3. Instead of a text just scrolling, better or worse, in an emacs window the whole screen picture starts to jump up and down in a very disconcerting manner (which may be another bug related or not - I do not know) and a after a few moves of that sort, unpredictable number but usually quite small, a screen goes blank for a while. Moving a mouse or touching a keyboard does not seem to have any influence on how long this black screen lasts. It returns on its own after a short while.
Screen go blank from time to time for one to three seconds while all kind of activities are happening.
Nothing like the above.
This seems to be really the same as bug 501601 but the other one is "CLOSED ERRATA" and it appears that this is indeed the case for some. Still note, for example, comments
Hardware - ATI Technologies Inc RV280 [Radeon 9200 PRO] - was in use with a number of Fedora distributions and it was now showing symptoms in question before Fedora 11 was put in use. Monitor - Samsung SyncMaster 213T LCD.
There is currently no /etc/X11/xorg.conf. Xorg.log after a procedure described above attached. I tried to catch what is happening on some kind of a movie but results with my simple photo camera are not very good.
I was thinking a bit what happens. I have no idea if that is a real mechanism but what I see in "Steps to Reproduce" _looks_ like a series badly synchronized screen updates, making a picture jump like from a broken movie projector, followed by a switch to an absolutely empty off-screen buffer where we stay for a while before switching back.
A presence or absence of 'nomodeset' in a boot line does not make much difference. It seems to me that without 'nomodeset' the situation is even worse, i.e. a screen picture disappears more frequently.
As another datapoint - booting without 'nomodeset' makes a screen saver NOT to turn off a display. That means that a display goes "black" but it is still going full blast. A display becomes only a dark gray instead of turning off and a power light on a monitor is lit up all the time. That after leaving a machine not touched by over an hour and a half.
After booting the same configuration but _with_ 'nomodeset' a screen, after an expected while, really turns off and a power light starts slow blinking.
When a display goes away inadvertentently it has a tone of something turned off but not one of "grayed out" by a not entirely functioning screensaver.
I tried to play with "AccelMethod" and "EXAVSync" radeon driver options. They do not seem to influence visible outcomes in any way.
i'm one of the bug#501601 "it was never fixed for me" users. i have radeon hardware. it's possible this is now a radeon specific issue.
now running F12 and the problem is SEVERE. as soon as the monitor comes back from DPMS sleep it blanks every few seconds until I reboot. again, this is only the DVI panel. blanks are also exactly 3 seconds long (manually timed so += a few tenths each time).
recommending severity be boosted. even if this only hits a few users, it's extremely severe when it does hit (i.e. makes system unusable)
Please attach also your X server config file (/etc/X11/xorg.conf, if you have any), and output of the dmesg command to this bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
no xorg.conf (fresh F12 install)
dmesg will be attached momentarily...
Created attachment 372402 [details]
dmesg output from affected system
Any update on this issue?
It looks like I am having the same issue even with the latest update on Fedora 12.
I have radeon 3450 hardware.
Please help. Let me know if you need additional logs
I no longer see this problem, and it could be related to the following configuration change:
System -> Preferences -> Screensaver -> Power Management -> Display
Put display to sleep when inactive for: 1 hour
After having changed this, I have not had the random blanking a single time. Since then I haven't changed anything or done any other experiments.
I have more kerneloops logged...
sorry, mistaken bug, please remove.
I replaced the card with another radeon (ATI Technologies Inc R300 AD [Radeon 9500 Pro]) which I happened to have around and it looks like that a display nastiness stopped. It become practically impossible to use a machine before that switch. That replacement card has only 64K of memory on it.
Created attachment 389853 [details]
Xorg.0.log with a replacement video card
I haven't seen this problem for months. Tonight, I mistakenly created a huge tar file (over 10 GB) while my laptop was unplugged. While tar was causing lots of disk activity, the display kept dimming and then restoring, and my computer was nearly unusable. When I stopped the runaway tar command, all the dimming symptoms disappeared.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora Bugzappers volunteer triage team
[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]
as far as i can tell, this does not happen in a fresh F13 install. consider fixed from my perspective...
Thank you for reporting back.