Unusually high battery drain while suspended

Ruediga · 2025-01-19 00:17:56

I've recently noticed a significant increase in power consumption during suspension on my Thinkpad E14. Previously, I could leave the system in suspend for several days before it would finally give up, but now I have to either power it off or plug it in in the evening just so it makes it through the night.

Some data

By taking snapshots of the value reported by /sys/class/power_supply/BAT0/energy_now, I've been able to (consistently) measure a drain of about 10%/h, which equates to ~5Wh (stock battery, Sunwoda L22D3PG5). When used for light work, my laptop easily lasts 4-5 hours without needing to be plugged in, so an issue with the battery itself seems very unlikely.

--- TLP 1.7.0 --------------------------------------------

+++ System Info
System         = LENOVO ThinkPad E14 Gen 5 21JK00DQGE
BIOS           = R2AET59W(1.34)
EC Firmware    = 1.34
OS Release     = Arch Linux
Kernel         = 6.6.69-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 22:00:49 +0000 x86_64
/proc/cmdline  = BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=63cf2f0f-9b84-4877-8541-b86edf7cfc09 rw loglevel=3 quiet
Init system    = systemd
Boot mode      = UEFI
Suspend mode   = [s2idle]

+++ TLP Status
State          = enabled
RDW state      = not installed
Last run       = 12:10:59 AM, 2199 sec(s) ago
Mode           = AC
Power source   = AC

What I already tried

By default, only s2idle appears to be supported as a suspend state:

$ cat /sys/power/mem_sleep
[s2idle]

My UEFI does not have any option to enable a proper S3 sleep state (Linux/Windows mode, like some posts I found mentioned), even after an upgrade to the newest version, 0.1.34.
A quick look into journalctl proves that the s2idle state has always been the default on my system, as there are logs like

Jan 18 21:39:08 Thinkpad kernel: PM: suspend entry (s2idle)

going back to June of last year, a long time before the issue initially appeared.

Another guess I had related to spurious acpi wakeup capable interrupts, but after checking /proc/acpi/wakeup nothing looked suspicious to me, and since I haven't ever witnessed random wakeups, I didn't investigate further here. Eitherway, in case it's still relevant, this is what reading the file returns.

Enabling tlp or auto-cpufreq with their default configuration did not have any noticeable effect on suspend power consumption.

I also tried downgrading my kernel (to version 6.7.6), but to no avail.

Switching to hibernation instead is not a viable solution for me, since I suspend and wake my laptop several times a day, and therefore don't want to deal with longer startup times.

Any advice regarding what else to try or debugging what caused this would be greatly appreciated, I've wasted way too much time troubleshooting this already : )

seth · 2025-01-19 16:34:18

When checking the journal, does the system actually remain in S2idle for the expected time?
Lenovos have recently (over the past year) shown up w/ weird lid-related behavior.
Can you keep it suspended for a while w/o closing/touching the lid and see whether you still get high power drain?
(Disabling the LID in acpi/wakeup won't cut it)

Ruediga · 2025-01-19 18:14:24

Yup - as mentioned, no spurious wakeups are happening while suspended, so the system does indeed remain in s2idle for the expected time.

Every time I took these snapshots I suspended via systemctl suspend and woke it by pressing a random key. All of this was done with the lid up to avoid any lid-related unwanted behaviour, but the issue remains regardless.

seth · 2025-01-19 20:23:03

Do you also get this w/ the non-LTS kernel resp. when downgrading the former to an earlier version (downgrading the kernel in isolation is, within reason, "safe" - it's mostly self-contained and only would break with major toolchain changes)

Ruediga · 2025-01-19 21:24:11

Good point, the tlp-stat -s output I posted mentions to the latest lts kernel because I was trying to test it aswell (should have mentioned that). I normally run on the latest linux release:

uname -sr
Linux 6.12.9-arch1-1

and for testing purposes I downgraded to 6.7.6.

Unfortunately, none of these versions made any difference...

Ruediga · 2025-01-20 21:04:51

Tiny update: I've been asked to test on windows, and surprisingly, it uses <1% of battery per hour, as I'd expect Linux to!

C:\Windows\System32>powercfg /a
The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected

The following sleep states are not available on this system:
    Standby (S1)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S2)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S3)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Hibernate
        Hibernation has not been enabled.

    Hybrid Sleep
        Standby (S3) is not available.
        Hibernation is not available.
        The hypervisor does not support this standby state.

    Fast Startup
        Hibernation is not available.

