Laptop wakes up from suspend on its own

Hello,

After being several hours in sleep mode, the laptop wakes up on its own. When this happens it draws a lot of battery and gets quite warm. This does not happen every time and is more likely to happen, the longer the laptop is in sleep. This happens since I got the laptop in April over several kernel versions and it’s very annoying.
This also happens when the laptop is just sitting on a desk, nothing plugged in and no expansion cards (except 2x USB C) attached. A fresh install didn’t help.
On the bottom you find a journalctl entry.

When it doesn’t happen, the battery draw is only around 0.5%/h.

I hope anyone has an idea how to solve this!

Fedora 36 KDE
Intel i7 1165G7
Kernel: 6.0.7-200
Bios 3.10
sudo grubby --update-kernel=ALL --args="nvme.noacpi=1"
s2idle

Nov 20 09:23:09 fedora kernel: Freezing user space processes ... (elapsed 0.008 seconds) done.
Nov 20 09:23:09 fedora kernel: OOM killer disabled.
Nov 20 09:23:09 fedora kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) 
done.
Nov 20 09:23:09 fedora kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Nov 20 09:23:09 fedora kernel: PM: suspend devices took 0.585 seconds
Nov 20 09:23:09 fedora kernel: ACPI: EC: interrupt blocked
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 977 (I/O Cmd) QID 1 timeout, aborting
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 916 (I/O Cmd) QID 7 timeout, aborting
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 450 QID 2 timeout, completion polled
Nov 20 09:23:09 fedora kernel: ACPI: EC: interrupt unblocked
Nov 20 09:23:09 fedora kernel: nvme nvme0: Abort status: 0x0
Nov 20 09:23:09 fedora kernel: nvme nvme0: Abort status: 0x0
Nov 20 09:23:09 fedora kernel: PM: resume devices took 0.283 seconds
Nov 20 09:23:09 fedora kernel: OOM killer enabled.
Nov 20 09:23:09 fedora kernel: Restarting tasks ... done.
Nov 20 09:23:09 fedora kernel: random: crng reseeded on system resumption
Nov 20 09:23:09 fedora kernel: PM: suspend exit
Nov 20 09:23:09 fedora kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bou
nd 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Nov 20 09:23:09 fedora kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: boun
d 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
Nov 20 09:23:09 fedora rtkit-daemon[1218]: The canary thread is apparently starving. Taking ac
tion.
Nov 20 09:23:09 fedora systemd-resolved[1163]: Clock change detected. Flushing caches.
Nov 20 09:23:09 fedora flatpak[2471]: 09:23:09.766 [JavaFX Application Thread] WARN  o.cryptom
ator.ui.fxapp.UpdateChecker - Error checking for updates
Nov 20 09:23:09 fedora flatpak[2471]: java.net.ConnectException: null
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.HttpClien
tImpl.send(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.HttpClien
tFacade.send(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at org.cryptomator.desktop@1.6.15/org.cryptomato
r.ui.fxapp.UpdateCheckerTask.call(UpdateCheckerTask.java:41)
Nov 20 09:23:09 fedora flatpak[2471]:         at org.cryptomator.desktop@1.6.15/org.cryptomato
r.ui.fxapp.UpdateCheckerTask.call(UpdateCheckerTask.java:22)
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent.Task
$TaskCallable.call(Task.java:1426)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.FutureTask.run
(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent.Serv
ice.lambda$executeTask$6(Service.java:727)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.security.AccessController.doPr
ivileged(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent.Serv
ice.lambda$executeTask$7(Service.java:726)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.ThreadPoolExec
utor.runWorker(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.ThreadPoolExec
utor$Worker.run(Unknown Source)
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.lang.Thread.run(Unknown Source
)
Nov 20 09:23:09 fedora flatpak[2471]: Caused by: java.net.ConnectException: null

Just to confirm, your sleep state is set to deep, correct? (edited, correction - lack of coffee)

The suspend settings can be either set to s2idle or deep, and I am using s2idle.

Thanks for catching that, I’ve been a bit under the weather. Yeah, if it’s waking you’ll want /sys/power/mem_sleep to be set to deep. I use deep on all of my laptops.

So my own Framework laptops look like:

cat /sys/power/mem_sleep

edited, should have read as:

s2idle [deep]

My recommendation is to avoid s2idle or shallow.

1 Like

This means that s2idle is used and not deep.

Since deep takes quite some time to wake up, is there a way to use s2idle by default but switch to deep automatically after 1h of sleep?

In fairness to my brain at the time, Theraflu and three Framework laptops, all turned on with different sleep states. Helps if I don’t have all of them on and open to work. lol

On the correct laptop:

s2idle [deep]

But you’re right, sleeping deep should not be needed. Might just for testing, try without the modules plugged in. Test one more time. I have heard mentions of a potential regression, but I never experienced it myself.

Currently on Fedora 37 on two machines I use, the one with the s2idle setting is working fine, HDMI, DP and USB C cards installed, 12th gen.

I only use 2 modules for USB-C, the other 2 are usually empty. Should I also remove the USB-C ones?

Since we’re trying to understand why the the laptop wakes up on its own, it’s a good place to start - eliminate as much hardware as possible to dial this in better and discover less log noise, more results. Once we eliminate this as a module causing the wake up, we can begin digging into the journal a bit.

Immediately after it wakes again on its own:

sudo journalctl --since="5 minutes ago"

If nothing, let’s also try:

sudo journalctl | grep resume

We’re looking for anything that stands out as an element that may have woken it up. A device, magic packet, etc.

Sorry for the newbie question, but how do you edit this file? I can’t seem to edit this file to reflect your post. I’ve tried sudo nano /sys/power/mem_sleep but it won’t let me save the changes to the file. I’d Google for an answer but I’m not quite sure what to search.
Thank you for your time.

cat is the command, short for concatenate. It just prints out the file contents without editing it. This file is not editable but will place square brackets [] around the activated sleep state.

1 Like

You can update the value in this file with sudo tee.

echo deep | sudo tee /sys/power/mem_sleep

This change will not survive a reboot, however. To make the change persistent, you need to add mem_sleep_default=deep to your kernel parameters.

To do this, open /etc/default/grub (with nano is fine) and add mem_sleep_default=deep to the other parameters on the GRUB_CMDLINE_LINUX_DEFAULT= line.

Then, update Grub. For Fedora, I believe you update Grub with:

sudo grub2-mkconfig -o /etc/grub2-efi.cfg

Surely that should’ve been taken care of before taking our money?

You can do it with this one liner and then restart:
sudo grubby --update-kernel=ALL --args=mem_sleep_default=deep

Here is a journalctl entry when it happened some time ago, still with two USB-C modules. I put the laptop to sleep on Nov 18 18:23:

Nov 20 09:23:09 fedora kernel: Freezing user space processes ... (elapsed 0.008 seconds) >
Nov 20 09:23:09 fedora kernel: OOM killer disabled.
Nov 20 09:23:09 fedora kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seco>
Nov 20 09:23:09 fedora kernel: printk: Suspending console(s) (use no_console_suspend to d>
Nov 20 09:23:09 fedora kernel: PM: suspend devices took 0.585 seconds
Nov 20 09:23:09 fedora kernel: ACPI: EC: interrupt blocked
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 977 (I/O Cmd) QID 1 timeout, aborting
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 916 (I/O Cmd) QID 7 timeout, aborting
Nov 20 09:23:09 fedora kernel: nvme nvme0: I/O 450 QID 2 timeout, completion polled
Nov 20 09:23:09 fedora kernel: ACPI: EC: interrupt unblocked
Nov 20 09:23:09 fedora kernel: nvme nvme0: Abort status: 0x0
Nov 20 09:23:09 fedora kernel: nvme nvme0: Abort status: 0x0
Nov 20 09:23:09 fedora kernel: PM: resume devices took 0.283 seconds
Nov 20 09:23:09 fedora kernel: OOM killer enabled.
Nov 20 09:23:09 fedora kernel: Restarting tasks ... done.
Nov 20 09:23:09 fedora kernel: random: crng reseeded on system resumption
Nov 20 09:23:09 fedora kernel: PM: suspend exit
Nov 20 09:23:09 fedora kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04>
Nov 20 09:23:09 fedora kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1:>
Nov 20 09:23:09 fedora rtkit-daemon[1218]: The canary thread is apparently starving. Taki>
Nov 20 09:23:09 fedora systemd-resolved[1163]: Clock change detected. Flushing caches.
Nov 20 09:23:09 fedora flatpak[2471]: 09:23:09.766 [JavaFX Application Thread] WARN  o.cr>
Nov 20 09:23:09 fedora flatpak[2471]: java.net.ConnectException: null
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Http>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Http>
Nov 20 09:23:09 fedora flatpak[2471]:         at org.cryptomator.desktop@1.6.15/org.crypt>
Nov 20 09:23:09 fedora flatpak[2471]:         at org.cryptomator.desktop@1.6.15/org.crypt>
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.FutureTas>
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.security.AccessController>
Nov 20 09:23:09 fedora flatpak[2471]:         at javafx.graphics@18.0.2/javafx.concurrent>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.ThreadPoo>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.util.concurrent.ThreadPoo>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.base/java.lang.Thread.run(Unknown S>
Nov 20 09:23:09 fedora flatpak[2471]: Caused by: java.net.ConnectException: null
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.comm>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Plai>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Asyn>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Http>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Http>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Exch>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Exch>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Exch>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Exch>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Exch>
Nov 20 09:23:09 fedora rtkit-daemon[1218]: Demoting known real-time threads.
Nov 20 09:23:09 fedora systemd-sleep[115623]: System returned from sleep state.
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Mult>
Nov 20 09:23:09 fedora flatpak[2471]:         at java.net.http/jdk.internal.net.http.Mult>

@letscho Okay, this is helpful and this definitely feels like software as I cannot replicate it. I’ve tested this on and on, nothing comes close. Seeing your logs, I see what I suspect is a contributor.

Looking at your journal, it appears that a java application appearing in those logs is likely waking your system.

If it was my Framework laptop, I’d test things further disabling or removing the application for extended troubleshooting.

@3by2 - how does your comment help to further the discussion or build the community?

@lbkNhubert - By informing FW that they shouldn’t use paying customers to beta test their products?

@3by2 - the OP’s issue is likely being caused by user-installed software. This is the first product from a startup company, it’s wholly unsurprising that there are some issues. Certain issues are more impactful depending upon one’s use case, but there are reasonable means by which to avoid adverse impacts. Personally, I don’t feel like a beta tester, it’s too bad that you do. I’m happy with both of my machines, and am glad that I bought them.

Your initial comment in this thread was unnecessary and, to be blunt, obnoxious. Mr. Hartley was too polite to respond or to take the bait. I’m not as big a person, so I took the bait and responded.

I hope that you find peace, and have a good evening.

2 Likes

How is it possible that a flatpak application can wake up the laptop? Is there a way to prevent this without disabling the application?

I haven’t personally experienced this, however, it’s an application and applications can in some cases wake things up from suspend. In your case, it appears the software is potentially touching/triggering rtkit-daemon which is waking the system. And daemons can wake up a system.

I think it’s worth testing to see if this is in fact what is happening since I have not experienced this nor have I been able to replicate it.

The suspend settings can be either set to s2idle or deep, and I am using s2idle.

Another option would be to try putting your suspend into a deeper sleep state. Deep is what I use on my Framework laptops.

I deactivated the flatpak application and also took out all modules, but the issue persists.

I noticed that the laptop was pretty warm at around 16:00. At 18:20 I opened the laptop and had only 4% of charge left (yesterday afternoon 90%). But the first journalctl entry is from 17:01:

Dec 10 17:01:46 fedora kernel: Freezing user space processes ... (elapsed 0.002 seconds) >
Dec 10 17:01:46 fedora kernel: OOM killer disabled.
Dec 10 17:01:46 fedora kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seco>
Dec 10 17:01:46 fedora kernel: printk: Suspending console(s) (use no_console_suspend to d>
Dec 10 17:01:46 fedora kernel: PM: suspend devices took 0.507 seconds
Dec 10 17:01:46 fedora kernel: ACPI: EC: interrupt blocked
Dec 10 17:01:46 fedora kernel: nvme nvme0: I/O 993 (I/O Cmd) QID 6 timeout, aborting
Dec 10 17:01:46 fedora kernel: nvme nvme0: I/O 969 QID 8 timeout, completion polled
Dec 10 17:01:46 fedora kernel: ACPI: EC: interrupt unblocked
Dec 10 17:01:46 fedora kernel: nvme nvme0: Abort status: 0x0
Dec 10 17:01:46 fedora kernel: PM: resume devices took 0.304 seconds
Dec 10 17:01:46 fedora kernel: OOM killer enabled.
Dec 10 17:01:46 fedora systemd-resolved[1132]: Clock change detected. Flushing caches.
Dec 10 17:01:46 fedora rtkit-daemon[1189]: The canary thread is apparently starving. Taki>
Dec 10 17:01:46 fedora rtkit-daemon[1189]: Demoting known real-time threads.
Dec 10 17:01:46 fedora rtkit-daemon[1189]: Demoted 0 threads.
Dec 10 17:01:46 fedora kernel: Restarting tasks ... done.
Dec 10 17:01:46 fedora kernel: random: crng reseeded on system resumption
Dec 10 17:01:46 fedora CROND[197217]: (root) CMD (run-parts /etc/cron.hourly)
Dec 10 17:01:46 fedora kernel: PM: suspend exit
Dec 10 17:01:46 fedora systemd-sleep[197150]: System returned from sleep state.
Dec 10 17:01:46 fedora kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04>
Dec 10 17:01:46 fedora kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1:>
Dec 10 17:01:46 fedora systemd[1]: plocate-updatedb.service - Update the plocate database>
Dec 10 17:01:46 fedora sssd_kcm[196262]: Shutting down (status = 0)
Dec 10 17:01:46 fedora systemd[1]: Starting unbound-anchor.service - update of the root t>
Dec 10 17:01:46 fedora kscreenlocker_greet[197076]: qt.qpa.wayland: Wayland does not supp>
Dec 10 17:01:46 fedora tracker-miner-f[164980]: Running on LOW Battery, pausing
Dec 10 17:01:46 fedora run-parts[197238]: (/etc/cron.hourly) starting 0anacron
Dec 10 17:01:46 fedora systemd[1]: logrotate.service - Rotate log files was skipped becau>
Dec 10 17:01:46 fedora systemd[1]: sssd-kcm.service: Deactivated successfully.
Dec 10 17:01:46 fedora run-parts[197266]: (/etc/cron.hourly) finished 0anacron
Dec 10 17:01:46 fedora CROND[197209]: (root) CMDEND (run-parts /etc/cron.hourly)
Dec 10 17:01:46 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 >
Dec 10 17:01:46 fedora systemd[1]: NetworkManager-dispatcher.service: Deactivated success>
Dec 10 17:01:46 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 >
Dec 10 17:01:46 fedora systemd[1]: systemd-suspend.service: Deactivated successfully.
Dec 10 17:01:46 fedora systemd[1]: Finished systemd-suspend.service - System Suspend.
Dec 10 17:01:46 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295>
Dec 10 17:01:46 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 >
Dec 10 17:01:46 fedora systemd[1]: Stopped target sleep.target - Sleep.
Dec 10 17:01:46 fedora systemd[1]: Reached target suspend.target - Suspend.

So it seems the laptop battery was discharged for whatever reason without actually being on.