Bug 18961 - Battery drained when laptop sleeps.
Summary: Battery drained when laptop sleeps.
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
Depends on:
Reported: 2016-07-17 00:52 CEST by Marja van Waes
Modified: 2016-08-26 11:42 CEST (History)
5 users (show)

See Also:
Source RPM: kernel-4.7.0-0.rc7.6.mga6
Status comment:

Yesterday's journalctl output, including closing the lid and several segfaults (92.70 KB, application/x-xz)
2016-07-17 00:52 CEST, Marja van Waes
current upower -d output (after recharging) (1.92 KB, text/plain)
2016-07-17 09:43 CEST, Marja van Waes

Description Marja van Waes 2016-07-17 00:52:48 CEST
Created attachment 8187 [details]
Yesterday's journalctl output, including closing the lid and several segfaults

To my dismay, I found out a few hours ago that I had reproduced this (from #mageia-dev on IRC):

2016:06:24:12:57< stuartm> put my laptop to sleep with a full charge last night, this morning the battery was dead ... something very wrong in Cauldron :(

2016:06:24:12:58< rindolf> stuartm: was the battery empty or dysfunctional?
2016:06:24:12:59< stuartm> empty - full battery drained while it was suspended to RAM - can usually expect to get 2+ days that way, which is still terrible compared to Windows/Mac but this is a regression from Mageia 5

I don't usually put my laptop to sleep, but last evening I did, around 18:53:32 h. (See attached logs)

When I wanted to use it again 4 hours later, I found that the battery (with a capacity of over 90Wh, which was ± half full when I had closed the lid of the laptop, was empty. "upower -d" showed 0%

Apart from that, the laptop was extremely hot! I didn't measure its temperature, but don't remember it has ever felt so hot before.

When looking for upower related errors, I saw that there have been several upowerd segfaults yesterday. 

kernel: upowerd[930]: segfault at 20 ip 00007f7d41e11050 sp 00007ffc46ea7838 error 4 in libglib-2.0.so.0.4800.1[7f7d41d8e000+10d000]

I do not know whether those segfaults are related to the overheating of the sleeping laptop and the draining of the battery.

Also, I do not know yet where to find the core dump that's also mentioned in the journal ("upower.service: Failed with result 'core-dump'.") and I won't have time the next few days to find out.

An old lspcidrake -v of the laptop I use can be found here:

I have a 64bit install, and was running Plasma5 when closing the lid of the laptop.
Comment 1 Marja van Waes 2016-07-17 08:06:54 CEST
Forget about the overheating part: during those 4 hours the laptop was in a padded sleeve inside a backpack with other things.

The heat generated by whatever was consuming power, had nowhere to go. 

Someone hitting the same issue while the laptop is just sitting on a desk, will not notice such heat.
Comment 2 Marja van Waes 2016-07-17 09:43:51 CEST
Created attachment 8192 [details]
current upower -d output (after recharging)

It amazed me that the battery was _completely_ empty, and in the upower -d output, the line

   critical-action: (null)

puzzles me.

Does that meant that the system is no longer powered off, when the battery is e.g. less than 5% full?

Isn't there a default action, if a user doesn't set one?
Comment 3 Marja van Waes 2016-07-17 09:52:11 CEST
According to the Plasma settings, the action for reaching critical battery level (5%) was to hibernate to disk.

I just changed that to poweroff.

upower -d output still shows "critical-action: (null)"
Comment 4 Stuart Morgan 2016-07-17 10:03:55 CEST
For me the issue seems to have been resolved by a recent update. Instead of draining overnight it's using ~20% of the battery. I'm really not sure which package update fixed it.

I'm not sure it was going to sleep at all before the issue was resolved, it seemed to start the process, the screen would blank, the fans and disk would spin down but then the fans would spin back up again and the power LED wouldn't start flashing. The latter is a detail I missed at first because I usually sleep the laptop by closing the screen which hides the power LED.
Comment 5 Marja van Waes 2016-07-22 17:00:06 CEST
There are no more (libglib) segfaults

When the laptop goes to sleep correctly, then after such lines:

jul 22 14:14:29 cldrn_64 systemd-logind[790]: Lid closed.
jul 22 14:14:30 cldrn_64 systemd[1]: Reached target Sleep.
jul 22 14:14:30 cldrn_64 systemd[1]: Starting Suspend...
jul 22 14:14:30 cldrn_64 systemd-sleep[17070]: Suspending system...

many kernel lines follow:

jul 22 14:14:31 cldrn_64 kernel: PM: Syncing filesystems ... done.
jul 22 14:14:31 cldrn_64 kernel: PM: Preparing system for sleep (mem)
jul 22 14:14:58 cldrn_64 kernel: Freezing user space processes ... (elapsed 0.004 seconds) done.
jul 22 14:14:58 cldrn_64 kernel: Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) 
jul 22 14:14:58 cldrn_64 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
jul 22 14:14:58 cldrn_64 kernel: PM: Suspending system (mem)


If that happens, then the system can be woken up, and then I don't see the battery was being drained.

However, often there are _no_ more lines after those 4 systemd lines. The logs simply stop there, until next time the system was booted up.

In that case, when opening the lid there is no way to get X back up, no way to switch to a visible VT, SysRq keys don't work and the only option is pressing the button to power off.

Guessing this is really a kernel issue.

I'm using kernel-desktop-4.7.0-0.rc7.6.mga6-1-1.mga6
Comment 6 Marja van Waes 2016-08-26 11:42:59 CEST
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Note You need to log in before you can comment on or make changes to this bug.