Description of problem: When sending the laptop to sleep or hibernate, it won't either enter or return the desired state properly. The laptop must then be forced to power-off by holding the power button, and then powered on. This appears to not be a dup of Bug #972881 as it does not depend on selinux being enforcing or permissive, and I don't have the other components mentioned there. It is possible that it has to do with the hardware as I dont have this behavior with my other laptop, an older MSI. Version-Release number of selected component (if applicable): * Fedora Core 20 installed from FC20-1 ISOs, using KDE 4.11-5, up-to-date * Laptop is MSI GS70-20D, this one --> http://de.msi.com/product/nb/GS70-STEALTH.html How reproducible: Send the laptop to sleep or hibernate mode by either closing the lid or selecting that action via startup/Leave menu of KDE Steps to Reproduce: 1. Try to send laptop into either sleep or hibernation using the "Leave" menu of KDE 2. 3. Actual results: It goes into a state where keyboard backlight and power button are alight and fans still working, screen dark, there is no way to get back from here but by power-cycling the machine. Expected results: It should go into the desired state properly, turning off backlighting, turning off the fans, and it should return from the desired state properly w/o necessity of cycling power. Additional info: Am willing to deliver any reasonable data to support this or perform tests as needed.
kde (essentially) just makes calls to systemd suspend, so this is more likely related to general kernel/driver issues related to power management (video is a prime suspect). To fully test, running this (in a konsole) yield different results: qdbus --system org.freedesktop.login1 /org/freedesktop/login1 Suspend 0
(In reply to Rex Dieter from comment #1) > kde (essentially) just makes calls to systemd suspend, so this is more > likely related to general kernel/driver issues related to power management > (video is a prime suspect). > > > To fully test, running this (in a konsole) yield different results: > > qdbus --system org.freedesktop.login1 /org/freedesktop/login1 Suspend 0 Did the qdbus thing. Same as before: screen blank, everything else active, must power-cycle. And I found the following in /var/log/messages: Jan 22 10:17:35 localhost kernel: [ 22.880923] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x418880 [ IBUS ] Jan 22 10:17:35 localhost kernel: [ 22.881056] nouveau E[ PIBUS][0000:01:00.0] GPC0: 0x419eb4 0xbadf1000 (0x3800820c) Jan 22 10:17:35 localhost kernel: [ 22.881083] nouveau E[ PIBUS][0000:01:00.0] GPC1: 0x419eb4 0xbadf1000 (0x3800820c) Jan 22 10:17:35 localhost kernel: [ 22.881110] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0xbadf1008 FAULT at 0x419cc0 [ IBUS ] Jan 22 10:17:35 localhost kernel: [ 22.882612] Ebtables v2.0 registered Jan 22 10:17:35 localhost kernel: [ 22.889294] Bridge firewalling registered Jan 22 10:17:36 localhost kernel: [ 23.618746] IPv6: ADDRCONF(NETDEV_UP): p4p1: link is not ready Jan 22 10:17:36 localhost kernel: [ 23.621220] alx 0000:04:00.0 p4p1: NIC Up: 1 Gbps Full Jan 22 10:17:36 localhost kernel: [ 23.621460] IPv6: ADDRCONF(NETDEV_CHANGE): p4p1: link becomes ready Jan 22 10:17:37 localhost kernel: [ 24.883060] nouveau E[ PGRAPH][0000:01:00.0] HUB_INIT timed out Jan 22 10:17:37 localhost kernel: [ 24.883064] nouveau E[ PGRAPH][0000:01:00.0] 409000 - done 0x00000244 Jan 22 10:17:37 localhost kernel: [ 24.883068] nouveau E[ PGRAPH][0000:01:00.0] 409000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 Jan 22 10:17:37 localhost kernel: [ 24.883072] nouveau E[ PGRAPH][0000:01:00.0] 409000 - stat 0x00000000 0x00000000 0x00000002 0x00000009 Jan 22 10:17:37 localhost kernel: [ 24.883074] nouveau E[ PGRAPH][0000:01:00.0] 502000 - done 0x00000300 Jan 22 10:17:37 localhost kernel: [ 24.883080] nouveau E[ PGRAPH][0000:01:00.0] 502000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 Jan 22 10:17:37 localhost kernel: [ 24.883085] nouveau E[ PGRAPH][0000:01:00.0] 502000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 Jan 22 10:17:37 localhost kernel: [ 24.883088] nouveau E[ PGRAPH][0000:01:00.0] 50a000 - done 0x00000300 Jan 22 10:17:37 localhost kernel: [ 24.883093] nouveau E[ PGRAPH][0000:01:00.0] 50a000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 Jan 22 10:17:37 localhost kernel: [ 24.883099] nouveau E[ PGRAPH][0000:01:00.0] 50a000 - stat 0x00000000 0x00000000 0x00000000 0x00000000 Jan 22 10:17:37 localhost kernel: [ 24.883100] nouveau E[ PGRAPH][0000:01:00.0] init failed, -16 Jan 22 10:17:42 localhost kernel: [ 29.913795] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xd0 [nouveau] returns -22 Please let me know if you need anything else.
Judging from the log, it's the Nouveau driver which is not suspending properly, reassigning.
Can I get your full kernel log before suspending please?
Created attachment 855163 [details] Shutdown to new start as per info request of Ben Skeggs As per request. Hope this is the info needed.
I also can't suspend or hibernate. Hard to say if it the same problem: Aug 17 12:48:45 localhost kernel: [136852.861996] PM: Syncing filesystems ... done. Aug 17 12:48:45 localhost kernel: [136853.303941] Freezing user space processes ... (elapsed 0.002 seconds) done. Aug 17 12:48:45 localhost kernel: [136853.306537] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Aug 17 12:48:45 localhost kernel: [136853.307671] Suspending console(s) (use no_console_suspend to debug) Aug 17 12:48:45 localhost kernel: [136853.308017] sd 0:0:0:0: [sda] Synchronizing SCSI cache Aug 17 12:48:45 localhost kernel: [136853.330926] nouveau [ DRM] suspending display... Aug 17 12:48:45 localhost kernel: [136853.330930] nouveau [ DRM] unpinning framebuffer(s)... Aug 17 12:48:45 localhost kernel: [136853.330936] nouveau [ DRM] evicting buffers... Aug 17 12:48:45 localhost kernel: [136853.330937] nouveau [ DRM] waiting for kernel channels to go idle... Aug 17 12:48:45 localhost kernel: [136853.330971] nouveau [ DRM] suspending client object trees... Aug 17 12:48:45 localhost kernel: [136853.331466] nouveau [ DRM] suspending kernel object tree... Aug 17 12:48:45 localhost kernel: [136854.054623] sd 0:0:0:0: [sda] Stopping disk Aug 17 12:48:45 localhost kernel: [136855.332189] nouveau E[ PDISP][0000:02:00.0][0xc000857c][ffff88023e14e000] fini timeout, 0xc2071008 Aug 17 12:48:45 localhost kernel: [136855.332192] nouveau E[ PDISP][0000:02:00.0][0xc000857c][ffff88023e14e000] failed suspend, -16 Aug 17 12:48:45 localhost kernel: [136855.332196] nouveau E[ DRM] 0xd1500000:0xd15c7c00 suspend failed with -16 Aug 17 12:48:45 localhost kernel: [136855.332222] nouveau E[ DRM] 0xdddddddd:0xd1500000 suspend failed with -16 Aug 17 12:48:45 localhost kernel: [136855.332357] nouveau E[ DRM] 0xffffffff:0xdddddddd suspend failed with -16 Aug 17 12:48:45 localhost kernel: [136855.332942] nouveau E[ DRM] 0xffffffff:0xffffffff suspend failed with -16 Aug 17 12:48:45 localhost kernel: [136855.333187] nouveau [ DRM] resuming display... Aug 17 12:48:45 localhost kernel: [136855.357010] pci_pm_suspend(): nouveau_pmops_suspend+0x0/0xb0 [nouveau] returns -16 Aug 17 12:48:45 localhost kernel: [136855.357014] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -16 Aug 17 12:48:45 localhost kernel: [136855.357017] PM: Device 0000:02:00.0 failed to suspend async: error -16 Aug 17 12:48:45 localhost kernel: [136855.357030] PM: Some devices failed to suspend, or early wake event detected Aug 17 12:48:45 localhost kernel: [136855.368095] sd 0:0:0:0: [sda] Starting disk Aug 17 12:48:45 localhost kernel: [136855.628226] PM: resume of devices complete after 271.170 msecs Aug 17 12:48:45 localhost kernel: [136855.629220] Restarting tasks ... done.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.