Announcement

**skyfishgoo** · Feb 07, 2025, 02:33 PM

having similar issues with the plasma suspend feature under power management... when asleep that way overnite the machine will completely brick

and when i use the term brick, i am not exaggerating... i've had to RMA the motherboard to get the CMOS replaced.

the workaround i've come up with is detailed here

https://discuss.kde.org/t/tracking-d...om-sleep/29090

**hexintor** · Feb 07, 2025, 03:16 PM

I appreciate the response. My first preference would be to get s2idle (S0) working since that seems to be the modern way things are going, but I would be okay with using S3 Suspend-to-RAM. In fact I tried that, but it did not seem to change the behavior or fix the wake up defect when plugging in the USB monitor while in the sleep state. To be fair, I am not 100% sure I actually set the S3 Suspend-to-RAM correctly.

#1 I don't see any indication in Kubuntu's Power Management to configure S3 Suspend-to-RAM. I only see "Do Nothing"/"Sleep"/Shutdown". I see in the documentation there's an additional option for type of Sleep, '...additional drop-down setting to select the exact sleep mode to enter when "Sleep" is activated' but the described additional drop-down is not shown on my system.

#2 I attempted to manually configure S3 Suspend-to-RAM by writing "deep" into /sys/power/mem_sleep per https://www.kernel.org/doc/Documenta...wer/states.txt I confirmed [deep] shown in the output after writing, but after a reboot, /sys/power/mem_sleep output reverted back to [s2idle]. Not sure if Powerdevil is doing something, or systemd is doing something, or what?

**claydoh** · Feb 07, 2025, 04:28 PM

Originally posted by hexintor View Post

but after a reboot, /sys/power/mem_sleep output reverted back to [s2idle]

yes, this needs to be made permanent. What you edited doesn't survive a reboot, since it isn't a physical or persistent file.

THIS is a bit easier to follow and has more info and things to try. It may be a systemd service edit, or a grub kernel parameter.

**hexintor** · Feb 07, 2025, 05:42 PM

Thanks. Unfortunately S3 is not working either. Per the instructions linked, "Confirm that your hardware does not exhibit issues with S3 sleep by testing a few sleep cycles after changing the sleep method". It's good to know if it did work that there is a way to sustain it through systemd, so thank you for that.

When I sleep after enabling S3, it appears to go to sleep correctly (slow blinking LED), but waking resume does not work. For what it's worth, there is a difference from the S0 s2idle behavior. For S3, regardless of USB Monitor connection, the system appears to try to wake because the power LED light goes from blinking to solid on, as if it woke up. But the laptop screen does not turn on (stays black).

In contrast on the original s2idle S0 side, the LED continues to blink slowly when trying to wake resume after connecting a USB monitor. Completely unresponsive.

Any thoughts on which one of these methods I have the best chances of getting to work relative to effort of debugging? The link posted also suggests that even if "deep" is listed in /sys/power/mem_sleep, which it is on my system, it may still not be supported. So my gut is to continue to explore getting S0 s2idle to work. In theory from what I have been reading S0 s2idle is "Software" based, so it should be obtainable regardless of vendor hardware.

**skyfishgoo** · Feb 07, 2025, 07:27 PM

S0 is the working state, not a sleep state.

s2idle is the S2 state and is faster to go into and come out of than suspend to disk (S3)

if you run cat /sys/power/mem_sleep it will show you the sleep state supported by your firmware and kernel with the current default shown in [ ]'s, but those only apply when the power state of mem is called.

cat /sys/power/state will list the power states that are called you issue the suspend command

if freeze is listed first then it should go into s2idle, but my machine would not wake up when freeze was called i made edits to

/etc/systemd/sleep.conf

to remove the word freeze from the SuspendState= parameter and just relied on mem

mem coupled with MemorySleepMode= will also determine which state of sleep your machine will go into when suspended

if you have mem combined with deep then it will go into S3

if you have mem combined with s2idle then it will go into S2 but that's the same as freeze and may be why it's not working.

what happens if you issue the command

