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: 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.
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.
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
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?
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)"
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.
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: Lid closed.
jul 22 14:14:30 cldrn_64 systemd: Reached target Sleep.
jul 22 14:14:30 cldrn_64 systemd: Starting Suspend...
jul 22 14:14:30 cldrn_64 systemd-sleep: 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
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.