battery drain while notebook off / shutdown

[asgard2]

Hello,

my battery drains around 15 to 20 percent a day when shutdown on linux ubuntu.
It is an HP notebook HP 15s-eq0355ng , Ryzen 5 3500U , Vega8 .

Tested:

- with ubuntu 20.04
- Kernel 5.4, 5.8 (hwe) and the current mainline kernel 5.11 (rc4)
- no usb devices are plugged in
- no wake ob lan available
- no USB power when off (checked with optical mouse)
- no visible LEDs are on when shutdown

I reinstalled window 10, when shutdown from windows there is no (visible) battery drain (or significantly lower).

Linux is unusable on this device, if the battery drains in a short time to 0% percent. This cause battery damage ...

---

Tested TLP with default settings and activated DEVICES_TO_DISABLE_ON_SHUTDOWN (bluetooth wifi wwan), same power consumption after shutdown.

Same power consumption on 20.10 (Groovy Gorilla).

---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.14
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: test 953 F.... pulseaudio
 /dev/snd/controlC0: test 953 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-01-24 (0 days ago)
InstallationMedia: Xubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
MachineType: HP HP Laptop 15s-eq0xxx
Package: linux (not installed)
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-64-generic root=UUID=17ad50f6-ec98-46b2-8c2e-c169f9baace8 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.4.0-64.72-generic 5.4.78
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-64-generic N/A
 linux-backports-modules-5.4.0-64-generic N/A
 linux-firmware 1.187.8
Tags: focal
Uname: Linux 5.4.0-64-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/18/2020
dmi.bios.vendor: AMI
dmi.bios.version: F.30
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 86FD
dmi.board.vendor: HP
dmi.board.version: 99.40
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAMI:bvrF.30:bd11/18/2020:svnHP:pnHPLaptop15s-eq0xxx:pvr:rvnHP:rn86FD:rvr99.40:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP Notebook
dmi.product.name: HP Laptop 15s-eq0xxx
dmi.product.sku: 20T63EA#ABD
dmi.sys.vendor: HP

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1912935

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[asgard2 (kamp000x)]

apport information

[Kai-Heng Feng (kaihengfeng)]

Please test latest mainline kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11-rc5/amd64/

[Kai-Heng Feng (kaihengfeng)]

Potential solution:
https://<email address hidden>/T/#m8a1f86c7024264201eac37223594c5d15112ae73

[asgard2 (kamp000x)]

@kaihengfeng
I tested the mainline kernel 5.11, version rc5 has the same battery drain.

How can I test the patch, or is it integrated in rc5?

[Kai-Heng Feng (kaihengfeng)]

Kernel with the patch included:
https://people.canonical.com/~khfeng/lp1912935/

[asgard2 (kamp000x)]

@kaihengfeng
Your kernel is installed. At a first 10 hour test, it stopped on the same percentage. With the previous kernel impossible.

I will check again tomorrow!

But I have no wifi or other network connection, the module is not building (same on the mainline kernel).

Would be an integration to the current ubuntu release possible?

[asgard2 (kamp000x)]

@kaihengfeng
Awesome, battery is still on the same percentage. I need this fix.

[Kai-Heng Feng (kaihengfeng)]

The author is going to work on an alternative approach.

[asgard2 (kamp000x)]

@kaihengfeng

Thanks for your support, is there any update in this issue?

[Michael Rickmann (mrickma)]

@asgard2 and @Kai-Heng Feng
Thank you for working this out. I have the same type of notebook as asgard2 has and the same problem, using Manjaro though. The notebook is seemingly powered off and looses 10% battery charge over night. I tried 5.4, 5.10 and 5.11 kernels. Hopefully an ACPI-specific patch will arrive at lore.kernel.org soon. The patch for the preliminary fix seems to consist of one line of code only and is contained in the thread Kai-Heng cited in #22. May be it is time for a bit of private enterprise.

[Nolt (nolt)]

Same here I have HP 15s-eq0057nw, tried almost everything and battery drain exist while I shutdown laptop from Ubuntu. If I reboot to Windows and shutdown from Windows there is no battery drain. So for now I unfortunately have to dualboot to Windows and shutdown from Windows.

[asgard2 (kamp000x)]

@Nolt
Booting to Windows is not required, your can press the power button from grub menu.

@kaihengfeng
I'm concerned, no update in months and it seems to affect a lot of devices. Most of the users may not notice the increased energy consumption with daily use in home office.

[Nolt (nolt)]

@asgard2
Didn't tried that but I will today. Rebooting to another OS only to shut it down is horror, I needed Windows only to upgrade BIOS (had a hope maybe this resolve mine issue). And yea I live with this bug since October 2020, back then I upgraded to alpha Ubuntu 21.04 because I thought maybe in new kernel issue has been fixed but unfortunately nope.

[Kai-Heng Feng (kaihengfeng)]

Nolt, is your laptop also AMD based?

[asgard2 (kamp000x)]

@kaihengfeng
You mean, maybe only amd devices are affected?
If I search the web, the "HP 15s-eq0057nw" always has an amd core (Ryzen 5 3500U).

[Kai-Heng Feng (kaihengfeng)]

Can you please give this kernel a try:
https://people.canonical.com/~khfeng/lp1912935-d3cold/

[asgard2 (kamp000x)]

@kaihengfeng

Thank you for your help.

Shutdown with this kernel (linux-image-5.14.0-rc6+_5.14.0-rc6+-1_amd64) at ubuntu 20.04:
12h - 7% battery decrease
23h - 13% battery decrease
Unfortunately there is no improvement in energy consumption.

... speaking of battery damage, had to be replaced in the meantime :(

[Nolt (nolt)]

@kaihengfeng
Sorry for delay reply. Yes mine laptop is based on AMD Ryzen 5 3500U with integrated Vega 8. (HP Laptop 15s-eq0035nw)

[Aarne Rantala (aarantal)]

My laptop is HP Pavilion 15-CS3816NO, based on Intel i5 (_not_ AMD Ryzen). The problem is intermittent - when I powerup it after two days poweroff sometimes battery has drained 2%, sometimes 26%, so I have to powerup the laptop at least twice a week just in order to prevent battery damage.

I have a USB mouse connected to a USB-A port practically always, internet connection is through cable and no WLAN access points are defined. About every other time I back up stuff to an external disk (USB-C) but I have not found any correlation between USB backups and battery drain.

[asgard2 (kamp000x)]

@kaihengfeng
Please let me know as soon as you have a new kernel to test.

[Hemanth V. Alluri (hypro999)]

Hello. I would just like to mention that I, too, face this same exact issue. I'm running Manjaro and can confirm that I observe this issue on both Linux 5.10.70-1 and Linux 5.13.9-2. After a full week of testing I can confirm that I face this power drain only when gracefully shutting down from Linux.

Basic hardware specs:
  OS: Manjaro Linux x86_64
  Host: HP Pavilion Laptop 15-cc1xx
  Kernel: 5.10.70-1-MANJARO
  Resolution: 1920x1080
  DE: Plasma 5.22.5
  WM: KWin
  CPU: Intel i7-8550U (8) @ 4.000GHz
  GPU: Intel UHD Graphics 620
  GPU: NVIDIA GeForce 940MX

Bios: InsydeH20 f.36 Rev 5

Some timings I've recorded:
  - 44% drain in 9h20m
  - 36% drain in 6h48m
  - 32% drain in 5h35m

When sifting through the system logs using journalctl I didn't find anything that stuck out as unusually suspicious. No errors as far as I can tell - but honestly, I don't know enough about Linux to be 100% sure so please don't hold me to this. I can attach these logs if needed.

Commands used:
  - journalctl -b -1 -r
  - journalctl /sbin/init -b -1 -r | grep -i shutdown
  - journalctl /sbin/init -b -1 -p err..alert

Like asgard2 I can confirm that I do not have wake-on-lan enabled (my system doesn't support it in the first place as confirmed by the lack of an option in my UEFI menu and no indication from ethtool), no usb ports providing power when shutdown, no noticible power drain when shutting down from the UEFI menu or from Windows, etc. basically everything they have reported above.

I'd love to help get this fixed - if I can help out by providing more data, please let me know.

[Hemanth V. Alluri (hypro999)]

Oh, I should mention that I faced the same issue when running Ubuntu 18.04 (DE: XFCE) last year. Sadly, I don't recall which version of the kernel I was running - the damage to my battery ended up getting so bad that by the end of the year, my battery lost it's capacity to hold charge and I had to replace it (got warnings from OEM software on Windows, as well as on boot - before the bootloader menu loaded).

[Hemanth V. Alluri (hypro999)]

I've collected some more data and it seems to suggest that maybe suspend/sleep has something to do with this?

=========

Test 1:
  1. Boot (and wait a few seconds after signing in).
  2. Suspend/Sleep (using the "sleep" button from Manjaro/KDE's GUI).
  3. Wait 20 seconds.
  4. Wake from sleep.
  5. Wait 20 seconds again.
  6. Poweroff (and not the time and percentage just before doing so).
  7. Wait a few more seconds before closing the lid.

Result:
  12% drain (100% -> 88%) in exactly 2 hours powered off.
  Note: All of the data points from my previous comment were done with Sleep/Suspend being one of the steps of my test workflow. In this new version of the test, I test for a shorter period of time and have not opened any applications during the test workflow.

=========

Test 2:
  1. Boot (and wait a few seconds after signing in).
  2. Open some applications and use them a bit (Firefox, VS Code, Yakuake, FZF) - about 1 or 2 minutes.
  3. Close all applications.
  4. Poweroff (and not the time and percentage just before doing so).
This time I forgot to wait a few seconds after powering off before closing the lid (but I *did* at least wait till all the lights turned off)

Results:
  2% drain (88% -> 86%) in exactly 6 hours powered off.
  1% drain (32% -> 31%) in exactly 9 hours powered off.

Results when I don't open any applications:
  1% drain (44% -> 43%) in exactly 2 hours powered off (run 1).
  So it seems like opening applications doesn't have anything to do with this (as expected).

=========

Test 3:
(no formally described steps this time)

Results when I force powered off from my bootloader menu (currently, that's rEFInd):
  1% drain (47% -> 46%) in exactly 2 hours powered off.

Results when I shutdown from my BIOS/UEFI menu (interrupt the boot process and go straight to the UEFI menu):
  0% drain (100% -> 100%) in exactly 6 hours and 20 minutes powered off.

=========

Conclusion:

I'm pretty sure that there's no BIOS v/s Bootloader issue here and that the difference in the rate of battery drain is negligible. I'm also pretty sure that as long as I don't let my laptop sleep/suspend on Manjaro (running Linux 5.10 or Linux 5.13) it's fine.

Could this help in identifying the source of the bug?

Could someone else please conduct similar experiments so that we can cross-validate the results? Perhaps someone on Ubuntu or some other operating system that's *not* Manjaro (just so that we can rule out the operating system as a variable in this)

Once again, please let me know if I can help by collecting more data/logs/etc.

[Hemanth V. Alluri (hypro999)]

I ran one more test (twice) since my last comment.

Following the resolution of a StackExchange answer I found [1], I can confirm that when I run Manjaro on Linux 4.14.248-1, even with sleep/suspend, I don't face any heavy overnight battery drain.

==========

Test 4:
  1. Boot (and wait a few seconds after signing in).
  2. Open some applications and use them a bit (firefox, yakuake, konsole, nvim, node) - about 1 minute.
  3. Close all applications.
  4. Close the lid of my laptop to trigger sleep/suspend (I'm sure that closing the lid does indeed cause the OS to sleep - confirmed by double checking the corresponding setting from the system settings UI as well as from the journalctl logs).
  5. Wait for around 10-20 seconds.
  6. Open lid and sign back in.
  7. Wait 10 seconds.
  8. shutdown and wait for 5 seconds after all of the lights have gone out before closing the lid.

Results:
  - 2% drain (58% -> 56%) in exactly 4 hours powered off.
  - 2% drain (100% -> 98%) in exactly 17 hours and 33 minutes powered off (yes, that's 17 (seventeen) hours - not a typo).

Conclusion:
  - We now have a "last stable" version and a "known broken" version, it's possible for one to begin bisecting the kernel version that introduced this issue.
  - I understand that this bug report is for Linux/Ubuntu, but seeing as to how it's now clear that this is due to the Linux Kernel itself and not the distro, my data should still provide some degree of value here despite it being collected on a Linux/Manjaro.

==========

[1] https://unix.stackexchange.com/questions/409774/manjaro-on-hp-laptop-battery-drain-while-powered-off

[Hemanth V. Alluri (hypro999)]

Narrowed it down a bit.

4.19.208-1 does not exhibit any battery drain issues when sleeping sometime before powering off.
  - 0% in 7 hours (97% -> 97%)
  - 0% in 5 hours (100% -> 100%)

5.4.150-1 does.
  - 54% in 10 hours (91% -> 37%)
  - >34% in 12 hours (34% -> Dead)

Could someone else with this problem double check my results with their laptop?

[Martien Lagerweij (mlagerweij)]

I can confirm that this affects my HP Elitebook 1030 G1 laptop with Intel Core m7-6Y75 processor.
OS: Ubuntu 20.04.3 LTS
Kernel: 5.11.0-40-generic #44~20.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021

[asgard2 (kamp000x)]

still the same problem at ubuntu 22.04 with kernel 5.15.0-25 ...

[Martien Lagerweij (mlagerweij)]

Since there is no patch yet, I am using this work-around for my HP laptop (hw/sw details: see #45):
- put this in /etc/default/grub (in my setup it is only changing the default value of that var)
  GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=! \"acpi_osi=Windows 2015\" "
- then run this command to update the grub menu config:
  sudo update-grub2

@kaihengfeng
Any progress on the rework of the patch?

[asgard2 (kamp000x)]

@mlagerweij
I tried this by editing the grub boot settings, unfortunately it doesn't make a difference on my hardware, the battery is drained.

So far, the only option is to choose no shutdown to prevent rapid discharge, which is annoying.

[Martien Lagerweij (mlagerweij)]

Somehow it did make a difference a couple of times, but unfortunately not always: the last time I thought I had it configured the right way finally by adding the 'acpi_osi=!' part, and it did work after the first reboot and shutdown. But then after I read your last comment #48 I noticed again the drain.

So now I am left with the only thing that works at the moment: the HP laptop power reset, where I shutdown the laptop as usual, and then when it is off I unplug everything and hold the power button for 30 seconds. That work-around is fortunately reliable.

Hopefully the kernel fix will still come.

[Kai-Heng Feng (kaihengfeng)]

Please give this patch a try.

[Martien Lagerweij (mlagerweij)]

Thank you! Building the latest kernel (5.15.0-33 on Ubuntu 22.04) with your patch included. Will report back as soon as I have tested it (will be within a couple of days).

[Martien Lagerweij (mlagerweij)]

There was a compile error that I could easily fix:

/home/martien/kernel/linux-5.15.0/drivers/pci/pci-driver.c:516:17: error: implicit declaration of function 'dev_pm_domain_detach' [-Werror=implicit-function-declaration]
  516 | dev_pm_domain_detach(dev, true);
      | ^~~~~~~~~~~~~~~~~~~~

So I had to add this to pci-driver.c:

#include <linux/pm_domain.h>

Kernel still building, will report after I have tested the patch.

[Michael Rickmann (mrickma)]

Hello Kai-Heng, hello Martien,
thank you for your efforts. I am here on Manjaro affected by this bug. My hardware is the same as in the description of this bug. I compared (a) standard Manjaro 5.17.9 kernel, (b) same with Kei-Heng’s 0001-PCI-Detach-PM-domain-on-shutdown.patch (#50), and (c) with the original patch published on lore.kernel.org (see #22 of this thread). Battery state was recorded after 10 – 11h shutdown from /sys/class/power_supply/BAT0/capacity. Power consumption during startup was neglected. Extrapolated 24h-power drain was for (a, standard) 14.4%, (b, 0001...patch) 14.9%, and (c original patch) 2,4%.
Sorry for these results,
Regards Michael

[Martien Lagerweij (mlagerweij)]

I can confirm that the patch did not help prevent battery drain while the laptop was off.

@Kai-Heng, do you think that the patch could work when placing it in the core.c file as mentioned in #22 and not cause the previous issue with NVIDIA Tegra of that original patch?

[Kai-Heng Feng (kaihengfeng)]

I'd like to find out which power resource needs to be turn off.
Can you please find out which module needs to be unload before shutdown can avoid the battery drain?

[Martien Lagerweij (mlagerweij)]

Did not manage to do a first test with all modules unloaded (many are in use), so made a simple script that runs rmmod on all loaded modules, logs the result and then shuts down the laptop.
Running unmodified 5.15.0-33-generic Ubuntu kernel at the moment. To be able to use "rmmod -f" I would have to rebuild the kernel with CONFIG_MODULE_FORCE_UNLOAD=Y, but maybe the modules that can be unloaded now will already help find the culprit.
Battery drain is usually around 2% per day, so will report back in a couple of days.

[Ayush Kumar (kumarayush2102)]

I have hp pavillion au624tx and facing the face issue, which is very annoying. It consumes 3% of my battery each hour !!

I think, it is something related to power-profiles-daemon, is it possible to switch cpu frequency to balance mode while it is shutting down ?

[Martien Lagerweij (mlagerweij)]

@kaihengfeng, the first test with unloading a limited amount of modules (due to rmmod -f limitations) did not result in 0% battery drain. So the next step would be a modified kernel that allows unloading all modules (see #56). Do you maybe have another suggestion of how to find out which module needs to be removed just before shutdown to avoid the battery drain?

[Kai-Heng Feng (kaihengfeng)]

I think `modprobe -r` may work better. Can you please list what modules are unloaded so we can rule them out?

[Martien Lagerweij (mlagerweij)]

Thank you for your answers. My latest version of the script already uses modprobe -rf (earlier version had rmmod).
Am constrained at the moment in terms of time due to personal circumstances, but hope to send you within 1 week a list of modules that can be ruled out.

[Martien Lagerweij (mlagerweij)]

No progress in ruling out modules, but have a very interesting finding to report:

My laptop (see #45) is dualboot with Windows 11 and Ubuntu 22.04 LTS. Somewhere I read that powering down from Windows could result in 0% drain and with the previous Windows 10 that I had installed as other OS that was the case sometimes. BUT with Windows 11 I have the same issue as with Ubuntu 22.04 LTS: around 2% battery drain per day.

So my analysis at the moment is: could be the battery is slowly getting worse OR could be a hardware/driver issue that plagues both OS-es.

One more option to consider: boot the laptop with another OS (e.g. FreeBSD), shutdown and measure the battery drain again.

Please share your feedback. Thanks in advance.

[Martien Lagerweij (mlagerweij)]

p.s. in the meantime i can still use the workaround as mentioned in #49: the power reset. that one still works perfectly, so i can rule out the bad battery in my case. hopefully the module that causes the drain can still be found.

[solax (solax76)]

Hi everyone,
this morning, as usual since few months, battery was at 30% after normal switchoff yestarday.
I have restarted my notebook, went into bios setup, then exit and restarted. Battery was at 100%.

I did this test because I had the same behaviour few days ago, but I have realized only today what happend.
Could you do the same test to see if this is a common behaviour?

I usually have a discharge of 3% per hour, but now I'm thinking that this is not real. I have a Dell machine, and battery diagnostics says it is excellent.

[Kai-Heng Feng (kaihengfeng)]

Please see if the following kernel can solve the issue:

https://people.canonical.com/~khfeng/lp1991663-take2/

The kernel puts ACPI devices to low power mode.

[Martien Lagerweij (mlagerweij)]

Thank you for this kernel, just booted with it and will report to you the outcome later.

[Martien Lagerweij (mlagerweij)]

Outcome of testing with your kernel 6.5.0-2007-oem:
1) with your kernel batttery drain is 8% in 4 days;
2) with Ubuntu 22.04 6.2.0-37 kernel also 8% in 4 days;
3) with power reset workaround (see #49 above) it is 2% in 4 days.
So my conclusion is that 6.5.0-2007-oem has same battery drain still.
Hope this helps you find a good solution.