Unable to configure suspend-then-hibernate on new installation of -current

Hi all,

I have recently installed -current from a Liveslack image on my laptop (MacBook Pro 12,1). It is working great and I have sorted out most of the small issues (mostly to do with resuming from sleep - WiFi driver sometimes failing after resuming from sleep, out-of-tree module for FaceTimeHD webcam causing the kernel to crash after resuming from sleep). However, I cannot get suspend-then-hibernate working. I am interested in getting this working mainly because I often close my laptop and leave it for days - if it runs out of power while sleeping, the system clock loses power and resets; I have no idea how much of a pain this would be under Linux versus under macOS ...

Does anyone have any advice for getting suspend-then-hibernate working? Thank you all and much appreciated in advance!

A few details about my system:

• I have a full install of Slackware -current
• I am using KDE Plasma 5
• I have a handful of other Slackbuilds, mainly user programs - ufw, Spotify, etc.
• I have an out-of-tree module installed for FaceTimeHD, but I do not load this module anywhere - I was loading it in rc.modules.local, but it was causing issues when suspending the system so I commented that line out. It is not currently loaded
• In the System Settings under 'Power Management'>'Energy Saving'>{'On Battery','On Low Battery'}, I have the box "While asleep, hibernate after a period of inactivity" checked. I do not have the "Suspend session automatically after n minutes" box checked (or the type of suspend menu selected), but I have tested with this box checked as well and no luck
• I can confirm that hibernate itself works - when I go straight into hibernate mode, I can boot my system again and get back to my session, but despite my attempts to change configuration I just cannot get suspend-then-hibernate to work. *edit*: I have just tried to use hibernate mode, and my system wakes up from hibernate immediately ... weird ... *edit2* fixed this, I added a condition to an elogind hook to disable wake-on-lid-open for hibernation

Output from uname -a:

Linux darkstar.example.net 5.10.22 #1 SMP Tue Mar 9 16:42:18 CST 2021 x86_64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz GenuineIntel GNU/Linux

