[Bug 1213830] New: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it
https://bugzilla.suse.com/show_bug.cgi?id=1213830 Bug ID: 1213830 Summary: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: abittner@opensuse.org QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Hello Opensuse Kernel team, how come that my rather new notebook hardware (hp probook with amd apu, from 2021) does not sleep properly and eats up the battery all the time. barely any difference between when leaving an idle desktop (KDE) sitting around and blanking the screen and when only s2idle sleeping it (lid close, or kde function: sleep) i have tried to make sense of all of this, also reading about the linux folks over at framework-laptop e.g. <https://community.frame.work/t/responded-linux-deep-sleep/2491> all i can find is the value: cat /sys/power/mem_sleep [s2idle] cat /sys/power/state freeze mem disk also added the kernel boot parameter mem_sleep_default=deep command line via yast2 to grub2 or something: ---------- sudo dmesg -e | grep mem_sleep [ +0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto [ +0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto --------------- to sum it up, the system eats away the battery/power at high rates even when sleeping, lid closed etc. how to make this work on leap 15.5 with proper (deep?) memory sleep states and all? is this maybe incompatible with FDE, secureboot? this kernel lockdown stuff? i am not understanding much of this i guess. i am wondering why a really old system and other also older desktop systems just instantly show deep mem_sleep feature activated and working? this system: UEFI ans secureboot system [ +0.109168] smpboot: CPU0: AMD Ryzen 7 5800U with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0) full disk encryption on single nvme drive thanks for helping. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c2 --- Comment #2 from andreas bittner <abittner@opensuse.org> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c3 --- Comment #3 from andreas bittner <abittner@opensuse.org> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c5 --- Comment #5 from andreas bittner <abittner@opensuse.org> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c7 --- Comment #7 from andreas bittner <abittner@opensuse.org> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c9 --- Comment #9 from andreas bittner <abittner@opensuse.org> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1213830 https://bugzilla.suse.com/show_bug.cgi?id=1213830#c10 --- Comment #10 from andreas bittner <abittner@opensuse.org> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com