Still out of ideas regarding what went wrong on my linux install, sadly.

Last edited by Ruediga (2025-01-20 21:06:08)

seth · 2025-01-21 16:42:04

In case there's a parallel windows installation see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Ruediga · 2025-01-21 18:37:58

As you can see in the `powercfg /a` output, hibernation and fast startup have been disabled for a long time.

seth · 2025-01-21 20:44:04

Sorry, pawlowian…

Please post your complete system journal for a boot after a notable (>30min) S2idle:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

for the current one or eg. "… -b -1 …" for the previous one.

Ruediga · 2025-01-21 21:53:24

There you go: http://0x0.st/8HGT.txt
(Is the site intentionally http? I can't seem to get a https connection)
In case you're wondering why some log lines like 'freezing userspace processes' appear AFTER being woken, that's simply because the systemd daemon itself gets frozen and can therefore only read the dmesg logs delayed. The timestamps are correct when running dmesg directly.

seth · 2025-01-22 08:09:41

curl -vL https://0x0.st/

dosn't indicate any ssl/tls errors here.

The system successfully enters s2idle, there're no signs of intermediate wake-ups etc. so let's just randomly blame stuff:
1. try to rfkill wifi and BT before the sleep
2. disable thunderbolt (in the UEFI, if you can)
3. Counter-intuitively, limit the c-states: https://wiki.archlinux.org/title/Intel_ … up_from_S3 (iff this works the CPU should still power down for the S2, just now successfully)

Ruediga · 2025-01-22 18:05:40

1) tried, no effect
2) I had a lot of faith into that one, but my UEFI only provides options to:
- enable USB while in standby/at sleep
- turn of pcie tunneling for thunderbolt
first one was already turned off, manually disabled the latter
3) `cat /sys/devices/system/cpu/cpu*/cpuidle/state*/name` reports

POLL
C1_ACPI
C2_ACPI
C3_ACPI

for every single cpu
I wasn't 100% certain what you're asking me to try, so I did what I think you meant,

cpupower idle-set -d 3

to disable the deepest available sleep state. Lead to increased power consumption, presumably because it disallows the proper entry into any low power idle state, but could also be due to measuring inaccuracies caused by my method.

seth · 2025-01-24 17:21:05

The idea was to run "cpupower idle-set -D0" before the suspend and "cpupower idle-set -E" afterwards.
Those settings will temporarily increase the power demand, but the idea was that they might also allow the system to effectively idle (and this way ultimately drastically lower the power demand during the sleep) - however: you can only enter C3??
I'm gonna say that's your problem, do you apply https://wiki.archlinux.org/title/Microcode ?

Ruediga · 2025-01-25 15:40:48

Nope, my microcode is fine, I have the build hook for it set up.

Turns out, the cheap nvme drive I had installed a while ago because i was running low on storage space was the problem. After running tools like https://github.com/intel/S0ixSelftestTool (which complained about my igpu, for some reason?), reading through how-achieve-s0ix-states-linux and linux-s0ix-troubleshooting (maybe these are helpful to someone who encounters a similar problem in the future), I was hopeless enough that I decided to rip out components one by one out of my device. Lo and behold, when I ran the usual tests with that drive removed, battery drain was back to normal again! I have no idea what causes this, the ssd reports to support ASPM, and as I mentioned windows has no issue with it. Maybe windows fully disables it's pcie port once it fails to find any recognized partition types, i don't know.

I'll blame it on the ssd (I have another one that's working fine laying around and will just use this one in my in server) as I don't feel like wasting anymore time on this than I already have. Thanks a lot @Seth for your help.

Last edited by Ruediga (2025-01-25 15:41:44)

seth · 2025-01-25 16:39:31

For ans ssd see https://wiki.archlinux.org/title/Power_ … Management ?
A bunch of drives got afforded med_power_with_dipm - over-optimistically

But for an nvme the problem is usually https://wiki.archlinux.org/title/Solid_ … ST_support

Arch Linux

#1 2025-01-19 00:17:56