High battery discharge rate during suspend / when lid closed KDE

Community Support
1

If I have it fully charged, remove the cable, and then put it in suspend (or close the lid, which suspends) and leave it about 24 hours, the laptop will have suffered a power-loss and the battery be fully drained. While suspended, the laptop can also be noticeably warm.

I’m running KDE on Arch Linux. I read that the HDMI port had significant power draw for some reason, so I’ve ensured I don’t have it attached (currently I have two USB-C, one USB-A, and one Micro-SD port).

I saw someone else appears to have this issue (“Battery life while suspended (lid down) is pretty bad, but that’s not a huge issue for me.” Arch Linux on the Framework Laptop - #37 by Andrew_Walter) but didn’t see a resolution.

Has anybody successfully dealt with this issue?

2

There’s a bug in upower, and possibly elsewhere, that is preventing proper suspend. The GUI buttons in KDE weren’t actually triggering suspend at all for me. Closing the lid as trigger is similarly unreliable in my experience. Not sure on the status of the fix.

I recommend you use hibernate from command line if you have that working (I do) or full shutdown (and make sure it finishes full shutdown until the power button light goes off before lid close) for now.

1 Like
3

Thanks @D.H ! Do you have a ref to the bug so I can follow it?

4

Discussion here

https://bbs.archlinux.org/viewtopic.php?id=274292

1 Like
5

Thank you.

Based on the discussion in that thread, people are observing that their system is not entering a suspend mode successfully. However, if I execute journal-ctl | grep suspend I get logs that appear to show that the system is indeed suspending:

May 23 00:07:13 framework kernel: PM: suspend entry (s2idle)
May 23 00:45:51 framework kernel: printk: Suspending console(s) (use no_console_suspend to debug)
May 23 00:45:51 framework kernel: PM: suspend exit
May 23 00:45:51 framework systemd[1]: systemd-suspend.service: Deactivated successfully.
May 23 00:45:51 framework audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 23 00:45:51 framework audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 23 00:45:51 framework kernel: audit: type=1130 audit(1653284751.576:170): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 23 00:45:51 framework kernel: audit: type=1131 audit(1653284751.576:171): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

and reading from /sys/kernel/debug/suspend_stats I see:

success: 4
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
  last_failed_dev:

  last_failed_errno:    0
                        0
  last_failed_step: