Bug 1213830

It's expected; many modern systems support only s2idle.  The traditional S3 or others are legacy features and many new systems dropped them.

The high energy consumption is a different problem, though.  All depend on the driver implementations, and some might be missing the handling of the proper runtime PM.

You can try the latest upstream kernel from OBS Kernel:stable:Backport repo, and check whether the problem persists.  If yes, report to the upstream and handle there.

i still dont feel very comfortable adding many repos or lowlevel hardware stuff after all these years

is it this repo address?

<https://download.opensuse.org/repositories/Kernel:/stable:/Backport/standard/>

for leap 15.5?

reading
<https://en.opensuse.org/SDB:InstallNewerKernel>

and having installed

kernel-default package 6.4.7-lp154.4.1.g8de9301 x86_64

doesnt seem to help getting beyond s2idle.

needed to disable secure boot as well in uefi-bios settings of this notebook.
didnt enroll MOK and all this stuff if thats got anything to do with it.

As mentioned, s2idle is the right mode for many modern systems.  Some BIOS still allowed legacy S3 or such, but that's what vendor decides.

IOW, the use of s2idle is *NO* bug, per se.  It's the feature of modern laptops.
The problem is only that you might see high power consumption if all drivers don't play nicely with the runtime PM, and that should be addressed.

thanks for the information. more questions.

i put the notebook to suspend last night and closed the lid. right now reopening it again.

now grepping for "suspend" in journalctl -b   it shows like tens of events of wakeup and re-entering suspend again and again over like maybe every half hour or so, irregularly

i had assumed that when a user puts the machine into this suspend (s2idle then) it would stay in that state until the lid opens or a key gets pressed.

is this in and out of suspend state maybe another issue? thanks.

It's difficult to answer without seeing the actual log.

In general, s2idle is relying on the runtime PM of each component.  Some uneducated drivers might spew messages at runtime PM and look as if it were suspending, too (although it should be more silent).  Or, it might be some bug.

so just to make sure, a normal application (firefox running, and element riot chat client as real opensuse application) can not re-wakeup the machine, right? nothing fancy going on here.

i would really like to know if the screen during such times, would turn back on, and then later sleep again. but the lid is closed and I have not really watched the machine over hours just to see some backlight shine through some gaps of the notebook body and lid.

maybe i will sleep the machine with lid opened and observe if the screen comes back every now and then.

what kind of logs and lines exactly would be needed to find out what (component?) ends the s2idle state?

thanks.

No, no, everything should work as expected like before.  The only difference of s2idle is that the explicit deep sleep is replaced with the runtime suspend of each driver.  The wake up should work as the runtime resume of each driver, as well.

If anything doesn't work, *that* should be reported, instead.  It's more likely a bug of each individual driver / component.  You're scratching a wrong surface.

Note that s2idle was known to be problematic in the past because many drivers didn't follow the runtime PM properly.  But, basically it's a bug of those drivers, and the situation became better nowadays, as it's fixed for most drivers.

So i just selected sleep from the KDE menues/icons and left the notebook lid open. I have briefly fetched some lines, it slept only for 10minutes or so:

i have ended firefox, element/riot and pretty mucb everything except for the KDE desktop before sleeping the machine.


> journalctl -b | grep suspend

Aug 02 10:20:36 ipv6address ModemManager[1582]: <info>  [sleep-monitor] system is about to suspend
Aug 02 10:20:38 localhost.localdomain systemd[1]: Starting System Suspend...
Aug 02 10:20:38 localhost.localdomain systemd-sleep[8889]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Aug 02 10:20:38 localhost.localdomain systemd-sleep[8862]: Entering sleep state 'suspend'...
Aug 02 10:20:38 localhost.localdomain kernel: PM: suspend entry (s2idle)
Aug 02 10:31:29 localhost.localdomain kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 02 10:31:29 localhost.localdomain kernel: PM: suspend exit
Aug 02 10:31:29 localhost.localdomain systemd-sleep[8952]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Aug 02 10:31:29 localhost.localdomain systemd[1]: systemd-suspend.service: Deactivated successfully.
Aug 02 10:31:29 localhost.localdomain systemd[1]: Finished System Suspend.
Aug 02 10:31:29 localhost.localdomain systemd[1]: Reached target Suspend.
Aug 02 10:31:29 localhost.localdomain systemd[1]: Stopped target Suspend.


maybe now I can look into more lines of journalctl -b  between those two timestamps if you can tell me what I should look for or how to proceed with this?

this cezanne based laptop

> AMD Ryzen 7 5800U

still has sleep/lid-clode etc troubles, and today I acome across this post:

> <https://lore.kernel.org/platform-driver-x86/20231212045006.97581-1-mario.limonciello@amd.com/>

that speaks directly about cezanne lid/sleep problems of a different kind. I wonder if opensuse leap 15.5 kernel has that (which patch exactly?) other patch for cezanne power mangement stuff applied?

or if not, can you please apply? backport?
leap 15.5 and default up to date kernel, doesnt keep this cezanne laptop in sleep mode, and additionally when closing the still open lid of the laptop, the laptop wakes up (keyboard light) still a way (angle) before the lid is fully closed and the keyboard light stays on. weird.

thanks lots for all the efforts.