1

Hardware: Dell XPS 15 9570

OS: Ubuntu 19.10

I sleep my laptop at the end of the day. It goes into the 'deep' sleep state (/sys/power/sleep reads s2idle [deep]). At this point reawakening requires hitting the power button - neither lid nor keyboard will wake it. This is what I want - as deep a sleep state as possible 'till the following day.

However by the morning the laptop is warm, often with the fans running, and the screen comes on on when the lid is opened. Something is waking the machine after sleep during the night.

I've looked through the BIOS and there are no WoL or other relevant settings.

I've tried disabling all enabled devices in /proc/acpi/wakeup to no effect.

I can see in the log (pasted below) when the wakeup's happening but have no idea what the cause is. I'm still trawling through the journal, but it seems to be happening just after 00:00 daily (though I think it has also happened earlier than that on occasion?).

Can anyone either see from the below journalctl extract what might be waking the machine, or point me to other resources to help me investigate? It's become unviable for me to continue using Ubuntu at this point.

Journalctl:

Mar 26 21:02:20 bamboo systemd[1]: Starting Hibernate after suspend...
Mar 26 21:02:20 bamboo systemd[1]: Starting TLP suspend/resume...
Mar 26 21:02:20 bamboo rtcwake[7750]: rtcwake: assuming RTC uses UTC ...
Mar 26 21:02:20 bamboo rtcwake[7750]: rtcwake: wakeup using /dev/rtc0 at Thu Mar 26 13:02:21 2020
Mar 26 21:02:20 bamboo systemd[1]: Started Hibernate after suspend.
Mar 26 21:02:20 bamboo kernel: dell_wmi: Unknown WMI event type 0x12
Mar 26 21:02:20 bamboo systemd[1]: Started TLP suspend/resume.
Mar 26 21:02:20 bamboo systemd[1]: Reached target Sleep.
Mar 26 21:02:20 bamboo systemd[1]: Starting Suspend...
Mar 26 21:02:20 bamboo systemd-sleep[7886]: Suspending system...
Mar 26 21:02:20 bamboo kernel: PM: suspend entry (deep)
Mar 27 00:02:23 bamboo kernel: Filesystems sync: 0.009 seconds
Mar 27 00:02:23 bamboo kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.
Mar 27 00:02:23 bamboo kernel: OOM killer disabled.
Mar 27 00:02:23 bamboo kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
Mar 27 00:02:23 bamboo kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Mar 27 00:02:23 bamboo kernel: wlp59s0: deauthenticating from 10:b1:f8:b4:57:be by local choice (Reason: 3=DEAUTH_LEAVING)
Mar 27 00:02:23 bamboo kernel: psmouse serio1: Failed to disable mouse on isa0060/serio1
Mar 27 00:02:23 bamboo kernel: ACPI: EC: interrupt blocked
Mar 27 00:02:23 bamboo kernel: ACPI: Preparing to enter system sleep state S3
Mar 27 00:02:23 bamboo kernel: ACPI: EC: event blocked
Mar 27 00:02:23 bamboo kernel: ACPI: EC: EC stopped
Improve this question
11
  • What is your Timezone? Asking because "Mar 26 21:02:20 bamboo rtcwake[7750]: rtcwake: assuming RTC uses UTC ... Mar 26 21:02:20 bamboo rtcwake[7750]: rtcwake: wakeup using /dev/rtc0 at Thu Mar 26 13:02:21 2020"
    – Gerard H. Pille
    Commented Mar 26, 2020 at 18:58
  • UTC + 11 (with DST) - Aus/NSW. I don't quite follow the implications of those lines - they also seem to occur 3 hours before the laptop woke up. Do they offer a clue?
    – OpenAIDealAccountDeleted
    Commented Mar 26, 2020 at 19:14
  • "Mar 26 13:02:21 2020" + 11 = "Mar 27 00:02:23" ??
    – Gerard H. Pille
    Commented Mar 26, 2020 at 19:17
  • Hmm good point. I've just looked up rtcwake - seems to be a command to wake the machine automatically, which makes sense. Except that I had never heard of it and certainly never run it. Will need to dig further.
    – OpenAIDealAccountDeleted
    Commented Mar 26, 2020 at 19:22
  • Check with hwclock if rtcwake is wrong "assuming RTC uses UTC". If it is, tell rtcwake to use localtime. Or disable rtcwake completely, if you want a manual restart.
    – Gerard H. Pille
    Commented Mar 26, 2020 at 19:25

1 Answer 1

Reset to default
0

The problem turned out to be the suspend-sedation service. This runs rtcwake during the suspend process, scheduling a wake up after 3 hours, at which point it runs hibernate. In my laptop's case, I think hibernate was failing because the swap partition is too small. I'm surprised nothing showed up in the log to indicate this.

The expedient fix for now is to disable suspend-sedation (systemctl disable suspend-sedation.service) as hibernation isn't an immediate priority for me. This has been tested overnight, and seems to do the job.

Thanks to @GerardH.Pille for pointing me in the right direction in the question comments.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .