Please, improve the S0ix experience under Linux

Project Discussion
21

I have started looking into S0ix again today.

I have filled a bug on kernel.org:

https://bugzilla.kernel.org/show_bug.cgi?id=217603

22

@mariolimonciello

Yes, I believe what makes sense here would be systemd having some kind of database storing the stats about suspend, since it already deals with session and power anyway.
Also, if at some future point Linux ends up supporting waking from S0ix for doing some tasks and then going back to sleep, that would likely also end up being managed by systemd.

This is likely LVFS and being uploaded by fwupd.

I already noticed that it can send anonymized hardware data as well as anonymized HSI (basically the security features status from firmware + OS). So, it could very well have suspend data as well.
Since the LVFS already ships the firmware drivers from some OEMs, it should be possible to contact them in case itā€™s their firmware to blame for the suspend failures.

23

Hmm, @rhughes what do you think? If we managed to get systemd to capture suspend data into a database would it make sense to let fwupd access that data and report it to LVFS?

24

I donā€™t know; itā€™s feature creep and we have to justify it using the existing LVFS privacy policy. I guess what we could do is collect more details in the existing HSI sleep attribute and then upload that as part of the ā€œfwupdmgr securityā€ scan on the logic we want to get people to use s2idle when possible.

25

A few other thoughts about using LVFS for this.

  1. Only the command line client (fwupdmgr) currently uploads anonymous data to LVFS. Even if we ended up using LVFS for this purpose, I suspect that removes a very large amount of data. Itā€™s tangential to this threadā€™s problem, but I think the three graphical GNOME clients (gnome-software, gnome-control-center and gnome-firmware) should grow support for uploading data too.
  2. Uploads only happen when actions happen to make the data change. For example if someone ran fwupdmgr update and updated firmware or fwupdmgr security and something changed from last time theyā€™ll be prompted to upload data. Whereas suspend cycles happen constantly. How frequent should suspend data be uploaded?

IMO:
Step 1 is figure out which telemetry data is useful to be collected with each sleep cycle.
Step 2 is get systemd to start collecting this.
Step 3 is get a way to present this data to a user (GNOME?)
Step 4 is get a way to get this data uploaded to a consumable web service.

26

Another option for collecting such data is Fedoraā€™s in-the-works telemetry.

1 Like
27

So another thing you may wish to check ā€“ may be specific to my laptop.
On Linux & Windows, while suspended, if I jolt vigourously for 3 seconds my laptop, it exits S0idleā€™s ā€œmemā€ suspend (on Linux appears to be easier to trigger).

Using echo freeze > /sys/power/state makes this harder to happen, but still happens.

YMMV

Laptop: Thinkpad L13 Yoga (2-in-1/convertible)

28

Is there anything in the logs that gives the reason for the wake?
Any chance the lid opened just a tiny bit and triggered an lid open event?

29

Pretty certain I did not. I usually shake it holding the whole laptop with the two hands.

If you canā€™t reproduce it please do ignore. It may be just a model or machine quirk.

If anyone can reproduce it: maybe some forgotten sensor for harddisk parking is doing stuff. Nothing shows up in the logs though (journalctl).

30

Today I finally gave up on S0ix on my system, after keeping it enabled for a while.

Basically, more often than not, a failed suspend can happen with S0ix sleep enabled.
Sometimes this wonā€™t cause problems, other times the session will break in subtle ways or in catastrophic ways (likely something in logind broke) such as: flatpaks will refuse to launch, some of the options in GNOME power menu will disappear and I wonā€™t be able to shutdown neither via GNOME nor via systemctl.

It seems thereā€™s no point in keeping using something as broken as that on my system unless there are better tools to report these problems so it can be properly fixed.

In anyway, I reverted to using mem_sleep_default=deep for S3 sleep and I hope to not have problems anymore. Just as a note, Iā€™m using the very latest BIOS firmware available.

1 Like
31

Can I ask, earnestly, what is the best-case energy consumption that S0ix can achieve in the near future?

I just bought a ThinkPad, my first new laptop in several years. Ironically for me, suspend was one of the things I was most looking forward to (my old laptop was physically damaged and suspend was not working properly). Now I find myself sorely disappointed at the battery drain, but letā€™s say thatā€™s improved. Whatā€™s the ceiling for that in the short-term?

