Bug 533315

Summary: KMS:RV280:Radeon 9200 PRO Display is randomly blanked when system is not idle
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: xorg-x11-drv-atiAssignee: Jérôme Glisse <jglisse>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 12CC: bugzilla, mcepl, pur123, steven.chapel, vedran, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-11 19:51:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg.0.log from a freshly started X server but after an experiment as described in the report.
none
dmesg output from affected system
none
Xorg.0.log with a replacement video card none

Description Michal Jaegermann 2009-11-06 02:18:46 UTC
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):
xorg-x11-server-Xorg-1.6.4-0.3.fc11.x86_64
xorg-x11-server-common-1.6.4-0.3.fc11.x86_64
xorg-x11-drv-ati-6.12.2-14.fc11.x86_64
gnome-power-manager-2.26.4-3.fc11
kernel-2.6.30.9-90.fc11.x86_64

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.

How reproducible:
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.
  
Actual results:
Screen go blank from time to time for one to three seconds while all kind of activities are happening.

Expected results:
Nothing like the above.

Additional info:
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
https://bugzilla.redhat.com/show_bug.cgi?id=501601#c139
https://bugzilla.redhat.com/show_bug.cgi?id=501601#c154

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.

Comment 1 Michal Jaegermann 2009-11-06 14:33:03 UTC
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.

Comment 2 Michal Jaegermann 2009-11-06 17:49:41 UTC
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.

Comment 3 David Mansfield 2009-11-11 15:46:01 UTC
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.

Comment 4 David Mansfield 2009-11-19 14:18:40 UTC
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)

Comment 5 Matěj Cepl 2009-11-20 01:12:14 UTC
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.

Comment 6 David Mansfield 2009-11-20 02:15:47 UTC
no xorg.conf (fresh F12 install)

dmesg will be attached momentarily...

Comment 7 David Mansfield 2009-11-20 02:17:25 UTC
Created attachment 372402 [details]
dmesg output from affected system

Comment 8 Purnomo 2010-01-07 22:20:36 UTC
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

Comment 9 David Mansfield 2010-01-07 22:44:23 UTC
I no longer see this problem, and it could be related to the following configuration change:

In Gnome:

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.

Comment 10 Mariusz Smykuła 2010-02-09 21:04:20 UTC
I have more kerneloops logged...

Comment 11 Mariusz Smykuła 2010-02-09 21:04:51 UTC
sorry, mistaken bug, please remove.

Comment 12 Michal Jaegermann 2010-02-09 21:25:11 UTC
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.

Comment 13 Michal Jaegermann 2010-02-09 21:26:44 UTC
Created attachment 389853 [details]
Xorg.0.log with a replacement video card

Comment 14 Steve Chapel 2010-04-13 00:13:11 UTC
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.

Comment 15 Bug Zapper 2010-04-28 11:07:22 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Vedran Miletić 2010-05-24 20:13:07 UTC
Improving summary.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]

Comment 17 David Mansfield 2010-06-11 19:43:17 UTC
as far as i can tell, this does not happen in a fresh F13 install.  consider fixed from my perspective...

Comment 18 Vedran Miletić 2010-06-11 19:51:29 UTC
Thank you for reporting back.