When I click “Sleep” in the start menu, there is about a 1 in 4 chance that it hangs instead of sleeping. The monitor turns off, but fans continue to spin, and the system is stuck in this seemingly unrecoverable state and must be rebooted.
I found a clue in logs. sudo journalctl | grep suspend.entry reveals that each time the system goes to sleep correctly, there is the line kernel: PM: suspend entry (deep). Each time it hangs, there is the line kernel: PM: suspend entry (s2idle). OK, my mobo doesn’t seem to support s2idle in the BIOS so it makes sense that it hangs when s2idle mode is used. But whatever, I can just use “deep” mode right?
As shown by cat /sys/power/mem_sleep, the default sleep mode is deep:
s2idle [deep]
I ran a script to log the output of that command once per minute, to make sure it is not getting changed. But the default mode is always the same, even preceding the moment the system tries to sleep using the wrong mode.
I tried running systemctl suspend from the command line a few times and it always used the correct mode. Though I haven’t tried it enough times to be sure that it always works. Anyway, to get to my KDE-specific question, I wonder if the problem could be specific to the “Sleep” option in KDE’s menus. Maybe it does something more complicated that systemctl suspend. So does anyone how to find the source code to see what clicking “Sleep” in KDE’s start menu does?
1 Like
my recommend would be to edit your /etc/systemd/sleep.conf file and remove freeze from the list of things to try.
my default looked like this
[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#MemorySleepMode=
#HibernateDelaySec=
#SuspendEstimationSec=60min
uncomment the SuspendState=mem standby freeze line and remove the word freeze
that way it should always use mem which should default to deep
if not then you may need to also uncomment the line MemorySleepMode= and add deep to it.
finished it would look like
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
SuspendState=mem standby
#HibernateMode=platform shutdown
MemorySleepMode=deep
#HibernateDelaySec=
#SuspendEstimationSec=60min
unless you also want to hibernate, then it gets more complicated.
2 Likes
If I do sudo bash -c 'echo freeze > /sys/power/state', that indeed reproduces the symptoms of my issue: suspend entry (s2idle) in log, screen turns off, fans keep running. So I have a good feeling about the proposed solution. Thank you very much!
I suppose I have a bug to report to systemd, that it decides that “freeze” is viable, but only at random.
this definitely seems like a bug (plasma or kernel?) in that it is supposed go on to the next thing if the first option fails… what sort of test it uses to know in advance that a given method is a “fail”, i couldn’t say, but it seems to be picking up some false positives.
the reason i came to this solution was because my new build with a MSI motherboard would fail to wake from sleep… and removing the freeze option seemed to solve the problem
until it didn’t and i moved on to trying other things (including: down grading from 24.10 to 24.04, 3 RMAs of the m/b and switching to different brand of m/b altogether, and switching PSU brands as well)
seem stable now, but i’m afraid to undo this initial fix for fear or starting the whole cycle all over again, and your experience only adds to that fear so i think i will keep it in place for the duration of the LTS cycle.
For what it’s worth, there’s likely (also?) something that the motherboard manufacturer really ought to do in this situation - the output of cat /sys/power/mem_sleep is the list of sleep states that the hardware tells your OS are available, so if s2idle isn’t actually supported, then it probably shouldn’t be listed as such by the device in the first place.
I personally had this issue with a Lenovo laptop that we bought a couple of years ago, which exhibited very similar behavior to what you’re seeing - but under Windows 11 - and also “falsely advertised” its supported sleep states to the OS. On that device, I basically had to do the Windows equivalent of what @skyfishgoo demonstrated, and override the OS’ determination to force it to never try the unsupported state.
what’s even more perplexing is that when i use cat /proc/acpi/wakeup on either m/b i’ve had the opportunity to test, the only supported state is S4.
there are no lesser suspend states listed yet they will suspend to ram (S3) just fine.