32

Hi Mauricio,

Which ThinkPad and what numbers are you getting? (and BIOS/EC version is useful once I know which platform it is).

In my experience - expect to see between 0.3 and 0.6W during sleep. If youā€™re seeing anything significantly above that let me know and we can debug.

Mark

33

FWIW, I enabled the modern suspend via fwupd on this Ryzen 7 laptop and your script mostly works now, but complains about Kernel lockdown being engaged and it appears to be missing some headers for the ACPI BIOS checks. Otherwise, the suspend itself triggered by your script worked for me.

34

If you think there are some problems with the script, please file a bug at AMD DRM (gitlab.freedesktop.org) with the details. Iā€™m open to any adjustments if it makes it more accessible.

35

My primary point is that it appears to more or less be working on this AMD system. (I say more or less because itā€™s working fine AFAICT, but the script gives an ACPI Error stack trace at the bottom around missing symbols.)

Ref.

In my case, I hadnā€™t enabled it with fwupd yet.

36

Hi Mark,

Thank you for your kind answer. TL;DR is my issue may have gone away.

Just got a Carbon X1 (Gen 11, BIOS N3XET42W 1.17); I put it to sleep for the first time while traveling and came back to see ~20% battery drain (in about 12h, so ~1W/h). Now, reading more carefully maybe thatā€™s not crazy high (certainly thereā€™s reports of more severe drain) but it was high enough that I looked it up and ended here.

Now, Iā€™ve tried some troubleshooting (e.g. I found a report from one user blaming WWAN; I didnā€™t get my laptop with a broadband card but I turned it off anyway) and have tested it a few more times. Iā€™m consistently getting around 0.25W/h on sleep, which is on the low end of what youā€™re telling me to expect. Iā€™m not sure how to test it more thoroughly, but the current performance seems reasonable.

Thanks again for the reply and apologies if I came off poorly. My first experience was disconcerting.

37

Hi!

On my case ( ThinkPad L13 Yoga Gen 2 / 20VKCTO1WW ) the issues with modern standby were due to the laptop waking up fully and not suspending afterwards.

Through a Ubuntu Mate post and trial and error, I decided to disable all wakeup sources except for keyboard / USB (XHCI) and power button (SLPB).

On Fedora 38, Iā€™ve a good sleep status with the following script:

$ cat /etc/systemd/system/acpi-wake.service

[Unit]
Description=ACPI Wake Service

[Service]
Type=oneshot
ExecStart=/bin/sh -c "for i in $(cat /proc/acpi/wakeup|grep enabled|awk '{print $1}'|xargs); do case $i in SLPB|XHCI);; *) echo $i|tee /proc/acpi/wakeup;; esac; done"

[Install]
WantedBy=multi-user.target

and

$ sudo systemctl enable --now acpi-wake.service

This way, disabling almost everything including the LID (which Iā€™m thinking it is somehow the source of the problem), sleep issues never happen.

Battery should last 2 or 3 days this way (not a full weekend probably, but overnight will).



NOTE: unrelated, but on Fedora 38 there was a bug where the OS ignored the lid close. Seems to be fixed on Fedora 39 (again, waking up on lid open wonā€™t work since I disabled it with the script above but closing the lid now suspends the system).

38

Hi all!

Apparently there is a bug in some Embedded Controllers (EC). Itā€™s a shot in the dark, but you can try acpi.ec_no_wakeup=1 on kernel boot and see what happens with suspend (as in: if it works well).

Though, if skimmed reasonably, ā€œmyā€ script above should also fix most issues by disabling USB. But it never hurts to try.

References/Credits:
Power management/Wakeup triggers [wiki.archlinux.org]

39

@mariolimonciello What can we expect about S0ix for Fedora 40 and the kernel that will be shipped out-of-the-box?

40

Itā€™s taking 6.8 if Iā€™m not mistaken, right? s2idle should work on any AMD hardware that supports s2idle and the OEM enabled s2idle in the BIOS (Hawk Point, Phoenix, Rembrandt, Barcelo, Mendocino or Cezanne). If thereā€™s problems; theyā€™re bugs not lack of feature enablement.

1 Like