https://bugzilla.kernel.org/show_bug.cgi?id=216516 --- Comment #24 from kolAflash (kolAflash@xxxxxxxxxxxx) --- Created attachment 301894 --> https://bugzilla.kernel.org/attachment.cgi?id=301894&action=edit kernel log for s2idle: v6.0-rc7 with bug 216516 comment #14 patches - 23 minutes of s2idle @Mario Yes, it's definitely an intermingled mess... If you have an idea how I can help to untangle this, please give me detailed instructions which tests I should run. If you think this will help, we can have a (video) call about this. Just send me an email with date + time. (I live in UTC+2) Just tell me which (video) call tool you like to use. I'm open for pretty much everything (Jitsi-Meet, Skype, Mumble, XMPP, Matrix, ...) Something about the sysfs and procfs settings I'm doing: This is needed to disable wakeup from USB events in S3 suspend. echo XHC1 > /proc/acpi/wakeup Actually I wouldn't need to set this for s2idle. In future I'll leave this out for s2idle tests. This is needed to prevent the system from waking on keyboard events and on closing the lid. echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup And additionally this is needed to prevent the system from waking on opening the lid. echo disabled > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup (both, i8042 and LNXSYBUS:00/PNP0C0D:00, must be disabled to prevent wake on opening the lid) Additionally, if i8042 and LNXSYBUS:00/PNP0C0D:00 are not disabled, the system tends to wake after some minutes from s2idle. Maybe something between 10 or 60 minutes. I haven't figured out yet if this is related to just one or both settings. So beside the lid open/close, keyboard and AC power events, there must be something else interrupting the suspend. Something which is totally without user interaction, because these wakes also appear if I leave the lid open and don't touch the notebook at all. I rebooted the system and then put it into s2idle for a little more than 23 minutes (1400 seconds). See these lines: Thu Sep 29 00:09:19 CEST 2022 Thu Sep 29 00:33:12 CEST 2022 Everything, including all sysfs setting I made, is documented in the log. And I didn't closed the lid this time. I didn't even touched the notebook during that 23 minutes. These lines suggest, that the system didn't stay in "deepest state" of sleep the whole time. [ 92.340524] PM: suspend-to-idle [ 92.340549] ACPI: EC: ACPI EC GPE status set [ 92.340562] ACPI: PM: Rearming ACPI SCI for wakeup [ 92.364660] Timekeeping suspended for 759.694 seconds [ 92.364660] ACPI: EC: ACPI EC GPE status set [ 92.364680] ACPI: EC: ACPI EC GPE dispatched [ 92.364987] ACPI: EC: ACPI EC work flushed [ 92.364987] ACPI: PM: Rearming ACPI SCI for wakeup [ 92.383963] ACPI: EC: ACPI EC GPE status set [ 92.383981] ACPI: PM: Rearming ACPI SCI for wakeup [ 92.408334] Timekeeping suspended for 331.956 seconds [ 92.408334] ACPI: EC: ACPI EC GPE status set [ 92.408334] ACPI: EC: ACPI EC GPE dispatched [ 92.408340] ACPI: EC: ACPI EC work flushed [ 92.408340] ACPI: PM: Rearming ACPI SCI for wakeup [ 92.429810] Timekeeping suspended for 328.978 seconds [ 92.429810] ACPI: EC: ACPI EC GPE status set [ 92.429810] ACPI: EC: ACPI EC GPE dispatched [ 92.429815] ACPI: EC: ACPI EC work flushed [ 92.429815] ACPI: PM: Rearming ACPI SCI for wakeup [ 92.451340] Timekeeping suspended for 8.978 seconds [...] [ 92.451340] amd_pmc AMDI0005:00: Last suspend in deepest state for 758373565us To it looks pretty much like the deepest sleep was only for the first 758 seconds. The remaining time of the altogether ~ 1400 seconds the system wasn't in the deepest state. I guess that the deepest state has been interrupted by the remnant of what completely wakes the system if i8042 and LNXSYBUS:00/PNP0C0D:00 are not disabled (see above). I set the BIOS to limit the battery to max. 80 %. This usually drastically increases the overall lifetime of lithium-ion batteries. That's what makes the difference between energy-full and energy-full-design in the log. These are the power consumption values: energy-full-design: 53.0145 Wh 22.2222/(53.0145/100) = 41.9 % 20.8824/(53.0145/100) = 39.4 % So about 2.5 % of power (1.3398 Wh) was consumed. If the system was in perfect s2idle, this should have been less than 1% for 23 minutes. Bug 2.5 % pretty much matches about 700 seconds of "bad" s2idle after the initial 700 "good" s2idle seconds in deepest state. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