sudo systemctl suspend

does it suspend and resume as you expect or does that have the same issues as the plasma suspend?

also examine the file /proc/acpi/wakeup to see if there are any S2 or S3 states listed by your firmware and also verify the contents of cat /sys/power/disk which may have [platform] as the default

you may even want to add the SuspendMode=suspend parameter to your sleep.confg so that it does not have to rely on ACPI features you may not have.

**hexintor** · Feb 07, 2025, 08:14 PM

Thank you so much. I don't know why I kept calling S2Idle S0, it's literally in the name: S2. Sorry. My method for enabling S3 was described in my previous post (#5), and it resulted in worse behavior than s2idle because the wake resume did not turn on laptop monitor screen regardless of usb connectivity. I'll tinker with your systemd sleep conf setting recommendations but here's the current state, of note /proc/acpi/wakeup seems suspicious? XHCI appears to be USB related, and the issue involves plugging in a USB monitor while under s2idle. I'll have to do more research on the function of acpi wakeup file.

cat /sys/power/mem_sleep
[s2idle] deep

cat /sys/power/state
freeze mem

/etc/systemd/sleep.conf (default?)
[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#MemorySleepMode=
#HibernateDelaySec=
#SuspendEstimationSec=60min

grep -E 'S2|S3' /proc/acpi/wakeup
XHCI S3 *enabled pci:0000:00:14.0

cat /sys/power/disk
[disabled]

**claydoh** · Feb 07, 2025, 08:56 PM

so, have you tried setting it via a boot parameter (in Grub)?

**hexintor** · Feb 07, 2025, 10:18 PM

Originally posted by claydoh View Post

so, have you tried setting it via a boot parameter (in Grub)?

My understanding based on THIS is setting mem_sleep_default=deep kernel parameter is only needed to make S3 permanent. I tested S3 manually by writing to /sys/power/mem_sleep and described the failing conclusions above. So I don't understand why I would want to make it permanent if it doesn't work. I don't see any notation stating that the kernel parameter assignment is the only/required way to enable the S3 state.

Is that the boot parameter you are referring to? or am I missing something. Thanks.

**claydoh** · Feb 07, 2025, 10:38 PM

Originally posted by hexintor View Post

My understanding based on THIS is setting mem_sleep_default=deep kernel parameter is only needed to make S3 permanent.

yes, it is an alternate method of doing the same thing as the systemd edit.
You also can set different choices, not just :"deep". That is just one example.
Just something to try if the systemd one isn't working on your specific hardware and kernel combo.

a couple of years back, this is what we had to do for AMD based and some Intel Chromebooks to not lock up or some other bad thing, but which one to try differed for each board. The systemd sleep options had zero effect on these

**skyfishgoo** · Feb 08, 2025, 08:57 AM

the cat /sys/power/disk result indicates you have secure boot turned on in your firmware preventing you from hibernating.

if you turn that off and check /proc/acpi/wakeup again, what does it say about S4?

rather than writing to those /proc files directly, it's better to issue the systemctl command and make your changes to the sleep.conf file by removing the comment #'s

this is what mine looks like

[Sleep]
MemorySleepMode=deep
AllowSuspend=yes
AllowHibernation=yes
AllowSuspendThenHibernate=yes
AllowHybridSleep=no
SuspendState=mem
HibernateState=disk
SuspendMode=platform
HibernateMode=platform shutdown
HibernateDelaySec=2h
#SuspendEstimationSec=60min

a script is run after period of inactivity that issues the command

sudo systemctl suspend-then-hibernate

this will put my machine into S3 for 2hrs and then wake up and move everything to the suspend to disk (S4) state (its a desktop so i don't need to check on the battery state of charge).

**hexintor** · Feb 09, 2025, 01:29 PM

Happy super bowl day and thanks to all who are sharing a small part in my misery (okay it's not that bad) troubleshooting my HP Elitebook with Kubuntu 24.10

Results from suggestions so far, if I missed anything please let me know.

1.) sudo systemctl suspend with current state/default settings as shown in post #7

Result: Going to sleep state continues to work. Resuming after connecting USB monitor cable also worked ONCE, then repeating the exact same process immediately after (unplug usb, systemctl suspend, plug in usb monitor, unresponsive) failed. This is an ongoing battle with s2idle. Sometimes it will work 2,3 times in a row and then it doesn't. What gives!? In some sense this gives me hope, but in another sense it's demoralizing.

2.) turn off secure boot

sys/power/disk changed as you suspected - Just a call out here, i'm not interested in disk hibernation, but I'm happy to troubleshoot what you wish. Long term in a perfect world I like your strategy of suspend-to-ram then hibernate, but if I can't S2 or S3 working, then what's the point?)

cat /sys/power/disk
[platform] shutdown reboot suspend test_resume

grep -E 'S2|S3' /proc/acpi/wakeup
XHCI S3 *enabled pci:0000:00:14.0

grep -E -i 'enabled' /proc/acpi/wakeup
XHCI S3 *enabled pci:0000:00:14.0
RP09 S4 *enabled pci:0000:00:1d.0
TXHC S4 *enabled pci:0000:00:0d.0
TDM0 S4 *enabled pci:0000:00:0d.2
TRP0 S4 *enabled pci:0000:00:07.0
TRP1 S4 *enabled pci:0000:00:07.1

Result: sudo systemctl suspend resume still not working

3.) Modify /etc/systemd/sleep.conf

