Created attachment 186070 [details] Logs as showing first failed sleep, resume, second successful deep sleep, and then another resume SUMMARY Ever since I upgraded to Plasma 6.5.0, suspend to RAM has been extremely unreliable. The first power button push will fail to completely suspend the system. Instead it will use s2idle instead which is terrible for desktops because the fans are still running. If I really quickly press the power button again to resume and then attempt to suspend again, it will then successfully go into deep sleep. If I wait too long, it will use s2idle again on the next sleep attempt. It seems like a Plasma issue because if I reboot and trigger a sleep from the SDDM login screen, I can successfully deep sleep every single time. The problem only occurs after logging into a Plasma session. Looking at the journalctl logs I can see that the failed sleep will have a "PM: Some devices failed to suspend, or early wake event detected" message before going into s2idle. I've captured logs from journalctl and attached them to the bug report. It covers the first failed sleep that goes into s2idle, a subsequent wake, a successful deep sleep, and then another wake. STEPS TO REPRODUCE 1. Log into plasma 2. Attempt to suspend. System will go into s2idle. 3. Press the power button to resume and immediately go to sleep again 4. Notice that system can now deep sleep OBSERVED RESULT System prefers to go into s2idle instead of deep sleep on the first try. EXPECTED RESULT System goes into deep sleep every time SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor Memory: 64 GiB of RAM (62.4 GiB usable) Graphics Processor: NVIDIA GeForce RTX 3090 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X870E AORUS ELITE WIFI7 ADDITIONAL INFORMATION
I have also been having suspend troubles after updating to Plasma 6.5.0 on Arch today. My problem is a bit different than described here though. I can't get the computer to suspend at all. The screen turns black but the PC, fans and all, keep running. And it's impossible to bring it back to life. I need to do a force shutdown. Suspend works fine on SDDM and only stops working after starting the Plasma session. The last log messages I get are: out 25 15:34:24 desktop-nfp systemd-logind[1897]: The system will suspend now! out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7021] manager: sleep: sleep requested (sleeping: no enabled: yes) out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7022] manager: NetworkManager state is now ASLEEP out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7022] device (enp9s0): state change: activated -> deactivating (reason 'sleeping', managed-type: 'full') out 25 15:34:24 desktop-nfp dbus-broker[1891]: A security policy denied :1.35 to send method call /org/freedesktop/login1/seat/seat0:org.freedesktop.login1.Seat.Inhibit to org.freedesktop.login1. out 25 15:34:24 desktop-nfp kwin_wayland[2498]: Failed to delay sleep: Sender is not authorized to send message out 25 15:34:24 desktop-nfp dbus-broker[1891]: A security policy denied :1.35 to send method call /org/freedesktop/login1/seat/seat0:org.freedesktop.login1.Seat.Inhibit to org.freedesktop.login1. out 25 15:34:24 desktop-nfp kwin_wayland[2498]: Failed to delay sleep: Sender is not authorized to send message out 25 15:34:24 desktop-nfp systemd[1]: Starting Network Manager Script Dispatcher Service... out 25 15:34:24 desktop-nfp systemd[1]: Started Network Manager Script Dispatcher Service. out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7202] device (enp9s0): state change: deactivating -> disconnected (reason 'sleeping', managed-type: 'full') out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7205] dhcp4 (enp9s0): canceled DHCP transaction out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7205] dhcp4 (enp9s0): activation: beginning transaction (timeout in 45 seconds) out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7205] dhcp4 (enp9s0): state changed no lease out 25 15:34:24 desktop-nfp kernel: r8169 0000:09:00.0 enp9s0: Link is Up - 1Gbps/Full - flow control rx/tx out 25 15:34:24 desktop-nfp NetworkManager[1892]: <info> [1761402864.7545] device (enp9s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', managed-type: 'full') out 25 15:34:24 desktop-nfp kernel: r8169 0000:09:00.0 enp9s0: Link is Down out 25 15:34:25 desktop-nfp systemd[1]: Reached target Sleep. out 25 15:34:25 desktop-nfp systemd[1]: Starting System Suspend... out 25 15:34:25 desktop-nfp systemd[1]: user@1001.service: Unit now frozen-by-parent. out 25 15:34:25 desktop-nfp systemd[1]: user-1001.slice: Unit now frozen-by-parent. out 25 15:34:25 desktop-nfp systemd[1]: session-3.scope: Unit now frozen-by-parent. out 25 15:34:25 desktop-nfp systemd[1]: user@1000.service: Unit now frozen-by-parent. out 25 15:34:25 desktop-nfp systemd[1]: user-1000.slice: Unit now frozen-by-parent. out 25 15:34:25 desktop-nfp systemd[1]: user.slice: Unit now frozen. out 25 15:34:25 desktop-nfp systemd-sleep[4185]: Successfully froze unit 'user.slice'. out 25 15:34:25 desktop-nfp systemd-sleep[4185]: Performing sleep operation 'suspend'... out 25 15:34:25 desktop-nfp kernel: PM: suspend entry (deep) out 25 15:34:30 desktop-nfp kernel: Filesystems sync: 0.103 seconds out 25 15:34:30 desktop-nfp kernel: Freezing user space processes out 25 15:34:30 desktop-nfp rtkit-daemon[2428]: The canary thread is apparently starving. Taking action.
I am also experiencing some sleep issues. I usually press a dedicated Sleep key on my keyboard ("KC_SLEP" is the keycode). This used to work before the update. Now it appears that when pressing this button, the system tries to enter "deep" sleep, as I would prefer, but quickly tries to switch to s2idle, not preferred. This causes issues and immediately causes my PC to wake up. Pressing sleep from the "Kickoff"/start menu works just as expected. It never attempts s2idle. I also have logs of both good and bad cycles saved and will try to add.
Created attachment 186149 [details] Logs showing bad sleep with suspend button, good sleep with Kickoff menu, then another bad sleep with suspend button No matter how many times I press the suspend button on my keyboard, it never works
I can confirm the same behavior as anthonyjbarricelli. Sleeping from the Application menu always seems to work. It's the power button that is unreliable. I should also mention that the automatic sleep timer has the same issue. When it is time to sleep it will go into s2idle instead.
I can also confirm anthonyjbarricelli's behaviour. Sleeping from the Application Launcher works fine.
https://invent.kde.org/plasma/powerdevil/-/merge_requests/570 and https://invent.kde.org/plasma/powerdevil/-/merge_requests/556 look potentially related
"Some devices failed to suspend, or early wake event detected" comes from https://github.com/torvalds/linux/blob/fd57572253bc356330dbe5b233c2e1d8426c66fd/kernel/power/suspend.c#L519
So, I am reasonably confident it's my change (MR 570) which caused this issue. But to be fair, it is not an issue with the change, but kernel bug being exposed. Basically what is happening is, when going to suspend, there is some interrupt fired by some driver in system, and instead of it going to oblivion, system is cancelling that suspend, and since your system supports both s3 (deep) and s2 (s2idle) option, it is falling back to s2idle option. To confirm my theory, can you remove executable bit of for example, /usr/lib/kf6/kauth/wakeupsourcehelper and restart system?
I am wondering why does it work fine when suspending through the Application Launcher?
@Bhushan Shah I tested your theory. I removed the executable bit, restarted the machine and then tested suspend via my power button. It worked every time. I reset the executable bit, restarted again, and then the power button would go into s2idle every other press. Out of curiosity, what's the difference between power button / sleep timer vs sleeping through application launcher?
I have also tested removing the executable bit from /usr/lib/kf6/kauth/wakeupsourcehelper and indeed everything went back to working order. Suspend now works through keyboard shortcut and lock screen sleep sleep button.
I have the same issue with hibernate. Hibernation from the Application Launcher works fine, but not from a keyboard shortcut. I removed the executable bit, restarted the machine and then tried the keyboard shortcut. It enters hibernation as it should.
The workaround with the execution bit worked for me too. Thank you. But can we find out which hardware is the culprit?
Also removed the executable bit and it fixed my problems with sleep after updating to 6.5.0 I have my PC set to sleep after 20 minutes. After the update it would not sleep automatically though. The PC was still running in the background (could play audio via KDE Connect), but the monitor would not come on and even plugging in a new monitor did nothing. Have an AMD gpu (9070 xt) with a 9800X3D.
Also have this behavior though on plasma 6.5.1 and kernel 6.17.6 There is no /usr/lib/kf6/kauth/wakeupsourcehelper on my system however Operating System: Fedora Linux 43 KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.6-300.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor Memory: 32 GiB of RAM (30.5 GiB usable) Graphics Processor 1: NVIDIA GeForce RTX 4070 Graphics Processor 2: AMD Ryzen 7 9800X3D 8-Core Processor
> There is no /usr/lib/kf6/kauth/wakeupsourcehelper on my system however Try /usr/libexec/kf6/kauth/wakeupsourcehelper
(In reply to Dejan from comment #16) > > There is no /usr/lib/kf6/kauth/wakeupsourcehelper on my system however > > Try /usr/libexec/kf6/kauth/wakeupsourcehelper Bingo! That worked a treat. This resolves the suspend issues for me.
*** Bug 511597 has been marked as a duplicate of this bug. ***
I'm having same issue on Dell Latitude 7490, looks like it is not AMD-specific bug. "systemctl suspend" works fine, but suspending using sleep button or hibernating does not always work. Removing executable bit from "wakeupsourcehelper" resolved problem. When laptop fails to deep sleep there is "PM: Some devices failed to suspend, or early wake event detected" in dmesg. Operating System: Arch Linux KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.7-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 32 ГиБ of RAM (31.2 ГиБ usable) Graphics Processor: Intel® UHD Graphics 620 Manufacturer: Dell Inc. Product Name: Latitude 7490
*** Bug 510814 has been marked as a duplicate of this bug. ***
I am working on patch which does not use functionality of "dark resume" if suspend mode is "deep/s3" and does use it only if mode is s2idle. Although ideally this bugs in hardware should be reported to kernel.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/587
Git commit e49f9ae776a35016f2f280e752613db9c56df688 by Bhushan Shah. Committed on 12/11/2025 at 06:58. Pushed by bshah into branch 'master'. daemon: perform dark resume on s2idle mode only Currently there are some platform specific bugs with deep suspend and in specific x86 platforms, which causes wakeup event during suspend process. This causes it to fallback to s2idle mode. Limit dark resume mode by reading current mem sleep mode, and if it is not s2idle, we skip writing wakeup count file. M +30 -4 daemon/wakeupsourcehelper.cpp https://invent.kde.org/plasma/powerdevil/-/commit/e49f9ae776a35016f2f280e752613db9c56df688
Git commit 3eeb71e10083a6ed811b4662dd44ae303d1fe86b by Bhushan Shah. Committed on 12/11/2025 at 11:31. Pushed by bshah into branch 'Plasma/6.5'. daemon: perform dark resume on s2idle mode only Currently there are some platform specific bugs with deep suspend and in specific x86 platforms, which causes wakeup event during suspend process. This causes it to fallback to s2idle mode. Limit dark resume mode by reading current mem sleep mode, and if it is not s2idle, we skip writing wakeup count file. (cherry picked from commit e49f9ae776a35016f2f280e752613db9c56df688) M +30 -4 daemon/wakeupsourcehelper.cpp https://invent.kde.org/plasma/powerdevil/-/commit/3eeb71e10083a6ed811b4662dd44ae303d1fe86b
Fantastic to see this fixed! Thank you! But does this take into consideration the fact that the behaviour when using the "Sleep" button through the Application Launcher was different? Sleep worked fine specifically with that button even before the fix, hinting that maybe that button is not using the new behaviour.