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: https://wiki.mageia.org/en/User:Marja/QA/Hardware#Lenovo_ThinkPad_SL510 I have a 64bit install, and was running Plasma5 when closing the lid of the laptop.
Summary: laptep gets overheated and battery drained when put to sleep. related to upowerd "error 4 in libglib-2.0.so.0.4800.1" segfaults? => laptop gets overheated and battery drained when put to sleep. related to upowerd "error 4 in libglib-2.0.so.0.4800.1" segfaults?
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.
Summary: laptop gets overheated and battery drained when put to sleep. related to upowerd "error 4 in libglib-2.0.so.0.4800.1" segfaults? => Battery drained when laptop sleeps. Maybe related to upowerd "error 4 in libglib-2.0.so.0.4800.1" segfaults?
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?
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)"
CC: (none) => mageia
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.
CC: (none) => smorgan
Severity: normal => majorPriority: Normal => High
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) etc. 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
Summary: Battery drained when laptop sleeps. Maybe related to upowerd "error 4 in libglib-2.0.so.0.4800.1" segfaults? => Battery drained when laptop sleeps.Assignee: bugsquad => tmbSource RPM: glib2.0-2.48.1-1.mga6 ? => kernel-4.7.0-0.rc7.6.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.
Assignee: tmb => kernel
No idea whether this issue is still valid, I've been shutting my laptop down instead of letting it sleep, because I don't want to risk that it'll generate so much heat again when it's in my backpack. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD
Hi everyone, I see a very similar issue on my Asus laptop. I wonder if it is linked to the discrete GPU not suspending properly as hinted there: https://github.com/Bumblebee-Project/bbswitch/issues/115 Here's dmesg for a suspend/resume cycle: [ 4432.057145] PM: suspend entry (s2idle) [ 4432.057146] PM: Syncing filesystems ... done. [ 4432.070722] bbswitch: enabling discrete graphics [ 4432.226603] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 4432.229060] OOM killer disabled. [ 4432.229061] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 4432.230411] Suspending console(s) (use no_console_suspend to debug) [ 4432.546563] wlp2s0: deauthenticating from c0:4a:00:37:55:98 by local choice (Reason: 3=DEAUTH_LEAVING) [ 4432.547170] sd 2:0:0:0: [sda] Synchronizing SCSI cache [ 4432.554068] sd 2:0:0:0: [sda] Stopping disk [ 4432.559715] wlp2s0: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-22) [ 4434.382064] rtc_cmos 00:01: Alarms can be up to one month in the future [ 4434.389076] sd 2:0:0:0: [sda] Starting disk [ 4434.697557] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 4434.701064] ata3.00: configured for UDMA/133 [ 4434.712019] OOM killer enabled. [ 4434.712019] Restarting tasks ... done. [ 4434.722609] bbswitch: disabling discrete graphics [ 4434.746619] PM: suspend exit [ 4435.921436] [drm] RC6 on I'd love to contribute more info, but I'm not sure how to collect it. Any pointers?
Status: RESOLVED => UNCONFIRMEDCC: (none) => heninjResolution: OLD => (none)Ever confirmed: 1 => 0
Hi, This is High priority bug for a good reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please make the status to Assigned when you are working on this. Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it. On October 1st 2020, we will drop priority to normal.
(In reply to Aurelien Oudelet from comment #9) > Hi, > This is High priority bug for a good reason. > > Making Mageia even better than ever is best direction. > In order to do right thing, this bug should be examined and fixed as soon as > possible. > > Packagers, please make the status to Assigned when you are working on this. > Feel free to reassign the bug if bad-triaged. Also, if bug is old, please > close it. > > On October 1st 2020, we will drop priority to normal. dropping to normal. (In reply to Jérôme Hénin from comment #8) > > I'd love to contribute more info, but I'm not sure how to collect it. Any > pointers? If you can still reproduce this issue, then please run as root: journalctl -a --since="YYYY-MM-DD hh:mm" --until="YYY-MM-DD hh:mm" > log.txt while setting the first date/time to just before suspending and the last date/time to shortly after getting it back up
Keywords: (none) => NEEDINFOPriority: High => Normal
I have not noticed any problem lately. I think this is fixed for me.
(In reply to Jérôme Hénin from comment #11) > I have not noticed any problem lately. I think this is fixed for me. Thanks for the fast feedback.
Status: UNCONFIRMED => RESOLVEDResolution: (none) => FIXED