Hide Forgot
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
Switching off dpms in xorg.conf does not help. Sigh!
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.
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?
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.
Created attachment 156548 [details] Xorg.0.log from a run with an attached xorg.conf present
Created attachment 156549 [details] Xorg.0.log from a run with no xorg.conf
Created attachment 156550 [details] log for a server running on display :1.0 (with xorg.conf as attache)
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?
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.
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?
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.
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...
I had the same problem, http://www.redhat.com/archives/fedora-package-announce/2008-February/msg00565.html fixed this for me...
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.
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
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.