Laptop wakes up immediately after suspending

When I put my laptop to sleep mode it wakes up immediately. No matter how: via “suspend” button in control center, via ‘systemctl suspend’ command in terminal or by closing the laptop lid

Suspending succeeds when the airplane mode is on or when only Bluetooth is on. If I enable Wi-Fi, the suspending fails

I did not install any packages. It’s a clear system, right after installation finished

Here’s a laptop config:
CPU: AMD Ryzen 5 5600H
GPU: AMD Radeon Graphics (Integrated)
RAM: 16G
NetworkCard: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter

Or laptop name (if it’s easier that way): HONOR MAGICBOOK 16 (2022) (HYM-W56, if I’m not mistaken)

I’m not new to Linux but I still don’t know much about it :slight_smile:

It was interesting for me what’s the situation with this on another distribution with GNOME. This distribution is completely different from Fedora - ALT Regular GNOME (Sisyphus). Checked this right after installation is finished - the same behaviour. So, it may be GNOME problem but I will not bodly assert this

journalctl | grep -i wake log after systemctl suspend

jan 20 20:06:24 fedora bluetoothd[971]: Controller resume with wake event 0x0
jan 20 20:06:24 fedora NetworkManager[1100]: <info>  [1705748784.2151] manager: sleep: wake requested (sleeping: yes  enabled: yes)

and journalctl | grep -i suspend log

jan 20 20:06:22 fedora systemd-logind[988]: The system will suspend now!
jan 20 20:06:22 fedora ModemManager[1086]: <info>  [sleep-monitor-systemd] system is about to suspend
jan 20 20:06:23 fedora systemd[1]: Starting systemd-suspend.service - System Suspend...
jan 20 20:06:23 fedora systemd-sleep[6597]: Entering sleep state 'suspend'...
jan 20 20:06:23 fedora kernel: PM: suspend entry (s2idle)
jan 20 20:06:24 fedora kernel: printk: Suspending console(s) (use no_console_suspend to debug)
jan 20 20:06:24 fedora kernel: PM: suspend devices took 0.118 seconds
jan 20 20:06:24 fedora kernel: PM: suspend exit
jan 20 20:06:24 fedora systemd[1]: systemd-suspend.service: Deactivated successfully.
jan 20 20:06:24 fedora systemd[1]: Finished systemd-suspend.service - System Suspend.
jan 20 20:06:24 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
jan 20 20:06:24 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
jan 20 20:06:24 fedora systemd[1]: Reached target suspend.target - Suspend.
jan 20 20:06:24 fedora systemd[1]: Stopped target suspend.target - Suspend.

Without being able to test with your hardware I cannot provide details, but you should be aware that suspend is not actually a ‘suspend’ unless the wifi is able to be powered down. In order to actually enter the low power mode the system must be able to fully power down devices.

It seems in your case that keeping the wifi active is preventing sleeping.

Your case is different than several who have posted here. Theirs was that wifi remained disabled after resuming from suspend.

Are you on Fedora 39 ? Which one Silverblue, Workstation ?

Latest Fedora 39 release

Since fedora has multiple spins and versions please post the result of cat /etc/fedora-release so we can get the exact details. Also the output of inxi -Fzxx would be of use as well.

Please try an older kernel … It seams that the newer updates recently got this problem.

https://bugzilla.kernel.org/show_bug.cgi?id=217239

This issue has been around since 2023. I have the same issue today on f41. Does anyone know if this is fixed in f42? I cannot afford updating right now and risk any issues, but curious if anyone knows if it has been addressed.

It should be fixed in 6.15 kernel. I run F42 with 6.14.1 and have no issues with suspend but 6.14.2 suspend freezes whole system.

I see. I seem to be on 6.13.11. I might try to use a later version if safe for my spin and see if that fixes the issue.

Fixed for me with 6.14.3