Bug 243022 - xorg-x11 radeon driver blanks in the most unopportune moments
Summary: xorg-x11 radeon driver blanks in the most unopportune moments
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 7
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-06 22:09 UTC by Michal Jaegermann
Modified: 2018-04-11 16:04 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-06-17 01:28:03 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/etc/X11/xorg.conf currently in use (671 bytes, text/plain)
2007-06-08 06:01 UTC, Michal Jaegermann
no flags Details
Xorg.0.log from a run with an attached xorg.conf present (50.13 KB, text/plain)
2007-06-08 06:02 UTC, Michal Jaegermann
no flags Details
Xorg.0.log from a run with no xorg.conf (50.86 KB, text/plain)
2007-06-08 06:03 UTC, Michal Jaegermann
no flags Details
log for a server running on display :1.0 (with xorg.conf as attache) (45.68 KB, text/plain)
2007-06-08 06:10 UTC, Michal Jaegermann
no flags Details
for comparison Xorg.0.log with 9500 (53.66 KB, text/plain)
2007-06-13 21:06 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2007-06-06 22:09:19 UTC
Description of problem:

After an update of FC5 installation to FC7 from time to time
a screen goes away, i.e. turns black, in the middle of a normal use.
It comes back after few seconds but this becomes fast a real PITA.
Nothing like that was ever happening before this upgrade.

It appears that power management code kicks in unasked.
The reason I think that this is the case is that I can find
in log files things of that sort:

