Hide Forgot
Description of problem: Workstation "HP Pavilion Elite HPE" Having pushed power button or pm-suspend or "systemctl suspend" - monitor is going blank, workstation is freezing, power button is not changing color indicating suspend. Version-Release number of selected component (if applicable): 4.4.4-200.fc22.x86_64 4.4.4-301.fc23.x86_64 How reproducible: Always reproducible if do suspend 2 times one after another. 75% reproducible if do suspend ones. Steps to Reproduce: 1.Push power button, if suspend is successful - resume and push power button again. 2. "systemctl suspend" resume and do again. 3. pm-suspend resume and do again Actual results: workstation is freezing, monitor is going blank, power button color is blue. Expected results: workstation is suspended, power button color is yellow - indicating successful suspend. Additional info: Workstation "HP Pavilion Elite HPE" [noname@localhost ~]$ dmesg | grep "hash matches" [ 4.597824] hash matches drivers/base/power/main.c:1065 [ 4.597863] acpi device:0e: hash matches [ 4.597877] platform: hash matches
I have the same issue on an Asus RampageII-GENE desktop. First use of suspend to RAM will work after reboot. The second use of "systemctl suspend" sounds like it is working based on what I hear from the disk but the monitor stays fully powered with just an underscore cursor showing. The fans keep running and he USB continues to be powered. Can not wake up system, must use long press of power button to power off. Once booted back up the longs don't indicate any trouble. I keep 3 recent kernels, with only the oldest working properly: vmlinuz-4.4.3-300.fc23.x86_64 == works vmlinuz-4.4.4-301.fc23.x86_64 == Suspend fails on second try vmlinuz-4.4.5-300.fc23.x86_64 == Suspend fails on second try
Found the issue to still exist for me with 4.4.6-300. Current status for me is: vmlinuz-4.4.3-300.fc23.x86_64 == works vmlinuz-4.4.4-301.fc23.x86_64 == Suspend fails on second try vmlinuz-4.4.5-300.fc23.x86_64 == Suspend fails on second try vmlinuz-4.4.6-300.fc23.x86_64 == Suspend fails on second try
I did some bios settings tests and found that I could get fix this issue by disabling "ACPI APIC" support. This does not allow SMP, so I only get one CPU core but it did happen to allow multiple suspend to RAM and resume cycles. Adding this note but I am not confident that anybody is actually reading this so I will do more searching and maybe open my own bug entry with full information on my system.
Workstation "HP Pavilion Elite HPE" 4.4.6-300.fc23.x86_64 == suspend fails on second try
*** Bug 1321427 has been marked as a duplicate of this bug. ***
Created attachment 1141034 [details] lshw report from my system.
Exact same symptoms as in comment 1 on a Dell Latitude E6420 laptop 4.4.6-300.fc23.x86_64 == suspend fails on second try
Just to see for sure I did an install using Fedora-Workstation-netinst-x86_64-24_Alpha-1.7.iso and did a fully default install with the exception of selecting XFCE for the desktop and it also had the issue. It was exactly the same for me, with the bug only showing up on the second usage of suspend.
I found a "fix"... The test this morning was an install that did not select the XFCE desktop. Using: Fedora-Workstation-netinst-x86_64-23.iso Everything was default tho I did use the check box to make myself the "Administrator". I opened a terminal and used "systemctl suspend" as normal and it worked multiple times without issue. 4.4.6-300.fc23.x86_64 == Works when using Gnome instead of XFCE, for me at least. I am don't consider it a fix of course but this should help narrow down where the issue is and point to some non-kernel items that are involved with this bug. Does anybody who is experiencing this bug *not* use XFCE?
Hi Doug, I'm using Gnome (3.18.2) and it fails for me nonetheless.
Just to confirm that in the same setup kernel-4.4.3-300.fc23.x86_64 still works. kernel-4.4.4-301.fc23.x86_64 and following fail on the second suspend after boot.
This issue seems to be fixed for me with the new kernel that installed today: 4.4.7-300.fc23.x86_64 I have suspended to RAM 3 or 4 times so far since rebooting to the new kernel with no problems showing up so far.
Fixed with kernel 4.4.7-300.fc23.x86_64
*********** 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 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. 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 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
There is no manifestation of this bug any more. 4.7.5-200.fc24.x86_64
The bug is BACK as of September 2017. The last three Fedora 26 updates have had the same bug. Acer C720 Chromebook running Open Souce Firmware and Fedora, which worked perfectly until that last major upgrade (three minor upgrades ago). First suspend will work, whether by pushing the button or closing the lid. On second suspend, fan will run and power light stays lit. Suspend never happens and OS is locked tight with blank screen. Only pushing and holding power button or pulling the batter will recover.