S3 sleep / suspend to ram on Ubuntu 18.04

[tophneal]

Anything running Debian Bullseye is, assuming you used my installer and didn't change it afterwards, configured to do something called suspend-to-idle.

It means that when the laptop is asked to suspend to memory the kernel will prevent any tasks from being scheduled and close down most of the device drivers. Then it just waits... in other words is relies on normal kernel power management (cpufreq, cpuidle, etc) to minimise standby power. In principle by eliminating wakeups then we ensure that cpuidle can descend to it's deepest sleep state.

Is this something you added to the kernel, or was it already part of tsys'? (I've done a little mucking around in my Manjaro install, so if it was I probably wouldn't see it now lol)

[wasgurd]

Anything running Debian Bullseye is, assuming you used my installer and didn't change it afterwards, configured to do something called suspend-to-idle.

It means that when the laptop is asked to suspend to memory the kernel will prevent any tasks from being scheduled and close down most of the device drivers. Then it just waits... in other words is relies on normal kernel power management (cpufreq, cpuidle, etc) to minimise standby power. In principle by eliminating wakeups then we ensure that cpuidle can descend to it's deepest sleep state.

There are some power savings in this state (for example all the radios will get turned off) but they are pretty modest. I compared an s2idle system against a system doing nothing with the backlight turned off... s2idle ended up saving about a watt. So, not completely useless, but if I am going away for more than an hour I generally do a real power off instead.

It is configured this way because I wasn't able to get the system to turn back on after going into a deeper suspend state. There are some power savings but more importantly the laptop shouldn't hang when you close the lid: most desktop environments are configured to automatically suspend on lid-close and adopting s2idle means we don't have to hack each one separately to avoid the suspend.

Could you clarify please, how to change s2idle to suspend to ram/disk? I want to test how it works for me.

[altacus]

Anything running Debian Bullseye is, assuming you used my installer and didn't change it afterwards, configured to do something called suspend-to-idle.

It means that when the laptop is asked to suspend to memory the kernel will prevent any tasks from being scheduled and close down most of the device drivers. Then it just waits... in other words is relies on normal kernel power management (cpufreq, cpuidle, etc) to minimise standby power. In principle by eliminating wakeups then we ensure that cpuidle can descend to it's deepest sleep state.

There are some power savings in this state (for example all the radios will get turned off) but they are pretty modest. I compared an s2idle system against a system doing nothing with the backlight turned off... s2idle ended up saving about a watt. So, not completely useless, but if I am going away for more than an hour I generally do a real power off instead.

It is configured this way because I wasn't able to get the system to turn back on after going into a deeper suspend state. There are some power savings but more importantly the laptop shouldn't hang when you close the lid: most desktop environments are configured to automatically suspend on lid-close and adopting s2idle means we don't have to hack each one separately to avoid the suspend.

Could you clarify please, how to change s2idle to suspend to ram/disk? I want to test how it works for me.

If you used the unofficial debian installer and want to switch from s2idle as the default suspend mode, remove the following file (or move it somewhere else for backup).

/etc/tmpfiles.d/force-s2idle.conf

Reboot, then check the default

cat /sys/power/mem_sleep

You want to see

s2idle [deep]

If the brackets are around s2idle. Do the following.

echo deep > /sys/power/mem_sleep

Note if you run into permission issues, try doing a sudo. If the permission issue persists, do a sudo su. Then try again.

Once this is set, test out suspend

echo deep > /sys/power/state
or try (if mem_sleep was set to deep upon reboot)
systemctl suspend

Then verify the output

sudo journalctl |grep suspend

 



I noticed that suspend is much more reliable with the terminal command.