Bug 339391 - system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
Summary: system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Kubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Plasma Development Mailing List
Depends on:
Reported: 2014-09-25 18:20 UTC by Roberto
Modified: 2015-02-07 17:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

Successful pm-suspend log (8.98 KB, text/plain)
2014-10-13 17:54 UTC, Vincent Petry
Failed pm-suspend.log (6.87 KB, text/plain)
2014-10-14 12:12 UTC, Vincent Petry

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto 2014-09-25 18:20:37 UTC
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
Comment 1 Roberto 2014-10-04 16:30:18 UTC
please close this bug, it's not powerdevil fault since also pm-suspend sometimes freezes the system :(
Comment 2 Vincent Petry 2014-10-13 12:31:01 UTC
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 ?
Comment 3 Vincent Petry 2014-10-13 12:32:40 UTC
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.
Comment 4 Roberto 2014-10-13 12:43:55 UTC
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?
Comment 5 Vincent Petry 2014-10-13 12:48:37 UTC
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.
Comment 6 Roberto 2014-10-13 13:07:40 UTC
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.
Comment 7 Lukáš Tinkl 2014-10-13 13:37:10 UTC
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.
Comment 8 Roberto 2014-10-13 14:14:40 UTC
Vincent, could you please test pm-suspend?
Comment 9 Vincent Petry 2014-10-13 17:51:21 UTC
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.
Comment 10 Vincent Petry 2014-10-13 17:54:56 UTC
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.
Comment 11 Vincent Petry 2014-10-13 17:57:43 UTC
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.
Comment 12 Roberto 2014-10-13 18:08:16 UTC
Vincent:  let the PC with power on for one hour or more, and then try pm-suspend
Comment 13 Vincent Petry 2014-10-13 18:10:10 UTC
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.
Comment 14 Roberto 2014-10-13 19:22:29 UTC
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).
Comment 15 Vincent Petry 2014-10-13 19:29:37 UTC
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
Comment 16 Vincent Petry 2014-10-14 12:12:49 UTC
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.
Comment 17 Vincent Petry 2014-10-14 12:20:24 UTC
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 ?
Comment 18 Vincent Petry 2014-10-14 12:35:38 UTC
I raised a ticket in the kernel tracker: https://bugzilla.kernel.org/show_bug.cgi?id=86241

I suggest to continue the discussion there.
Comment 19 Roberto 2014-10-14 12:40:12 UTC
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.
Comment 20 Kai Uwe Broulik 2015-02-07 17:00:11 UTC
Looks like an upstream issue. Thanks Vincent for filing a kernel bug, please continue the discussion there.