https://bugzilla.kernel.org/show_bug.cgi?id=216516 --- Comment #19 from kolAflash (kolAflash@xxxxxxxxxxxx) --- Created attachment 301886 --> https://bugzilla.kernel.org/attachment.cgi?id=301886&action=edit kernel log for s2idle: v6.0-rc7 with bug 216516 comment #14 patches Mystery solved: Guess what I'm always doing after running "systemctl start suspend.target". Yes, I'm closing the notebook lid. --> And closing the notebook lid is what's waking the CPU! I did a few tests, closing the lid after random times. And "deepest state for" always matched that time. If I don't close the lid, I also get 2 % battery usage per hour with openSUSE-15.4 and v6.0-rc7. I have to do at least echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup Else the notebook completely wakes after a random time. (e.g. 20 minutes) I guess something like a slight mouse movement then wakes it. With i8042 wakeup disabled I can close the lid without the notebook waking up completely. I can see this, because the keyboard backlight stays dark when I slightly look below the lid. And also programs don't start running again and dmesg also agrees. But it looks like nevertheless the CPU is waking from the "deepest state". About my usage behavior: I don't like my notebook to suspend automatically when closing the lid. So I always disable the lid close action in my desktop environment. As a result, I always trigger s2ram manually and close the lid afterwards. About the Ubuntu-22.10 beta and the "echo disabled" wakeup tests: --> Forget about these! I didn't closed the lid when testing Ubuntu-22.10 beta. And I just checked, that Ubuntu-22.10 beta also completely wakes when closing the lid, unless i8042 wakeup is disabled. And I couldn't reproduce the good consumption values after running find /sys/devices/ -type f -name wakeup -exec bash -c 'echo disabled > "{}"' \; when closing the lid. (see comment 15) I probably just didn't closed the lid when doing that test for comment 15. (In reply to Mario Limonciello (AMD) from comment #14) > [...] > 1) Collect the output of > # grep -v foo /sys/firmware/acpi/interrupts/* > 2) Run your suspend > 3) Capture again the output of > # grep -v foo /sys/firmware/acpi/interrupts/* > 4) Compare the two to see which incremented > [...] > The next debugging step will be applying the following patches to 6.0-rc: > [...] I did this and applied the mentioned patches. (4 commits + usleep_range patch) Find the result in the attached log. I closed the lod 22 seconds after s2idle started. Which matches exactly the dmesg output: Last suspend in deepest state for 22133270us OBJECTIVES: 1. Stay in deepest sleep state when closing the lid. (or immediately return to deepest sleep) 2. Identify when else the system might unintentionally leaves the deepest sleep state while the screen stays off. E.g. certain buttons, plug in/out events (USB devices, USB-C docking station, AC power, HDMI, ...) I'll try to think of some tests I can run for this. You'll find the output of find /sys/devices/ -name wakeup -type f -print -exec cat '{}' \; in the attachment. 3. Bring the s2idle power consumption further down below 2 % per hour. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
