Join Log in
Score:2
Roman Bekkiev avatar Ubuntu

Can't suspend: system resumes for unknown reason after ~40 minutes of sleep

pl flag
Roman Bekkiev

I've bought new MSI Summit B15 which was supplied without OS and happily installed on it fresh Ubuntu 21.04. So far everything works pretty well (except couple of troubles with touchpad & no drivers for FP scanner but that's a different story) except one pretty annoying issue: when I try to suspend the machine it suddenly wakes up in about ~40-60 minutes and start running fans full-speed. Not only it sometimes wakes up me if I happened to sleep nearby, it drains the battery over night, making suspend essentially useless.

I've tried to disable everything (see here how) but power button in /proc/acpi/wakeup, so it looks like this currently:

➜  ~ cat /proc/acpi/wakeup | grep enabled
PWRB      S4    *enabled   platform:PNP0C0C:00

It doesn't help.

Here is part of syslog (here I've put system to suspend at 7:48 and it started fanning at 8:35 but I logged in later, only at 10:56):

Sep  5 07:48:00 rb-base tracker-store[6784]: OK
Sep  5 07:48:00 rb-base systemd[3246]: tracker-store.service: Succeeded.
Sep  5 07:48:01 rb-base kernel: [  146.937861] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep  5 07:48:05 rb-base kernel: [  150.972633] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep  5 07:48:05 rb-base kernel: [  150.977982] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep  5 07:48:05 rb-base ModemManager[2119]: <info>  [sleep-monitor] system is about to suspend
Sep  5 07:48:05 rb-base kernel: [  150.997219] wlo1: deauthenticating from b0:4e:26:31:82:b8 by local choice (Reason: 3=DEAUTH_LEAVING)
Sep  5 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-DISCONNECTED bssid=b0:4e:26:31:82:b8 reason=3 locally_generated=1
Sep  5 07:48:05 rb-base NetworkManager[1931]: <info>  [1630817285.6861] device (wlo1): state change: deactivating -> disconnected (reason 'sleeping', sys-ifac
e-state: 'managed')
Sep  5 07:48:05 rb-base wpa_supplicant[1978]: wlo1: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=0 noise=9999 txrate=0
Sep  5 07:48:07 rb-base systemd[1]: Reached target Sleep.
Sep  5 07:48:07 rb-base systemd[1]: Starting Suspend...
Sep  5 07:48:07 rb-base kernel: [  152.341436] PM: suspend entry (s2idle)
Sep  5 07:48:07 rb-base systemd-sleep[7072]: Suspending system...
Sep  5 07:48:07 rb-base systemd[1]: zsysd.service: Succeeded.
Sep  5 07:48:07 rb-base kernel: [  152.424613] Filesystems sync: 0.083 seconds
Sep  5 10:56:42 rb-base kernel: [  152.426323] Freezing user space processes ... (elapsed 0.002 seconds) done.
Sep  5 10:56:42 rb-base kernel: [  152.428515] OOM killer disabled.
Sep  5 10:56:42 rb-base kernel: [  152.428516] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Sep  5 10:56:42 rb-base kernel: [  152.429676] printk: Suspending console(s) (use no_console_suspend to debug)
Sep  5 10:56:42 rb-base kernel: [  153.214718] ACPI: EC: interrupt blocked
Sep  5 10:56:42 rb-base kernel: [11468.660690] ACPI: EC: interrupt unblocked
Sep  5 10:56:42 rb-base kernel: [11469.338032] nvme nvme0: 8/0/0 default/read/poll queues
Sep  5 10:56:42 rb-base kernel: [11469.574414] OOM killer enabled.
Sep  5 10:56:42 rb-base kernel: [11469.574416] Restarting tasks ... done.
Sep  5 10:56:42 rb-base kernel: [11469.584884] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Sep  5 10:56:42 rb-base kernel: [11469.586402] thermal thermal_zone6: failed to read out thermal zone (-61)
Sep  5 10:56:42 rb-base systemd[1]: Condition check resulted in Run anacron jobs being skipped.
Sep  5 10:56:43 rb-base systemd-sleep[7072]: System resumed.
Sep  5 10:56:43 rb-base kernel: [11469.846714] PM: suspend exit
Sep  5 10:56:43 rb-base systemd[1]: systemd-suspend.service: Succeeded.
Sep  5 10:56:43 rb-base systemd[1]: Finished Suspend.
Sep  5 10:56:43 rb-base systemd[1]: Stopped target Sleep.
Sep  5 10:56:43 rb-base systemd[1]: Reached target Suspend.
Sep  5 10:56:43 rb-base systemd[1]: Stopped target Suspend.
Sep  5 10:56:43 rb-base NetworkManager[1931]: <info>  [1630828603.2303] manager: sleep: wake requested (sleeping: yes  enabled: yes)
Sep  5 10:56:43 rb-base ModemManager[2119]: <info>  [sleep-monitor] system is resuming
Sep  5 10:56:43 rb-base NetworkManager[1931]: <warn>  [1630828603.5154] sup-iface[499bce01c63427b3,1,wlo1]: call-p2p-cancel: failed with P2P cancel failed
Sep  5 10:56:45 rb-base ModemManager[2119]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.3': not supported by any plugin
Sep  5 10:56:46 rb-base dbus-daemon[1927]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.90' (uid=1000 pid=3490 comm="/usr/bin/gnome-shell " label="unconfined")
Sep  5 10:56:46 rb-base systemd[1]: Starting Fingerprint Authentication Daemon...
Sep  5 10:56:46 rb-base dbus-daemon[1927]: [system] Successfully activated service 'net.reactivated.Fprint'
Sep  5 10:56:46 rb-base systemd[1]: Started Fingerprint Authentication Daemon.

(Here is the full log, in case I've removed something relevant)

As you can see, there's no record at the moment the machine is actually woke up. So my next assumption is that something outside the OS causes wake-up. But system looks not suspended: e.g. monitor is lite up and login screen is shown when immediately when I open the lid, it usually takes some time to start login screen, when I open lid on sleeping system.

UPD1: Thanks to @David comment, although WOL itself is not relevant to my system (MSI Summit doesn't even have an Ethernet card), I've figured out, that I have to search for some configuration in BIOS setup. And I found there "Wake on Thunderbolt™ device" entry which was enabled. I have 0 Thunderbolt™ devices but disabled the entry, just in case. This didn't help though.

UPD2: It seams that /proc/acpi/wakeup just doesn't work: as I mentioned earlier, I've disabled everything but power button in it, however, when I open the lid, computer still wakes up.

UPD3 Battery state dumping script, as suggested by @sancho.s ReinstateMonicaCellio:

#!/bin/bash

TIME="$(date +'%y-%m-%d %H:%M:%S')"
CAPACITY="$(cat /sys/class/power_supply/BAT1/capacity)"
CURRENT="$(cat /sys/class/power_supply/BAT1/current_now)"
VOLTAGE="$(cat /sys/class/power_supply/BAT1/voltage_now)"

echo "$TIME\t$CAPACITY\t\t\t$CURRENT\t$VOLTAGE" >> /home/rb/bat_dump
332
1 + 3
msi
David avatar
cn flag
David
This might be of some help. https://superuser.com/questions/86576/how-does-wol-wake-on-lan-work it has been the problem for some in the past.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
Unplugging the mouse/BT receiver?
0
Reply
Roman Bekkiev avatar
pl flag
Roman Bekkiev
Tried to unplug everything that could be unplugged. =)
0
Reply
Nate T avatar
it flag
Nate T
None of the loggers will display every log (that I know of, but one may have an option that does.) They usually each focus on a specific aspect of the system (e.g. `dmesg` prints boot related logs.) I would `cd` to `/var/log` and `cat` each one ending in `.log` one at a time. Search for a log that has an entry for around 8:00 and that is the culprit. Some of the entries (such as `apt`) will be directories with logs inside. Or you could get creative with `grep`. Something like `cat /var/log/**.log | grep <time-or-timecode>`.
0
Reply
Roman Bekkiev avatar
pl flag
Roman Bekkiev
I’m voting to close this question because This problem is most likely hardware related and seems to be not fixable from Ubuntu OS
1
Reply
Score:4
sancho.s ReinstateMonicaCellio avatar Ubuntu
pl flag
sancho.s ReinstateMonicaCellio

I don't know if this is your case, but if your system is configured to sleep when closing the lid, and hibernate after say 40 minutes, fans may start at that time, when hibernating. This wouldn't explain the battery drainage, though. Another related case is when the system is configured to hibernate at a certain battery level. So battery drainage occurs first (I wouldn't know why), and that triggers hibernation. Or, the system might be not suspended at all.

Diagnosing PC state

Check relevant events with

$ journalctl --no-pager | cat -n | grep -A 10 -B 3 systemd-logind

You may identify suspends in lines like

9818455 sep 08 22:25:57 MyServer systemd-logind[1132]: Lid closed.
...
9818624 sep 09 06:43:47 MyServer systemd-logind[1132]: Lid opened.

Or use

$ cat -n /var/log/syslog | grep -A 10 -B 3 systemd-logind

Your syslog appears to show an effective sleeping, but I am not sure. I have PM: suspend entry (deep) (in a Thinkpad) instead of your PM: suspend entry (s2idle). See also below.

Diagnosing battery drainage

You could write a script, say dump_bat.sh that dumps the battery state to file, with something like

#!/bin/bash
upower -i /org/freedesktop/UPower/devices/battery_BAT0 > battery_$(date | tr " " "_").txt

You could grep specific parts of the output like percentage, time to empty, updated, and History fragments. Remember

$ chmod +x dump_bat.sh

Placing a cron job to do this every say 10 minutes will help identifying the pattern of battery drainage, and the notebook state (awake/sleeping). Add

*/10  * * * * <path to dump_bat.sh>

with

$ crontab -e

Avoiding battery drainage

Try disabling WOL with this

$ ethtool -s <device> wol d

Combine with diagnosis above.

0 + 3
Roman Bekkiev avatar
pl flag
Roman Bekkiev
sancho.s ReinstateMonicaCellio, thanks for your answer! Battery drainage itself is not an issue: it is pretty much expected that fans running all night will drain a battery. Regarding WOL: I don't think this is relevant, as I said, my laptop doesn't even have ethernet (only `lo` and `wlo1` shows up in `ip a`), thus, no `ethtool`.
0
Reply
Roman Bekkiev avatar
pl flag
Roman Bekkiev
Regarding `hibernate` there is something strange though: `systemctl hibernate` says `Failed to hibernate system via logind: Sleep verb "hibernate" not supported`, so, I don't think it is even supported. However, in `syslog` there are records that look like `Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7`. Those are not near suspend events though.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
@RomanBekkiev - The idea behind my suggestion is not avoiding battery drainage, but as stated learning the pattern of battery drainage, and the notebook state (awake/sleeping). Please try the suggestion and post results.
0
Reply
Roman Bekkiev avatar
pl flag
Roman Bekkiev
Well, as I expected, it seems that the part of the system where cron resides doesn't work, as it happens with logs. Here is the dump: https://gist.github.com/RB-Lab/b2246e7dc47b16d603b943d1a4a17be9 Here laptop was charging until 22:30 then I've disconnected charger and put it to suspend. And the next record only occurs next morning, when I opened the lid and log-in, 20% already used. It looks like the system not actually wakes up at night but rather just have a bad sleep...
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
@RomanBekkiev - My comments: 1) What do you mean by "the part of the system where cron resides doesn't work"? It seems to have done its job. Unless you did it some other way. 2) What do you mean by "as it happens with logs"? 3) Your "battery log" looks perfectly normal. 4) How often does the problem you describe show up? It did not happen yesterday.
0
Reply
Roman Bekkiev avatar
pl flag
Roman Bekkiev
It looks like OS itself **is** in suspend mode, thus cron doesn't run it's jobs and nothing is being written in logs. The thing that run fans probably somewhere in a lower abstraction layer (e.g. BIOS??). I don't think that drop 20% in capacity per 8 hours is OK: e.g. Macs use at most 3-5% of battery capacity per night, when they're in sleep mode, and my previous Lenovo ThinkPad had comparable battery usage. However, problem, probably, is not related to Ubuntu/Linux.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
@RomanBekkiev - Ok, now I see what you mean. My comments: 1) The gap in the battery report is completely expected, and it confirms the PC is suspended. It doesn't mean there is anything wrong with cron or logs, it's exactly how it i supposed to work. 2) As for a 20% decrease overnight, that doesn't mean there is anything wrong either. From the original OP, I understood battery was completely exhausted overnight. That would be strange.
0
Reply
sancho.s ReinstateMonicaCellio avatar
pl flag
sancho.s ReinstateMonicaCellio
3) Whether the 20% can be improved, you could try a few things. a) Check with Windows, if you have installed. b) Try dumping the suspend mode Sx, and using a different mode if possible. c) Enable hibernation if possible at all in your system. All this is worth another question/s. 4) I suggest you continue using the script to see how your PC behaves. 5) If you didn't catch a case when the fans started, that might be a further issue.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.