I’m having inconsistent issues waking from suspend, occasionally it works properly but the majority of the time my laptop resumes as if from a fresh reboot.
journalctl at least shows that the system is going into S2 sleep, however nothing in my logs shows any reason for the failure to come back out of sleep (at least to my untrained eye). No change in behavior when on battery or connected to power.
This is pretty much a default installation of Fedora 39, with the tweaks suggested by the Framework guides. Installation is probably about 3 months old, but is fully updated.
First few lines from journalctl -b -1 -r
Mar 05 21:41:32 amidala kernel: PM: suspend entry (s2idle)
Mar 05 21:41:32 amidala systemd-sleep[17736]: Entering sleep state 'suspend'...
Mar 05 21:41:32 amidala systemd[1]: Starting systemd-suspend.service - System S>
Mar 05 21:41:32 amidala systemd[1]: Reached target sleep.target - Sleep.
Could post the lines from the journal when a full suspend and resume cycle is done. The cutout you posted seems fine. But more details would be great and are appreciated. I run debian with a custom 6.7 kernel and have no problems with suspend and resume. Even before I installed the custom kernel with kernel 6.5 I had no problems, only the occasional white screen with some colored cubes.
I generally run without anything attached or only power. Suspending from menu or resuming from the touchpad do not seem to have an effect.
Notably this is an intermittent issue, resume sometimes works. I’ve noticed that it usually works within the first few minutes of being suspended, but not typically after about 10 minutes (although occasionally it will resume just fine after being suspended all night).
The battery is not low, and it is often plugged into power when a resume fails. The lowest battery percentage I’ve seen wtih a failed resume was near 40%.
Tested this again, Fedora 30. Clicking the bottom left (for a left click) of the touchpad on the FW13 AMD, woke up. I will test additional suspend scenarios, but it would be interesting to see what your logs indicate is happening. Namely, grep resume.
I’m on Fedora 39, currently running kernel 6.7.7-200 from the Fedora repos. Annoyingly, it seems to be working fine at the moment. No kernel upgrades since I initially posted, as well as no configuration changes. I have not idea why it is suddenly working well.
Successul resume (two in this case):
~$ journalctl -b -0 | grep resume
Mar 12 19:58:24 amidala kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Mar 12 19:58:24 amidala kernel: PM: resume devices took 0.369 seconds
Mar 12 19:58:24 amidala bluetoothd[1020]: Controller resume with wake event 0x0
Mar 12 20:49:58 amidala kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Mar 12 20:49:58 amidala kernel: PM: resume devices took 0.372 seconds
Mar 12 20:49:58 amidala bluetoothd[1020]: Controller resume with wake event 0x0 here
Unsuccessful resumes don’t have any relevant log entries, which clearly makes this a more difficult issue to troubleshoot.
I was having this exact same issue once or twice a day. I’m on day 3 of kernel 6.7.9-200 (no other changes) and have not seen it again with many lid closes and suspends of varying duration (long and short). Perhaps too early to call it fixed but so far, so good.
I’ve been having this issue ever since I got my laptop, and while I haven’t figured out the cause, I have figured out a consistent way to replicate it. If I insert an expansion card while the system is suspended, the system will consistently reboot instead of waking up, with no traces in the logs, as if the power was simply cut off. So perhaps it is something to do with expansion cards?
But I’ve also had this happen with no expansion cards installed, so maybe not.
I think I’ve found the culprit - I uninstalled TLP (apparently known to interfere with AMD suspend) and now my laptop has managed to stay online for days at a time, with no suspend issues whatsoever. power-profiles-daemon seems to be fine.
Just now I have encountered the problem on a F13 running Mint 22.1 Cinnamon on a 6.11 kernel. EDIT: an AMD F13, and with tlp; BIOS 3.09.
Earlier today my F13 suspend fine but then later in the day it did not suspend upon lid close and systemctl suspend blanked the screen for a moment and then showed the lock screen. I do not think that I updated anything between the successful suspend and the unsuccessful ones. The system log shows:
kernel: usb usb2: PM: failed to suspend async: error -16
EDIT: suspend seemed to have become permanently broken. But I figured out the cause, or at least, on my system, the proximate cause: tlp. Here is the fix (/workaround). Create / edit a drop-in .conf file in /etc/tlp.d. Have this line in it:
I add the following good news. Something - a kernel update? a via-apt firmware package update? - seems to have solved the problem. That is: USB_AUTOSUSPEND=1 now does not prevent sleep. (I note that that setting is the default, i.e., gets implemented if one’s configuration has no USB_AUTOSUSPEND line in it.)
Still, it is possible that the problem has not disappeared entirely but rather is intermittent. The author of tlp has a troubleshooting guide that we can employ if the problem does reoccur.
I’m currently observing the same behaviour on my Framework 13 AMD (7840U). I close the lid, then open it again and occasionally it doesn’t seem to go back to normal operation. Instead I see the framework logo, as if were a cold boot.
I’m using Arch Linux.
Logs do not immediately say anything interesting (journalctl -b -1 -r):
Jul 18 09:07:50 framework-bjarch systemd-sleep[6145]: Performing sleep operation 'suspend'...
Jul 18 09:07:50 framework-bjarch systemd[1]: user@1000.service: Unit now frozen-by-parent.
Jul 18 09:07:50 framework-bjarch systemd-sleep[6145]: Successfully froze unit 'user.slice'.
Jul 18 09:07:50 framework-bjarch systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Jul 18 09:07:50 framework-bjarch systemd[1]: user.slice: Unit now frozen.
Jul 18 09:07:50 framework-bjarch systemd[1]: session-3.scope: Unit now frozen-by-parent.
Jul 18 09:07:50 framework-bjarch systemd[1]: Starting System Suspend...
Jul 18 09:07:50 framework-bjarch systemd[1]: Reached target Sleep.
Jul 18 09:07:50 framework-bjarch systemd-resolved[756]: wlan0: Bus client reset DNS server list.
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.5806] device (wlan0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', mana>
Jul 18 09:07:50 framework-bjarch systemd-resolved[756]: wlan0: Bus client set default route setting: no
Jul 18 09:07:50 framework-bjarch tailscaled[1096]: [REDACTED, Multiple messages]
Jul 18 09:07:50 framework-bjarch tailscaled[1096]: wgengine: set DNS config again after major link change
Jul 18 09:07:50 framework-bjarch systemd-resolved[756]: Flushed all caches.
Jul 18 09:07:50 framework-bjarch tailscaled[1096]: [REDACTED, Multiple messages]
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.5584] device (wlan0): state change: deactivating -> disconnected (reason 'sleeping', managed-typ>
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.5584] device (wlan0): new IWD device state is disconnected
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.5583] device (wlan0): new IWD device state is disconnecting
Jul 18 09:07:50 framework-bjarch iwd[1232]: event: state, old: disconnecting, new: disconnected
Jul 18 09:07:50 framework-bjarch kernel: wlan0: deauthenticating from [REDACTED] by local choice (Reason: 3=DEAUTH_LEAVING)
Jul 18 09:07:50 framework-bjarch iwd[1232]: event: state, old: connected, new: disconnecting
Jul 18 09:07:50 framework-bjarch systemd[1]: Started Network Manager Script Dispatcher Service.
Jul 18 09:07:50 framework-bjarch pkexec[6121]: bjarno: Executing command [USER=root] [TTY=unknown] [CWD=/home/bjarno] [COMMAND=/usr/bin/xfpm-power-backlight-helper --set-b>
Jul 18 09:07:50 framework-bjarch pkexec[6121]: pam_unix(polkit-1:session): session opened for user root(uid=0) by bjarno(uid=1000)
Jul 18 09:07:50 framework-bjarch systemd[1]: Starting Network Manager Script Dispatcher Service...
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.2393] device (wlan0): state change: activated -> deactivating (reason 'sleeping', managed-type: >
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.2393] manager: NetworkManager state is now ASLEEP
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.2390] device (/net/connman/iwd/0): state change: disconnected -> unmanaged (reason 'unmanaged-sl>
Jul 18 09:07:50 framework-bjarch NetworkManager[1010]: <info> [1752822470.2390] manager: sleep: sleep requested (sleeping: no enabled: yes)
Jul 18 09:07:50 framework-bjarch systemd-logind[1018]: The system will suspend now!
Jul 18 09:07:50 framework-bjarch systemd-logind[1018]: Lid closed.
Edit: I’ve tried linux-lts kernel, to see if this changes something. But it still occasionally happens. It seems to happen once every 20-ish times (didn’t actually count, so a rough guesstimate), so quite hard to debug. But obviously, when it happens, it’s always inconvenient.