Hibernate not working after the latest lts kernel update

rexdrive · 2017-03-09 04:12:41

This is what happens with me:

- I boot into Arch Linux (lts kernel)
- Do something
- Hibernate using `systemctl hibernate`
- Wake from hibernate
- Get stuck on a black screen
- Force shutdown my laptop
- Start again

Can anybody please tell me how to view the error messages logged after this unsuccessful wake from hibernation? So that I can see what's wrong and if need arises, report a bug.

Some information -
WM - I3
Login via xinit

muz · 2017-03-09 14:23:41

I think we have the same problem, as I described here yesterday :

https://bbs.archlinux.org/viewtopic.php?id=223903

Do you also have the same issue with suspend? If there is more than one of us this should be easier to track down.

I have the same wm (i3) and xinit login too.

Last edited by muz (2017-03-09 14:24:04)

rexdrive · 2017-03-09 15:39:21

muz wrote:

I think we have the same problem, as I described here yesterday :
https://bbs.archlinux.org/viewtopic.php?id=223903
Do you also have the same issue with suspend? If there is more than one of us this should be easier to track down.
I have the same wm (i3) and xinit login too.

But suspend/resume works perfectly for me. I only have problems with hibernation.

muz · 2017-03-09 16:26:43

Right, but mine suspends/resumes fine 9 out of 10 times too. I also noticed yours does not wake up whereas mine does not go to sleep proper.

But both issues being sleep related and induced by the same update in linux-lts, I think there is a good chance they are related.

swipe · 2017-03-10 09:01:03

I also have this issue in 4.9.13-LTS but not in 4.9.11-1. Neither suspend nor hibernate work at all in 4.9.13-LTS, it attempts to and then just bombs back to the lock screen. This is on an 8 year old HP 6710b laptop Core2 Duo with 4GB RAM.

rexdrive · 2017-03-11 06:51:56

The problem persists in the latest kernel 4.10.1-1.

Also, the error doesn't have anything to do with Xorg or any login manager, since, the error persists even when hibernated from console.

journalctl shows upto the message of successful hibernation but since I have to force shutdown, it doesn't show any error message thereafter. It starts logging again with the new boot messages

codedmart · 2017-03-11 15:04:30

I seem to be having this problem with the latest upgrade as well. I don't use hibernate, but suspend has been working fine 100% of the time for me since I installed Arch (about 6 months ago). Now I can't resume from suspend at all. Any further information on this?

vt220 · 2017-03-12 14:16:22

I can add that in my case the problem occurs only on 0x86 (Atom N280) but not on 0x64, and only hibernation doesn't work (suspend works). Both the regular and lts kernels are affected (4.9.13 & 4.10.1 - 4.9 had the problem from the beginning when it still was a regular kernel)

If I run 'journalctl --list-boots' before hibernating, then start a machine, wait until it becomes stuck, then turn the machine off and on to force a reboot and finally run 'journalctl --list-boots' again after the machine starts, I see that the boot which became stuck is not present in the list of boots (only one line is added to the list - the line for the latest boot), which means that the problem occurs somewhere very early in the boot process - at the time before systemd had a chance to start. It probably means that special techniques will be required to understand the problem, since regular logs are absent.

The only workaround I see for the time being is to switch to a previous lts version (4.4.51) or to any other pre-4.9 kernel.

rexdrive · 2017-03-13 12:20:19

vt220 wrote:

I can add that in my case the problem occurs only on 0x86 (Atom N280) but not on 0x64, and only hibernation doesn't work (suspend works). Both the regular and lts kernels are affected (4.9.13 & 4.10.1 - 4.9 had the problem from the beginning when it still was a regular kernel)
If I run 'journalctl --list-boots' before hibernating, then start a machine, wait until it becomes stuck, then turn the machine off and on to force a reboot and finally run 'journalctl --list-boots' again after the machine starts, I see that the boot which became stuck is not present in the list of boots (only one line is added to the list - the line for the latest boot), which means that the problem occurs somewhere very early in the boot process - at the time before systemd had a chance to start. It probably means that special techniques will be required to understand the problem, since regular logs are absent.
The only workaround I see for the time being is to switch to a previous lts version (4.4.51) or to any other pre-4.9 kernel.

Is it secure to use older kernels?

swipe · 2017-03-13 12:39:40

vt220 wrote:

The only workaround I see for the time being is to switch to a previous lts version (4.4.51) or to any other pre-4.9 kernel.

4.4.53 LTS is in the AUR under Linux-LTS44

arielinux · 2017-07-19 05:34:58

Anyone still having this issue?
I'm seeing the same symptons on Fedora (25 and 26). Suspend/Resume works perfectly, Hibernate/Resume hangs at resume time. No encryption on swap or root.
Currently on kernel 4.11.10-300.fc26.x86_64; this used to work in Fedora 24 and earlier.
Using amdgpu driver, and an NVME ssd. Tried various variations (swap partition, swap file, no_console_suspend in Kernel options) but can't find anything clear in the journal

Last edited by arielinux (2017-07-19 05:43:10)

WorMzy · 2017-07-19 05:50:59

Arielinux, Fedora is not Arch, you should seek support on the Fedora forums.

seth · 2017-07-19 06:25:07

As for the original problem though, see https://bbs.archlinux.org/viewtopic.php?id=225918
Remove "quiet" or "splash" or anything itr. from the kernel cmdline and see whether you get a "Hibernate inconsistent memory map detected" error message.

@swipe, this has nothing to do with *getting* into hibernation which is more likely of a permission issue (eg. because you're still using dbus-launch and thus don't become the active user?)
@codemart/muz, this also has *no* relation to resume from S3 (suspend to RAM) which might relate to some kernel module (nvidia has a record on this track) or even microcode uploads (where the solution is to *prevent* micorcode loading, passing "dis_ucode_ldr" to the kernel) - or something entirely different ... hard to say but i'd start by isolating the multiuser target, unload as many kernel modules as possible and try the behavior on this rudimentary condition.

Arch Linux

#1 2017-03-09 04:12:41

Hibernate not working after the latest lts kernel update

#2 2017-03-09 14:23:41

Re: Hibernate not working after the latest lts kernel update

#3 2017-03-09 15:39:21

Re: Hibernate not working after the latest lts kernel update

#4 2017-03-09 16:26:43

Re: Hibernate not working after the latest lts kernel update

#5 2017-03-10 09:01:03

Re: Hibernate not working after the latest lts kernel update

#6 2017-03-11 06:51:56

Re: Hibernate not working after the latest lts kernel update

#7 2017-03-11 15:04:30

Re: Hibernate not working after the latest lts kernel update

#8 2017-03-12 14:16:22

Re: Hibernate not working after the latest lts kernel update

#9 2017-03-13 12:20:19

Re: Hibernate not working after the latest lts kernel update

#10 2017-03-13 12:39:40

Re: Hibernate not working after the latest lts kernel update

#11 2017-07-19 05:34:58

Re: Hibernate not working after the latest lts kernel update

#12 2017-07-19 05:50:59

Re: Hibernate not working after the latest lts kernel update

#13 2017-07-19 06:25:07

Re: Hibernate not working after the latest lts kernel update

Board footer