....
(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(2,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(3,0x0)
(**) RADEON(0): RADEONSaveScreen(1)
(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)
(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(2,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(3,0x0)
(**) RADEON(0): RADEONSaveScreen(1)
(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONSaveScreen(0)
(**) RADEON(0): RADEONDisplayPowerManagementSet(1,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(2,0x0)
(**) RADEON(0): RADEONSaveScreen(2)
(**) RADEON(0): RADEONDisplayPowerManagementSet(3,0x0)
(**) RADEON(0): RADEONSaveScreen(1)
(**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0)

and time stamps on logs seem to conicide with vanishing screen.
At this moment I am running servers on displays :1.0 and :2.0
due to another problem I have yet to file a report. "Server 0"
is supposed to be for now "inactive".

Opening a new tab in firefox seems like good way to cause
a screen to go blank but not when you are trying to repeat
that and the same blanking happens in other moments as well.

ATI Radeon 9250 5960 (AGP) driving TMDS flat panel monitor on
a digital output.  "dpms" option is used (and I can try
to turn it off).

I have actually a rawhide installation on another machine
using radeon driver too but this is Radeon 9500 AD (AGP),
only one screen active and hooked up to an old analog monitor.
Nothing like that was also observed on another machine with
radeon and FC6 installation (xorg-x11-drv-ati-6.6.3-1.fc6)
and where also a flat panel monitor with digital connection
is in use. 

Version-Release number of selected component (if applicable):
xorg-x11-drv-ati-6.6.3-2.fc7

How reproducible:
annoyingly frequently and randomly

Comment 1 Michal Jaegermann 2007-06-07 05:04:43 UTC
Switching off dpms in xorg.conf does not help.  Sigh!

Comment 2 Matěj Cepl 2007-06-07 14:49:52 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 3 Michal Jaegermann 2007-06-07 21:32:09 UTC
It looks at this moment that I found how to avoid the problem.

In the first step I put in a '[daemon]' section of /etc/gdm/custom.conf
the following:

AddGtkModules=false
GtkModulesList=""

This greatly reduced a frequency in which such "blackouts" were
occuring but it did not cut that down to zero.

Going through my "inherited" from an upgraded system /etc/X11/xorg.conf
I noticed such option

       Option      "AGPMode" "4"

in "Device" section.  That used to be necessary in the past as
old radeon driver left to itself was going into an impossible
AGP mode, like 12, and was crashing hard.  A value for a mode was
a particular card dependent and derived by experiments.  Now it is
possible to comment out that line.

With both modifications in place it looks like that a display
stays active when in use.  None of the two by itself was enough
to get that result.

Do you still want to see items mentioned in comment #2?


Comment 4 Michal Jaegermann 2007-06-08 06:01:15 UTC
Created attachment 156546 [details]
/etc/X11/xorg.conf currently in use

Scratch, partially, the previous comment.  After a while it turned out
to be bogus.  Moments when I am getting a totally blank screen just
returned.  These are not blinks; they last for quite a few seconds and
when they start to happen they can show up quite frequently.
I tried to watch, with 'tail -f' what happess in  Xorg.0.log and
actually nothing is recorded in such moments so that log fragment
quoted in the original report does not seem to be directly relevant.

Eventually I turned off dpms in config and that seems to help.
Keep your fingers crossed.  The point is that I was trying with
dpms turned off before, but AGPMode still set to 4 _and_ extra
modules loaded by gdm, and that did not help.  Currently it seems
to behave, already for some time, although I cannot be sure that
something will not go haywire all of sudden.  Some timings which
confuse power managment?

I never had such problems before upgrading to F7 installation.

Comment 5 Michal Jaegermann 2007-06-08 06:02:54 UTC
Created attachment 156548 [details]
Xorg.0.log from a run with an attached xorg.conf present

Comment 6 Michal Jaegermann 2007-06-08 06:03:53 UTC
Created attachment 156549 [details]
Xorg.0.log from a run with no xorg.conf

Comment 7 Michal Jaegermann 2007-06-08 06:10:04 UTC
Created attachment 156550 [details]
log for a server running on display :1.0 (with xorg.conf as attache)

Comment 8 Michal Jaegermann 2007-06-08 06:22:50 UTC
Bummer!  After a while even without dpms a screen starts to
turn itself off.  It just did that three times in a short time span.
Now appears to behave again - who knows for how long.

Any suggestions?

Comment 9 Michal Jaegermann 2007-06-08 19:16:21 UTC
On an assumption that a vanishing picture may be caused by a driver
attempt to adjust again an output automatically to a digital or
analog connection I added to xorg.conf a device option

        Option      "MonitorLayout" "TMDS,NONE"

Unfortunatly that did not help.

The above resulted in the following fragment in logs:

.....
(II) RADEON(0): Primary:
 Monitor   -- TMDS
 Connector -- DVI-I
 DAC Type  -- TVDAC/ExtDAC
 TMDS Type -- Internal
 DDC Type  -- DVI_DDC
(II) RADEON(0): Secondary:
 Monitor   -- NONE
 Connector -- VGA
 DAC Type  -- Primary
 TMDS Type -- NONE
 DDC Type  -- VGA_DDC
(II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=46909632846912;
xclk=19900
(WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled
......

"Failed"???  I thought that it was told that there is NONE.

Comment 10 Michal Jaegermann 2007-06-10 20:09:51 UTC
I tried to see what will happen without gdm in a fray; i.e. I took
an installation to "level 3" and did startx from a user account.
It appears that a frequency of blackouts was substantially reduced,
although it is hard to tell as I do not have a good way to predict
how often and when something like that will happen, but I still observed
some incidents of that sort.

Each of these blackouts lasts around 3 seconds (not really measured
but I can count without hurry to five or six when a screen is black).
Any timers with such length?

Comment 11 Michal Jaegermann 2007-06-13 21:06:48 UTC
Created attachment 156920 [details]
for comparison Xorg.0.log with 9500

After various failed tries I switched Radeon 9250 to my test box
and Radeon 9500 AD to a regular one with an F7 installation.  So far
it looks that this move cured "blackouts" and they did _not_ go
with a graphics card to the other machine.

Keep in mind that 9250 now drives an old analog monitor, also in
a lower resolution, while previously this was a digital one.
Moreover this card was in use for quite some time in the same
hardware (mobo, monitor) configuration and only an upgrade
to F7 resulted in all these problems.

So everything is fine now?  Not quite.	9500 happens to have
half of a video memory of 9250 (64M vs. 128M), so they are quite
mismatched with what now they drive, and it was sort of an accident
that I was able to swap those cards in the first place. 

If you can see in logs any hints why the problem was happening
in the first place Xorg.0.log from a run with 9500 is attached.

Comment 12 Mark Bratcher 2007-11-24 13:23:45 UTC
I have the identical issue using Fedora Core 8 and ATI Radeon V7500-128A card.
The "black outs" don't occur very often, though. Perhaps once per day. So I have
ignored this issue thus far. I'll be watching this bug report with interest...

Comment 13 François Kooman 2008-02-25 14:35:11 UTC
I had the same problem, 
http://www.redhat.com/archives/fedora-package-announce/2008-February/msg00565.html

fixed this for me...

Comment 14 Michal Jaegermann 2008-02-25 17:23:38 UTC
Thanks.  Although this may help a machine with F8 installed this does
nothing for F7 where the last driver is xorg-x11-drv-ati-6.6.3-4.fc7
so the bug stays there.  Hopefuly recent ATI documentation releases
may shed some lite on this mystery.

Comments from others with the same problem, although apparently in
a less severe form, indicate that I am not totally insane. :-)

A "cure" described in comment #11 still happens to work.  It looks
like a lucky coincidence.

Comment 15 Bug Zapper 2008-05-14 12:52:21 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Bug Zapper 2008-06-17 01:28:01 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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