Description of problem: I have set up my new Toshiba laptop to always suspend (when using XFCE; "sleep" when using KDE) when the lid is closed. However, when I open the lid, everything is working except for the screen, which is black. I can interact with the machine using SSH or SFTP from another machine, and the keyboard seems to be alive, lighting up when I press keys, but I cannot see any output. I have to hold down the power button to force it to close down and then restart it to regain the screen. Under Fedora 19, the screen always came back properly when resuming, but the keyboard was sometimes dead,and I had to try a number of times to get it working properly. Version-Release number of selected component (if applicable): kernel-3.15.0-0.rc8.git2.1.fc21.x86_64.rpm How reproducible: Every time Steps to Reproduce: 1. In Settings / power manager, set the action to Suspend when laptop lid is closed (on AC and on Battery and when battery power is critical 2. Close the lid and wait for the front lights to turn off 3. Open the lid Actual results: The screen is black and does not show any output, regardless of what I do. Expected results: The normal Fedora screen contents should be visible and should change in response to mouse or keyboard input. Additional info: Hardware: Toshiba Satellite S50D-A $ ls /sys/class/backlight acpi_video0 acpi_video1 $ grep '.*' /sys/class/dmi/id/*_* 2> /dev/null /sys/class/dmi/id/bios_date:09/10/2013 /sys/class/dmi/id/bios_vendor:Insyde Corp. /sys/class/dmi/id/bios_version:1.20 /sys/class/dmi/id/board_asset_tag:Base Board Asset Tag /sys/class/dmi/id/board_name:VG10AD /sys/class/dmi/id/board_vendor:AMD /sys/class/dmi/id/board_version:Base Board Version /sys/class/dmi/id/chassis_asset_tag:No Asset Tag /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:OEM Chassis Manufacturer /sys/class/dmi/id/chassis_version:OEM Chassis Version /sys/class/dmi/id/product_name:Satellite S50D-A /sys/class/dmi/id/product_version:PSKKWA-00M007 /sys/class/dmi/id/sys_vendor:TOSHIBA When I reboot and add "video.use_native_backlight=1" to the command line that commences with "linuxefi", it makes no difference to the result. When I reboot and add "acpi_osi="!Windows 2012"" to the command line that commences with "linuxefi", it also makes no difference to the result.
I have also observed this on an Acer Apire One 722 netbook running Fedora 20 x86_64 with the 3.15.x kernels. When I revert to the 3.14.9 kernel, I get the expected suspend-resume behavior.
Additional information: The behavior I have observed is 1. boot with 3.14.9 and when I shut the lid on my AO722, the system suspends and lights on the front go out, with the exception of the charge light if it is plugged in and the power light, which blinks orange. When I open the lid and touch a key, the system resumes from suspend properly. The screen will blank, but touching the touchpad brings up a password dialog to unlock the screen. 2. Boot with 3.15.7 (and other 3.15.x kernels) and when I shut the lid, nothing happens. Power remains on, all lights remain lit, and the screen does not power off. Opening the lid reveals the situation. 3. Select "Suspend" from the menu. The screen blanks, but that is all. The system is still operating and never does shut down. If I hit a mouse button, the screen wakes up, but the system never suspends. (I just learned this. Before, I tried hitting a key on the keyboard, and the screen did not wake up). Fedora 20, kernel 3.15.7. Kmod-wl is the only kmod installed. The C50 processor used has AMD Wrestler (Radeon HD6250) graphics. The 3.15.x kernels broke this. When can we expect to see a fix?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
I have been following up on this issue in bug # 1149233. This issue still exists with 3.17.2-200.fc20. What doesn't work: Suspending via menu option or lid switch leads to the blank screen on resume. What does work: Suspending via "systemctl suspend" results in suspend and resume that work properly. Alternately, suspending via "pm-suspend" also results in a proper suspend and resume.
I can confirm that the problem persists with 3.17.2-200.fc20.x86_64 I have tried Stephen's "systemctl suspend", but resume still comes up with a black screen for me. I am able to contact the computer from another machine using SSH, but not able to see anything on the screen. The same happens for me with "pm-suspend".
I have upgraded to Fedora 21 and the problem remains (using kernel 3.17.6-300.fc21.x86_64).
I have the same problem with 3.17.6-200.fc20.x86_64 on my Lenovo g510 laptop. I had to revert to 3.15.10-200.fc20.x86_64.
Fix that worked for me: Open /etc/UPower/UPower.conf and change IgnoreLid=false to true. Reboot and then check if it worked for you.
I tried that change after doing a "yum update". The result for me was that when I closed the lid, it no longer suspended. If I suspended the computer using the "log out" menu item, the machine suspended fine, but when the lid was reopened, the machine resumed and was accessible from other computers, but the screen did not come back, remaining black. The keyboard was all lit up and apparently working, though with no screen I was unable to confirm this.
c2494345: your fix made no difference on my laptop.
With Xfce as the DE, the problem still remains. However, since I switched to Mate, suspend via the lid switch and resuming has been working reliably. However, it is only with Mate that this seems to be working. Why the difference? I do not know. What is so different in the way Mate works and Xfce works that the one succeeds and the other fails? If I knew how to figure that out, then it might provide a solution that works for Xfce and, I presume, others like LXDE and Enlightenment also.
I installed Mate desktop but was unable to repeat the success that Stephen reported. The screen remains black on resume after suspend (from closing the lid). I tried KDE desktop but its behaviour is the same as Mate and XFCE. I tried Gnome Classic but it doesn't seem to have any way of setting the behaviour when the lid is closed and nothing happens at all; the screen remains turned on and the computer running.
After the lastest update, my boot option 3.15.10-200.fc20.x86_64 is no more on the list. Is there a quick way to get it back? (since 3.17.8-200.fc20.x86_64 did not solve the issue).
Unfortunately, there does not seem to be a way to get it back. If you want to prevent this from happening in the future (and you have sufficient space in your /boot partition), edit your /etc/yum.conf file to increase the amount of kernels retained. The default is three. The line to change is "installonly_limit=3." I also noticed that this problem seems to be associated with xscreensaver. I removed xscreensaver, and now suspend/resume seems to be working even with Xfce.
To the one who maintains this bug, please update this bug to reflect Fedora 21 as it is affected also.
Thanks. I don't have xscreensaver installed. Tried Mate: the lockup appears to occur less often with Mate. It may have helped a bit if only "automatically remember running applications when logging out" was not broken.
I have installed OpenSUSE on the machine and the problem has disappeared with that version of Linux.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
used 3.18.6-100.fc20.x86_64 for 11 days (25 suspend/resumes)- 2x lockups: 1x black screen, 1x normal fc login screen showing time of suspend. Now with 2nd day on 3.18.7-100.fc20, already had 2x lock-ups (black screen) r
I was able to reproduce this problem in Fedora 21 MATE with two different Apple laptops (macbookAir5,2 MacBookPro11,2). Both of these laptops are using intel video (no nvidia). I could never seem to find a clear crash report, making this issue difficult to track down. POTENTIAL WORKAROUND FOR COMPIZ USERS: 1. Open ccsm 2. Select the 'Display Settings' tab 3. Make sure that 'Sync to VBlank' is NOT ENABLED If this fix works, it might make sense to change the default value for this control option in ccsm as a temporary measure, until full support for 'Sync to VBlank' w/resume can be restored.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
3.19.4-200.fc21.x86_64, Mate DE, and no xscreensaver seems to be working reliably. mate-screensaver-1.8.1-4.fc21.x86_64 is installed, but it does not cause the problem. I still think that xscreensaver causes or contributes to this issue.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 '21'. 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 21 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 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.