2

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
Roman Bekkiev
  • 331
  • 3
  • 10
  • 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. – David Sep 05 '21 at 08:44
  • Unplugging the mouse/BT receiver? – sancho.s ReinstateMonicaCellio Sep 09 '21 at 09:48
  • Tried to unplug everything that could be unplugged. =) – Roman Bekkiev Sep 09 '21 at 15:25
  • 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>. – Nate T Sep 11 '21 at 21:59
  • 1
    I’m voting to close this question because This problem is most likely hardware related and seems to be not fixable from Ubuntu OS – Roman Bekkiev Sep 18 '21 at 17:29

1 Answers1

4

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.

sancho.s ReinstateMonicaCellio
  • 14,674
  • 11
  • 44
  • 97
  • 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. – Roman Bekkiev Sep 09 '21 at 15:12
  • 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. – Roman Bekkiev Sep 09 '21 at 15:12
  • @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. – sancho.s ReinstateMonicaCellio Sep 09 '21 at 15:39
  • 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... – Roman Bekkiev Sep 10 '21 at 09:06
  • @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.
     – sancho.s ReinstateMonicaCellio Sep 10 '21 at 09:12
  • 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. – Roman Bekkiev Sep 10 '21 at 11:28
  • @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.
     – sancho.s ReinstateMonicaCellio Sep 10 '21 at 11:41
  • 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.

    – sancho.s ReinstateMonicaCellio Sep 10 '21 at 11:44