Contents of /etc/elogind/login.conf.d/login.conf (symlinked to a file in my home directory so I don't forget where it is). I copied these fields straight from /etc/elogind/login.conf and haven't uncommented any fields - I assume all the commented-out values are the defaults for elogind. (This is all so I can remind myself of what options are available):

[Login]
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RuntimeDirectoryInodes=400k
#RemoveIPC=yes
#InhibitorsMax=8192

Contents of /etc/elogind/sleep.conf/d/sleep.conf (also symlinked to a file under my home directory). I have uncommented the fields `AllowSuspendThenHibernate' and `HibernateDelaySec'. The HibernateDelaySec is only 30 seconds because I want to test this feature, I will make it something like 30 minutes eventually:

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#AllowPowerOffInterrupts=no
#BroadcastPowerOffInterrupts=yes
#AllowSuspendInterrupts=no
#BroadcastSuspendInterrupts=yes
#HandleNvidiaSleep=no
#SuspendState=mem standby freeze
#SuspendMode=
#HibernateState=disk
#HibernateMode=platform shutdown
#HybridSleepState=disk
#HybridSleepMode=suspend platform shutdown
HibernateDelaySec=30

Contents of /proc/acpi/wakeup:

Device  S-state   Status   Sysfs node
PEG0      S3    *disabled
EC        S4    *disabled  platform:PNP0C09:00
HDEF      S3    *disabled  pci:0000:00:1b.0
RP01      S3    *enabled   pci:0000:00:1c.0
RP02      S3    *enabled   pci:0000:00:1c.1
RP03      S3    *enabled   pci:0000:00:1c.2
ARPT      S4    *enabled   pci:0000:03:00.0
RP05      S3    *enabled   pci:0000:00:1c.4
RP06      S3    *enabled   pci:0000:00:1c.5
SPIT      S3    *disabled  spi:spi-APP000D:00
XHC1      S3    *disabled  pci:0000:00:14.0
ADP1      S4    *disabled  platform:ACPI0003:00
LID0      S4    *enabled   platform:PNP0C0D:00

Output from `loginctl show-session':

EnableWallMessages=no
KillUserProcesses=no
RebootToFirmwareSetup=no
RebootToBootLoaderMenu=18446744073709551615
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
BlockInhibited=handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
DelayInhibited=sleep
InhibitDelayMaxUSec=5s
UserStopDelayUSec=0
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore
HoldoffTimeoutUSec=30s
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
Docked=no
LidClosed=no
OnExternalPower=yes
RemoveIPC=yes
RuntimeDirectorySize=1668739072
RuntimeDirectoryInodesMax=407407
InhibitorsMax=8192
NCurrentInhibitors=5
SessionsMax=8192
NCurrentSessions=1

I don't think it's related, but I have the following udev script in /etc/udev/rules/90-xhc_sleep.rules (again symlinked) to prevent random USB events from waking the system (the system would suspend and immediately resume, and it came down to the XHC1 device). This suspend-then-hibernate issue was there before I deployed this script.

SUBSYSTEM=="pci", KERNEL=="0000:00:14.0", ATTR{power/wakeup}="disabled"

I am running LVM on LUKS, and the image section of my elilo.conf file currently looks like this:

image=vmlinuz
        label=vmlinuz
        initrd=initrd.gz
        root=/dev/cryptvg/root
        append="resume=/dev/cryptvg/swap"
        read-only

I made an initrd using the following command. This was produced by mkinitrd_command_generator.sh, with the addition of the hid-apple module for the keyboard and the `-h' flag for specifying the swap partition for hibernation:

mkinitrd -c -k 5.10.22 -f ext4 -r /dev/cryptvg/root -m usb-storage:xhci-hcd:uas:xhci-pci:ohci-pci:ehci-pci:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-apple:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -C /dev/sda3 -L -h /dev/cryptvg/swap -u -o /boot/initrd.gz

This is how I do it on my laptop.

I'm on slackware64-current, KDE Plamsa 5

I added a file to /etc/elogind/logind.conf.d

[Login]
HandleLidSwitch=suspend-then-hibernate

A file to /etc/elogind/sleep.conf.d

[Sleep]
HibernateDelaySec=3600

This works with runlevel 3 the HybernateDelaySec is also used by Power Management

In System Settings, Power Management, Energy Saving

You need to set Suspend session to Sleep, after what ever time you want
Check "While asleep, hibernate after a period of inactivity."

I also set Button events handling When laptop lib is closed to Sleep.

The period of inactivity is defined by HibernateDelaySec

This works for me at least.

Thanks a lot for your reply chrisretusn, it's very much appreciated.

Your settings didn't quite work for me, but I have determined that what seems to be happening is, if I close my laptop lid for, say 10 seconds with a HibernateDelaySec of 30, and open it back up again everything seems to work normally, but if I close it for a minute and open it up again I get a heap of kernel errors about failing to freeze userspace. I also know it is trying to hibernate at this point because I have an elogind hook triggered by going into hibernate which prints a log saying as much.

What I think is happening is my system tries to hibernate after I have resumed from suspend, and it fails for some reason - eventually I have to reboot because the entire system locks up for 20 seconds at a time. Not sure yet though why it is doing this after I resume from suspend mode and why it fails ...

As far as not waking up and hibernating while in suspend mode, I feel like there might be a missing ACPI trigger to wake my computer up from suspend so it can put it into hibernate, and instead it just realises 'oh, I need to go into hibernate' after it wakes up. With that being said though, when I exit suspend mode, it will still lock up for 20 seconds even before I have logged in ... I will keep looking into this and see if I can find any more leads, maybe time for me to remove my other elogind hooks and introduce more logging to try to figure out what it is doing ...

Originally Posted by uiopqwerty It is working great and I have sorted out most of the small issues (mostly to do with resuming from sleep - WiFi driver sometimes failing after resuming from sleep, out-of-tree module for FaceTimeHD webcam causing the kernel to crash after resuming from sleep).

You add a script to unload and load kernel driver before/after sleep/hibernate in /lib64/elogind/system-sleep. You can use this Gentoo template.

#!/bin/bash
case $1/$2 in
  pre/*)
    # Put here any commands expected to be run when suspending or hibernating.
    /sbin/modprobe -r some_driver
    ;;
  post/*)
    # Put here any commands expected to be run when resuming from suspension or thawing from hibernation.
    /sbin/modprobe some_driver
    ;;
esac

Originally Posted by walecha You add a script to unload and load kernel driver before/after sleep/hibernate in /lib64/elogind/system-sleep. You can use this Gentoo template.

Thanks, yes I did a similar thing - however I am still experimenting because I don't know how much the kernel exceptions I mentioned above have to do with removing this module, I have also been trying removing and re-adding the module in the post) section.

I assume since hibernate works that you have it setup via your boot loader and have enough space for the file.

I use a 2GB (4GB of RAM) swap partition for hibernate. This seem to work well as I don't normally leave a lot open with I go to hibernate.

I use lilo and have a lilo.conf and have an 'append="resume=/dev/sda1"' in the image section.

What I did as show above was it. I tested at a 10 second delay, it when from standby to hibernate fairly quickly. Once it's in hibernate, opening the lid does nothing. I have to push the on/off button, the system boot up to a short boot sequence and then loads the saved information and I'm back were I left off.

I'm not to thrilled that I have to turn on suspend though, seems like I should be able to do this with just closing the lid, which is how it works when I'm in runlevel 3 using the logind.conf settings.

Originally Posted by chrisretusn Once it's in hibernate, opening the lid does nothing. I have to push the on/off button, the system boot up to a short boot sequence and then loads the saved information and I'm back were I left off.

Mine is also doing the same, lid up no wake up, power button does. I'm just using KDE power management, set it to hybrid sleep (suspend + hibernate). I did not edit elogind configuration.

Bloody hell I have done a real number on my machine ... I used to have it so I could suspend with the lid open and hibernate worked, but now suspend only works with the lid closed unless I disable the LID0 switch, and hibernate just doesn't work - while resuming from hibernate, my system reboots shortly after reaching 100% and the screen tears ... I am also getting some concerning looking errors in /var/log/syslog concerning MCE hardware error, maybe my machine is on its way out.

What a mess. I need to have a closer look at this over the weekend. Even if I can't figure out suspend-then-hibernate for now, regular suspend and regular hibernate are better than no hibernate at all.

Well I have regular old hibernate working again and it's not clear exactly how, good grief. Will hopefully report back with some findings in a few days time ...

Edit: I also have regular old suspend working with the lid open again, i.e. I go into suspend with the lid open and it stays suspended, unless I close the lid and open it again or I press the power button. I almost have a feeling that I have a funky piece of hardware which is having problems but I can only guess right now.

I hope some of this problems will be easier to solve with a clean install : should have kept track of my tweaking since I do not really remember all what I've done since I switched to i3wm and we had so much big changes in -current.

ACPI is buggy on my second laptop and I do not master all this new elogind stuff. I bet we'll have to dig into this config files and get used to strange scripts location (/lib64 for instance).

Still not clear to me how bugfixes drizzle down to earlier kernels, but I've noted quite a few ACPI/suspend/resume changes in the kernel changelogs over some time now, so perhaps reset settings and test newer kernel?