config: deep (S3)

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
SuspendState=mem
#HibernateMode=platform shutdown
MemorySleepMode=deep
#HibernateDelaySec=
#SuspendEstimationSec=60min

Result: USB Monitor connection problem irrelevant. Resume fails to turn on laptop screen. But power button LED does still turn on, so I assume I could SSH into it, but not a long term solution.

config: s2idle

only pasting changed lines from above config
[Sleep]
MemorySleepMode=s2idle

Result worked once then failed after immediately repeating sleep/resume procedure again.

output of grep -E -i 'enabled' /proc/acpi/wakeup seems to be consistent from above

Summary s2idle resume works reliably with the big exception of connecting the USB Monitor while it is in a sleep state. S3 resume does not work at all.

**skyfishgoo** · Feb 09, 2025, 04:45 PM

new intel... i found a journal entry that looked like this

ACPI: PM: Hardware changed while hibernated, success doubtful!

when i saw it there was no issue with resuming that time but i wonder if some other change in wee hours of the morning is keeping my machine from waking up sometimes

i found that adding this kernel parameter seems to have quelled the error and hopefully prevents the kernel from checking so it won't panic when it finds something has changed

acpi_sleep=s4_nohwsig

just as a lark, try s2 or s3 with this param and see if that changes anything

**skyfishgoo** · Feb 09, 2025, 05:01 PM

also for your sleep.config try this..

AllowSuspend=yes
SuspendState=freeze mem
MemorySleepMode=s2idle

you need to remove the # for an item to be active

the freeze state may work, and if if not then it will try the mem state

the mem state combined with s2idle mode should put it in to S2 state and removing deep prevents it from saving to RAM (S3)

**hexintor** · Feb 09, 2025, 07:50 PM

Originally posted by skyfishgoo View Post

the freeze state may work, and if if not then it will try the mem state

The problem I'm having is resuming these states. Isn't systemd just going to write these values to the files, which I already did? I guess i'm failing to see how systemd is going to provide me any relief here... unless there's some configuration on how it is resuming or what is causing the failure to resume.

At least for S2idle I know it's being caused mostly due to USB3 connection while asleep, so it's fair to consider it is something related to USB controller. Originally I tested the devices except for the monitor independently and they all were fine and didn't cause resume issues. So it's evidently narrowed down to USB interplay with a monitor.

Is there a way I can disable the ability for the usb monitor to be involved with sleep or sleep resume?

Announcement

Sleep (s2idle) Unresponsive After Plugging in USB3 Monitor

Sleep (s2idle) Unresponsive After Plugging in USB3 Monitor

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment