On kernel 4.14.x and 4.15.x the battery of the notebook drain to 0% after shutdown.
Wake-on lan is disabled and the discharging stop if the battery is physically removed and reinserted (so it's not an hardware failure for sure).
Moreover the problem does not appear on kernel 4.9.x which report 100% of the battery after a day since the shutdown.
I don't know how investigate further the issue but i'm happy to provide some log or other if someone advice me what to log...
I’ve the same problem of battery drain while the notebook is off (from now on: BD) and I’ve been struggling for weeks to solve this problem. At the moment, in my case too the only way to avoid BD, after shutting down the notebook, is to remove/reinsert the battery.
My notebook is a HP Pavilion 15-ak112nl, and the OS is Slackware64 14.2. Since this bug has already been reported (see https://bugzilla.kernel.org/show_bug.cgi?id=198665 ) I didn’t send a bug notification earlier. However, hoping it may prove useful in order to solve this annoying problem, let me point out to your attention few things that I can tell you about BD.
1. As Andrea says, BD is kernel related since it is present on both 4.14.x and 4.15.x kernel, but – for instance – there is no BD on 4.12.x kernel (actually, I’m currently using 4.12.14 kernel and everything works fine).
2. BD is “manufacturer related”. In the past weeks I googled a lot on this matter, and I came to the conclusion that BD affects just some of HP notebooks (in particular, the “gaming” series).
3. BD is not related to data storage device type. Since in my case Slackware is installed on both HDD and SSD, I’ve noticed that BD is present on both storage devices.
4. My notebook is equipped with nVidia Optimus Technology (GeForce GTX 950M graphical + Intel HD Graphics 530) but BD does not seem related to the discrete GPU. I currently use Bumblebee packages and everything works fine on both 4.12.14 and 4.14.x-4.15.x kernels. The recompilation of Bumblebee packages on 4.12.14 or on 4.14.x (or 4.15.x) kernel makes no difference: BD is still present on 4.14.x (4.15.x) kernel, but it is not present on 4.12.14 kernel.
5. In order to solve BD problem, I wasn’t able to find anything of really relevant in dmesg outputs, nor I found something of interest in comparing the kernel configuration files (if it may prove useful, I can upload the diff file between kernel 4.12.14 and kernel 4.14.x config files). However, in the kernel syslog file (i.e., /var/log/syslog) I found the following (apparently interesting) warning message: i801_smbus 0000:00:1f.4: An interrupt is pending! Consistently with this message, before shutting down the notebook I unloaded the i2c_i801 module: at the reboot I noticed that the warning message wasn’t there anymore, but BD was still present.
That’s all. Please, let me know if you need any further information (of course I can give you a detailed description of my hardware configuration, of loaded modules, of software configuration, and so on…).
All the best,
P.S.: as soon as possible I will test the 4.16 kernel (which is still in the rc state)...I’ll let you know...
I tried kernel 4.17.r180422 but bug still present :(
I wanted to test the latest kernel patches before sending an upgrade notification about BD bug ...unfortunately, about two weeks ago my battery “died” – I don’t know if this fact is in some way related to BD: in any case I’m going to replace the battery with a brand new one – and then, at the moment, I can only tell you that BD was still present on 4.14.36 and 4.16.4 kernel.
However, as to 4.14.x kernel line, I noticed that the latest patches fixed various errors related to ACPI /bus ( see for instance: https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.37 ): Andrea, did you try 4.14.37 and 4.14.38 kernel? Please, let me (us) know.
All the best,
Hi Giorgio, i'm currently on Manjaro where >= 4.14.37 isn't avaiable. I'll check with a live distro like ubuntu where it should be avaiable and i'll be back soon...
please confirm if this is a duplicate of bug #198665.
please follow comment #40 of that thread and confirm if commit de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8 introduces the problem or not.
Hi, yes the problem appear to be the same. I've just installed 4.19.39 and i'll let you know if in some way it fixed the problem. I currently cannot compile kernel on this machine sorry :(
Yes, i confirm taht on 4.14.39 bug is still present. I'll try to build the kernel the commit before in next days... i'll be back, thanks again!
tx for the information…bad news from 4.14.x kernel line…unfortunately, as I’ve already said, my battery is gone and at the moment I can’t make any test at all. However, as to the commit de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8: Zhang, are you referring to the patches that can be found here
the fix patch in bug #198665 has been shipped in 4.17-rc5
Author: Rafael J. Wysocki <firstname.lastname@example.org>
AuthorDate: Wed May 9 00:18:32 2018 +0200
Commit: Rafael J. Wysocki <email@example.com>
CommitDate: Thu May 10 16:50:26 2018 +0200
PCI / PM: Check device_may_wakeup() in pci_enable_wake()
Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
went too far and dropped the device_may_wakeup() check from
pci_enable_wake() which causes wakeup to be enabled during system
suspend, hibernation or shutdown for some PCI devices that are not
allowed by user space to wake up the system from sleep (or power off).
As a result of this, excessive power is drawn by some of the affected
systems while in sleep states or off.
Restore the device_may_wakeup() check in pci_enable_wake(), but make
sure that the PCI bus type's runtime suspend callback will not call
device_may_wakeup() which is about system wakeup from sleep and not
about device wakeup from runtime suspend.
Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
Reported-by: Joseph Salisbury <firstname.lastname@example.org>
Cc: 4.13+ <email@example.com> # 4.13+
Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org>
Acked-by: Bjorn Helgaas <email@example.com>
please confirm if the problem still exists in upstream kernel later than 4.17-rc5.
Mark as duplicate.
But anyway, please feel free to reopen it if the problem still exists in the latest upstream kernel.
*** This bug has been marked as a duplicate of bug 198665 ***