Description of problem: Sometimes, but not always, my screen will fall asleep (but the rest of the system hasn't suspended or anything). Usually when I move the mouse the monitor will come back on fine, but sometimes nothing I do makes it wake up. I end up blindly changing to a vterm and Ctrl-Alt-Del rebooting. This is a desktop computer with a NVidia GTX 470 (GF100). Version-Release number of selected component (if applicable): Fedora 16 Beta as of October 18th. How reproducible: 1 in 5, roughly Steps to Reproduce: 1. Don't interact with the computer 2. The monitor goes to standby after 10 minutes or so 3. Wait some amount of time (>10 minutes?) 4. Move mouse or try using the keyboard. Actual results: Monitor doesn't wake up. Expected results: Monitor wakes up Additional info: In GNOME's "Screens" config dialog, I set the monitor to be shut down after 1 hour, but it definitely shuts off a lot sooner than that.
I'm experiencing exactly the same problem. It only happens if the monitor stays off for a long time. If I interrupt soon after the monitor goes off it returns fine, but if I wait long enough the monitor will freeze and wont wake up. The frozen monitor won't even respond to the power (touch) button. The workaround to wake up the monitor is to disconnect the power cord and connect again. I have dual LG Flatron IPS236 and a NVidia N210 card. One monitor is connected to the DVI port and the other to the HDMI port. It only happens to the monitor connected to the DVI port. I've already switched the monitors and the problem goes to the one connected to the DVI port. Maybe it's a coincidence, but the problem appeared after my dual DVI card (NVidia 8600) died and I replaced it with a ATI Radeon X1550 (DVI + VGA). I was using Fedora 16. After I received the NVidia N210 (DVI + HDMI) I also moved to Fedora 17 (full re-install) and the problem persisted.
I am still suffering from this in Fedora 17. But I have found an easier way to recover: You can hit Alt-F2 and run "xset dpms force off", then push a key (like alt). Alternatively you can ssh in and run "DISPLAY=:0 xset dpms force off" Sometimes it will take two or three invocations before the monitor will turn back on. Danilo: You can actually run "xset -dpms" and then the monitor will never turn off.
I'm wondering if this is specific to nouveau though, as I've recently begun to experience almost identical problems with the radeon driver on my HD5700 card. I have a MacPro5,1 with: lspci | grep -i vga 05:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series] and lsmod | grep -i radeon radeon 890567 2 ttm 79585 1 radeon drm_kms_helper 40233 1 radeon drm 244674 4 radeon,ttm,drm_kms_helper i2c_algo_bit 13250 1 radeon i2c_core 33895 5 i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit The Radeon card has two mini-DP connectors and a DVI. I have two monitors connected with miniDP-to-DP cables, and once every several dpms sleep cycles one of my monitors (screen 0, monitor #1) will not wake up. I tried 'xset dpms force off' before, but it never worked the first time -- thanks Andrew for suggesting that a few retries might be needed, that helped ! :) One more bit of information that might be important -- aside from upgrading to the most recent F16 kernels as they were released, I recently switched from Dell U2410 to Dell U2412M monitors, and, coincidence or not, problems only started appearing after the switch.
Well that's interesting. I am using a Dell 3008WFP connected via Displayport.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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 17'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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.
I see this is closed but I'm going to add comments in case they're helpful to anyone else, maybe even my future self. I too am using a Dell U2412M. I am using the DisplayPort connector. And am running Fedora 20. Unlike the OP though, I'm using the radeon driver. The workaround in comment #2 helped save my session, the only other option would have been a hard reboot. $ lspci | grep -i vga 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts XT [Radeon HD 6870] $ rpm -q xorg-x11-drv-ati xorg-x11-drv-ati-7.2.0-3.20131101git3b38701.fc20.x86_64 $ uname -r 3.13.3-201.fc20.x86_64
I am experiencing the same problems with my displayport monitor: $ lspci | grep -i vga 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] $ rpm -q xorg-x11-drv-ati xorg-x11-drv-ati-7.6.1-3.20160215gitd41fccc.fc23.x86_64 $ uname -r 4.4.3-300.fc23.x86_64 If I shell into the machine whilst this problem is happening, and run `xrandr -q`, none of the available modes have an asterisk beside them. Running `xrandr --auto` causes the display to turn back on again.
This bug is currently reported against a Fedora version which is already unsuported. I am changing the version to '27', the latest supported release. Please check whether this bug is still an issue on the '27' release. If you find this bug not being applicable on this release, please close it.
I experienced the same issue in fedora 27 and now in 28. Computer wakes up from sleep but not monitor, i have no way to interact with it but only perform hard reset. My gpu currently is R9 270x, but during fedora 27 I had gtx 480 so I can confirm this happens with both radeon and nvidia. lspici -v result: Kernel driver in use: radeon
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 EOL if it remains open with a Fedora 'version' of '27'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 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 this bug is closed as described in the policy above. 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.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.