System: dell-xps13-sputnik-2014 (Intel i7-4650U), 8GB ram, NO SWAP SPACE (maybe relavant?) OS: Kubuntu 14.04 x86_64 with kernel 3.16.0-17 In systemsettings->power-management I set suspend-to-ram on lid-close event. Then when closing the lid, the laptop seems to suspend (blanks screen) but cpu stays on and system freezes with no possibility to restore (also sshd does not respond). The only option is forcing shutdown by holding power button. Besides, a simple 'sudo pm-suspend' in the terminal works just fine. Reproducible: Always Steps to Reproduce: 1. set suspend-to-ram on lid-close in systemsettings->power-management 2. close the lid Actual Results: partial suspend and system hang Expected Results: the same as using pm-suspend
please close this bug, it's not powerdevil fault since also pm-suspend sometimes freezes the system :(
I know this is not related to KDE but wanted to point out that I randomly got the same issue, also on a Dell XPS 13. Using openSUSE Factory with kernel 3.16.4-1.g7a8842b-desktop. I also have no swap space set. I've enabled it now and we'll see whether it solves the issue in the long run. Roberto, did you report this issue in other places ? Kernel bug ?
This is with KDE 4.14.1-1.2.x86_64. Note that before switching to openSUSE Factory I used openSUSE 13.1 and it worked correctly there, so possibly a regression.
Hi Vincent, I have not reported anywhere, because I was thinking about an hardware problem. It is unlikely that linux cannot shutdown a system... What do you think?
I'm not sure. We'd need to find how powerdevil is doing the suspending. You said that pm-suspend always work ? I haven't tried it yet but will later. If pm-suspend works and not powerdevil we need to look at what happens in between, maybe find related logs which could contain clues.
In my case also pm-suspend doesn't work, see Comment #1 above. In fact, I think powerdevil calls pm-suspend via dbus, so it's the same. I've noticed that standby and shutdown work if the system is just powered on, while if you wait some time (half an hour or something like this) then they no longer work.
PowerDevil uses systemd's login1 interface, so if pm-suspend (which is something different) works, then systemd is to blame. If neither pm-suspend works, it must be a kernel or even HW issue.
Vincent, could you please test pm-suspend?
The version on which it worked was openSUSE 13.1 x86_64 with KDE 4-4.11.5 and kernel 3.11.10-21-desktop. And it's now broken on openSUSE Factory x86_64 with KDE 4.14.1-1.2 and kernel 3.16.4-1.g7a8842b-desktop I'll do some tests and post results.
Created attachment 89117 [details] Successful pm-suspend log Tried pm-suspend three times and it worked fine. See attached log. Next up: make it crash then get the log.
Hmmm... suspend to ram worked now from KDE. Here is the list of programs I have opened, for reference: - kopete: disconnected - wifi - owncloud sync client - kmail - konsole And in case it matters, I have the vboxdrv module loaded at all times. Also note: I have enabled the swap partition, but it didn't prevent it to crash. My filesystem is btrfs.
Vincent: let the PC with power on for one hour or more, and then try pm-suspend
I've now started the following: - skype - kopete: connected - apache 2 - mysql - thunderbird Talk about murphy's law or heisenbug... suspend to ram now still works properly. I'm pretty sure it will hang again when I least expect it. Roberto, if you managed to hang it again, can you post pm-suspend.log ? I'll do the same as soon as I can reproduce the issue again, as you say maybe it will happen after a few hours. You mentioned that in your case pm-suspend also crashed once, so it is likely that the problem is on the kernel side. Please let me know whether you also had some of the apps I mentioned above loaded (including vboxdrv), in case it's all related.
In my case the pm-suspend log is the same when it works and when it doesn't: pm-suspend always finishes the procedure without errors or crashes, but sometimes at the end the system hangs instead of actually suspend (or shutdown).
Good to know. I have now set pm_trace to 1 to hopefully capture more info from the next crash, if it happens. See https://wiki.ubuntu.com/DebuggingKernelSuspend
Created attachment 89126 [details] Failed pm-suspend.log It happened again, when running pm-suspend directly. I've attached the log. It looks the same as the successful one, except that it stops at: Tue Oct 14 13:11:03 CEST 2014: performing suspend INFO: using built-in quirks database from HAL. INFO: S2RAM_OPTS from HAL quirks: ' '. But the successful one goes one line further before waking up: /usr/lib/pm-utils/sleep.d/99video suspend suspend: success. Mon Oct 13 19:53:58 CEST 2014: performing suspend INFO: using built-in quirks database from HAL. INFO: S2RAM_OPTS from HAL quirks: ' '. KMS graphics driver is in use, skipping quirks. Mon Oct 13 19:54:12 CEST 2014: Awake. The additional row missing from the broken one is: KMS graphics driver is in use, skipping quirks.
Just checked dmesg from before the crash but there is no relevant info. The last entries are from a few hours before... not sure whether they got "eaten". I could imagine that suspending prevents buffers to be flushed to disk. I guess for now the only thing we can do is try different combinations of software / desktop env and possibly kernel modules... until the problem isn't reproducible a few days in a row. Roberto, did you also use powertop to optimize battery life ? Do you also have a BTRFS root partition ?
I raised a ticket in the kernel tracker: https://bugzilla.kernel.org/show_bug.cgi?id=86241 I suggest to continue the discussion there.
I used powertop a few times in the past weeks, and then switched to tlp. Of course I have tried to disable tlp to see if that helps (it doesn't). My filesystem is ext4.
Looks like an upstream issue. Thanks Vincent for filing a kernel bug, please continue the discussion there.