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?
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.
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.
Got a new wrinkle this time - it attempted both kinds of sleep states. First I got the suspend entry (deep), then 6 seconds later I got suspend exit and suspend entry (s2idle). I don’t think that happened before.
I had created a customized sleep.conf but it was ignored due to a syntax error. From this exercise, I learned that upon clicking “Sleep”, sleep.conf is parsed 6 times.
you can make your edits right in sleep.conf and just comment out anything you don’t want parsed.
i’m not surprised it parsed multiple times as it tries things in the order listed until success (or what it thinks is success).
this is what my current (working) sleep.config looks like, if that’s any help.
[Sleep]
AllowSuspend=yes
AllowHibernation=yes
AllowSuspendThenHibernate=yes
AllowHybridSleep=no
#SuspendMode=platform
SuspendState=mem
MemorySleepMode=deep
HibernateMode=platform shutdown
#HibernateState=disk
HibernateDelaySec=2h
#SuspendEstimationSec=60min
The SuspendState=mem entry in the configuration seems to be working to prevent the system from entering the bad s2idle state. (The other line I have is not recognized: Unknown key 'MemorySleepMode' in section [Sleep], ignoring.) What it does now sometimes is to fail at entering mode “deep”, then go to the lock screen.
I searched for one phrase from the log, Non-boot CPUs are now disabled, and found many people with the same problems of deep sleep failing and entering a broken s2idle mode (1) (2) (3). There is now a kernel fix to prevent s2idle from being attempted, at least for amdgpu users like me. But I still didn’t find any info about preventing deep sleep from failing, as it keeps doing.
Now I solved it. The relevant log was ahci 0000:11:00.0: port does not support device sleep. I have a SATA SSD drive with data from my old computer. I unmounted it and then sleep worked. I’ve had this drive in there the whole time, but only sometimes have the problem with sleep. So I’ll just unmount it whenever it acts up.