Bug 655039 - KMS:EVERGREEN:HD5700 hdmi monitor doesn't wake up from sleep
Summary: KMS:EVERGREEN:HD5700 hdmi monitor doesn't wake up from sleep
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-11-19 12:48 UTC by Jeff Layton
Modified: 2018-04-11 07:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-02-05 11:48:04 UTC
Type: ---

Attachments (Terms of Use)
dmesg (124.12 KB, text/plain)
2010-11-27 11:54 UTC, Jeff Layton
no flags Details
messages (393.71 KB, text/plain)
2010-11-27 11:55 UTC, Jeff Layton
no flags Details
xorg.conf (302 bytes, text/plain)
2010-11-27 11:55 UTC, Jeff Layton
no flags Details
Xorg.0.log (185.79 KB, text/plain)
2010-11-27 11:55 UTC, Jeff Layton
no flags Details

Description Jeff Layton 2010-11-19 12:48:01 UTC
I have my screensaver set up to put the display to sleep after 5 mins of idle time. When I return to the computer and wake it up, the main monitor on this machine (HDMI monitor) does not wake back up. If I physically turn the monitor off and back on, it comes back.

The card is a radeon 5770:

01:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series]

There are 2 displays attached to it:

HANNS-G HH241HPB (primary display via HDMI)
HANNS-G JW199D   (secondary display via DVI)

The second monitor generally never goes to sleep when the machine is idle (probably another bug), so I'm not sure whether it has the same problem.

I previously had a NVIDIA 8800GT in this machine with the same monitors and didn't have this problem, so I'm opening this as a radeon driver bug.

The machine is running:


...I'm using a f15 kernel here to get rid of the pink line running down the side of the screen with earlier kernels (see bug 597366).

Comment 1 Jérôme Glisse 2010-11-23 17:10:58 UTC
Please attach kernel log and Xorg log

Comment 2 Matěj Cepl 2010-11-24 14:05:23 UTC
To be more specific:

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

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

Thanks in advance.

Comment 3 Jeff Layton 2010-11-27 11:54:43 UTC
Created attachment 463225 [details]

Comment 4 Jeff Layton 2010-11-27 11:55:17 UTC
Created attachment 463226 [details]

Comment 5 Jeff Layton 2010-11-27 11:55:36 UTC
Created attachment 463227 [details]

Comment 6 Jeff Layton 2010-11-27 11:55:58 UTC
Created attachment 463228 [details]

Comment 7 Jeff Layton 2010-11-27 11:59:36 UTC
Ok, requested info is attached. I was hoping to get the logs from during one of the "events" where the monitor goes to sleep and can't be woken back up. But, for some reason the screensaver never kicked in after rebooting and letting the machine sit idle.

Let me know if you need other info.

Comment 8 Jeff Layton 2011-11-09 20:29:36 UTC
FWIW, this is still a problem on this monitor even after moving the machine to F16. Let me know if any other info would help to diagnose it.

Comment 9 Martin Naď 2012-05-25 19:20:35 UTC
*** Bug 825336 has been marked as a duplicate of this bug. ***

Comment 10 Gabriel Somlo 2012-08-31 13:35:39 UTC
I have the MacPro version of the Radeon5770 (two miniDP + one DVI), and I'm seeing the same issue (F16, currently with kernel 3.4.9-1.fc16.x86_64).

This problem seems to happen on nouveau as well (see bug 747162). Besides turning the monitor off and on again, doing "xset dpms force off" followed by wiggling the mouse or hitting a key can also wake the sleeping monitor back up.

Comment 11 Gabriel Somlo 2012-09-27 14:36:50 UTC
Continues happening on 3.6.0-0.rc6.git0.2.fc18.x86_64 as well. Running "xset dpms force off" a few times in a row will eventually wake up all connected monitors. So will power-cycling the affected monitors. Bumping version to 18 -- hope that's OK.

Comment 12 Jeff Layton 2012-10-09 18:55:45 UTC
Moving to f18 sounds fine. I haven't actually tested it there but it definitely still exists in f17.

I still have the same monitor setup. Both monitors do go to sleep properly now when the machine is idle. The secondary one will wake up when the mouse is wiggled, but the primary one does not.

Comment 13 Jeff Layton 2012-10-10 13:30:18 UTC
Huh, actually I've been conditioned for so long to hit the power switch on my monitor to wake it up that I haven't properly tested it for some time. The problem seems to now be fixed at least with the latest updates from f17!

Gabriel, you may want to open a new bug or clone this one if you're still having trouble since the problem is likely different.

Comment 14 Fedora End Of Life 2013-12-21 08:26:48 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

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.

Comment 15 Fedora End Of Life 2014-02-05 11:48:07 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

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.