| Summary: | Battery drained when laptop sleeps. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marja Van Waes <marja11> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | heninj, lists.jjorge, mageia, olav, smorgan, tmb |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel-4.7.0-0.rc7.6.mga6 | CVE: | |
| Status comment: | |||
| Attachments: |
Yesterday's journalctl output, including closing the lid and several segfaults
current upower -d output (after recharging) |
||
|
Description
Marja Van Waes
2016-07-17 00:52:48 CEST
Marja Van Waes
2016-07-17 00:53:06 CEST
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
Rémi Verschelde
2016-07-18 12:44:37 CEST
Severity:
normal =>
major 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. 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 =>
RESOLVED 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 =>
UNCONFIRMED 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) =>
NEEDINFO 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 =>
RESOLVED |