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.

For some added information, I was encountering likely the same issue on my computers. Since I have past experience debugging Linux suspend issues, I decided to debug the code to find what went wrong (in hindsight a rabbit hole deeper than I could have imagined).

After I moved my Arch Linux SSD from a Ryzen desktop into an Intel NUC, Plasma would fail to sleep from the lock screen (if I left the computer idle or clicked Sleep myself). It would successfully sleep from the start menu (which matches the "good sleep with Kickoff menu" reported here). I did not try sleeping from Ctrl+Alt+Del.

## Tracing the kernel

On a failed sleep, I got the "Some devices failed to suspend, or early wake event detected" error message. Based on past knowledge about debugging system suspend, I ran the following commands in a root console:
echo 1 > /sys/power/pm_print_times
echo 1 > /sys/power/pm_debug_messages

Afterwards, a failed sleep produced `journalctl --system` messages:
Oct 24 22:09:30 ryzen kernel: PM: Wakeup pending, aborting suspend
Oct 24 22:09:30 ryzen kernel: PM: active wakeup source: mmc0
Oct 24 22:09:30 ryzen kernel: PM: suspend of devices aborted after 151.615 msecs
Oct 24 22:09:30 ryzen kernel: PM: start suspend of devices aborted after 169.797 msecs
Oct 24 22:09:30 ryzen kernel: PM: Some devices failed to suspend, or early wake event detected

The "Wakeup pending, aborting suspend" message comes from function `pm_wakeup_pending()`. This function checks if event checks are enabled, and if some counters have changed aborts suspend and calls `pm_print_active_wakeup_sources()`, which prints `wakeup_sources`. I don't know what changed the counters, but instead looked into what wrote to wakeup_sources. I found that `pm_wakeup_ws_event()` would activate an event and `wakeup_source_register() → wakeup_source_add()` would add a new one.

- While writing this comment, I decided to trace `pm_wakeup_pending`. It was called so many times it overflowed my terminal's scrollback! I tried running it again, but plasmashell hung, kscreenlocker_greet froze freeze at a black screen, then *kwin* itself hung, I had to enable raw input with SysRq-R to open a TTY, and rebooting hung with `rcu_tasks_wait_gp` counting up endlessly. Yay Linux...

To find who changed wakeup events, I used my stacksnoop fork at https://github.com/nyanpasu64/bcc/blob/local/examples/tracing/stacksnoop.py to trace a failed suspend:
nyanpasu64@ryzen ~/code/bcc (local)> sudo ./examples/tracing/stacksnoop.py pm_wakeup_ws_event wakeup_source_register
TIME(s)            FUNCTION
5.660198689:
0: ret_from_fork_asm [kernel]
 1: ret_from_fork [kernel]
  2: kthread [kernel]
   3: worker_thread [kernel]
    4: process_one_work [kernel]
     5: async_run_entry_fn [kernel]
      6: async_suspend [kernel]
       7: device_suspend [kernel]
        8: dpm_run_callback [kernel]
         9: pci_pm_suspend [kernel]
          10: __pm_runtime_resume [kernel]
           11: rpm_resume [kernel]
            12: rpm_callback [kernel]
             13: __rpm_callback [kernel]
              14: rtsx_pci_runtime_resume [rtsx_pci]
               15: mmc_detect_change [mmc_core]
                16: pm_wakeup_ws_event [kernel]

Reading the source, the problem is that `pci_pm_suspend()` wakes PCI(e) devices before sending them into a full sleep state, but in the process, `_mmc_detect_change()` will "Prevent system sleep for 5s to allow user space to consume the\n corresponding uevent"... which interrupts a system sleep in progress!

## Debugging userspace `wakeup_count`

One oddity I found was that even when I didn't get a failed sleep, stacksnoop said that `mmc_detect_change() → pm_wakeup_ws_event()` was still being called! This bug thread provides a possible solution to this last mystery; the kernel doesn't abort sleep from a wakeup event unless event checks are enabled, and perhaps it's only true when Plasma is "writing wakeup count file".

The docs for `/sys/power/wakeup_count` (https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power#:~:text=What:%09%09/sys/power/wakeup_count) say the file explicitly enables "taking into account the concurrent arrival of wakeup events". And I've found broken code in the kernel sending wakeup events during suspend. So when Plasma 6.5.0 enabled wakeup checks, it must've caused these events to abort suspend!

To test with this file disabled, I ran `sudo chmod -x /usr/libexec/kf6/kauth/wakeupsourcehelper` on a fresh Fedora boot. I tried sleeping from Win+L four times, the first and third with +x and the second and fourth with -x. The journal log "Some devices failed to suspend" only appeared with +x, suggesting this workaround is necessary and sufficient to fix failed suspends.

I think sleeping from the start menu doesn't fail, because `wakeupsourcehelper` only runs when sleeping from the lock screen:

- I started `journalctl --follow` and slept from the lock screen (which fades to black and turns off the screen). The journal contained a message: `systemd[1]: Started dbus-:1.3-org.kde.powerdevil.wakeupsourcehelper@4.service.` followed by "Some devices failed to suspend". Neither message appeared when sleeping from the start menu.
    - Is it an oversight that `wakeupsourcehelper` is never run by the start menu? https://invent.kde.org/plasma/powerdevil/-/blob/master/daemon/actions/bundled/suspendsession.cpp unconditionally calls "org.kde.powerdevil.wakeupsourcehelper" for sleep and hibernate, but we don't see it running.

## Workarounds

- On Arch Linux, blacklisting `rtsx_pci_sdmmc` fixed system sleep, at the cost of breaking the SD card reader.
- On Fedora, I added file `/etc/systemd/sleep.conf.d/mysleep.conf` with contents `[Sleep]\nSuspendState=mem mem`. This retries a failed suspend, and the second attempt will work.

## Next steps

To identify the kernel drivers at fault, I strongly recommend that people on this bug thread run:

echo 1 > /sys/power/pm_print_times
echo 1 > /sys/power/pm_debug_messages

then attempt a failed suspend (hopefully it doesn't crash), and see which devices show up in `journalctl --system -b0` or `dmesg` under "active wakeup source".
Then to identify the exact stack traces, you can also run `stacksnoop.py pm_wakeup_ws_event wakeup_source_register` with my bcc repo (or use upstream https://github.com/iovisor/bcc if you don't trust my code).

However once the patch is merged and disables `/sys/power/wakeup_count` in Plasma 6.5.3, I don't know how others would test what hardware is at fault. I think I'd need a powerdevil maintainer to suggest a course of action.

Created attachment 186829 [details]
Shell script to enable /sys/power/wakeup_count and trigger a failed sleep.

I've reproduced this bug without depending on KDE or wakeupsourcehelper. I have attached a shell script replicating wakeupsourcehelper's behavior.

If you run `sudo ./badsleep.sh`, it reads and writes `/sys/power/wakeup_count`, then triggers a mem sleep with `/sys/power/state`. (sudo is needed to write to `/sys/power/wakeup_count` on Fedora.) This reproduces failed sleeps on my computer:

- If I edit the script and comment out `echo $wakeup_count > /sys/power/wakeup_count`, the sleep succeeds, and waking the computer skips the lock screen and resumes where I left off.
- If I run the script unaltered, the screen turns off and on, and the terminal outputs `./badsleep.sh: line 14: echo: write error: Device or resource busy` indicating the mem sleep failed.
- If I run `sudo rmmod rtsx_pci_sdmmc` to disable the faulty module, the sleep succeeds, and waking the computer skips the lock screen and resumes where I left off.

I get unclear behavior when reloading the module. If I have stacksnoop running, and run `sudo modprobe rtsx_pci_sdmmc` quickly followed by `sudo ./badsleep.sh`, sleep succeeds and I do not see a pm_wakeup_ws_event() call in stacksnoop. If I wait over ~5 seconds after modprobe, sleep fails from `pm_wakeup_ws_event()` as usual. In past boots, sleep would sometimes stop breaking altogether, but I don't know what causes it, nor if pm_wakeup_ws_event() gets called then.

----

Unfortunately I will probably not be able to report a kernel bug soon.

- https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html says bug reports not tested on the latest mainline kernel may be rejected.
- I currently have a Fedora 43 installation in my NUC, and tried adding COPRs for @kernel-vanilla/mainline and @kernel-vanilla/mainline-wo-mergew.
    - However all kernel updates since 6.16.12 do not get found by GRUB2, because dnf installs them to /boot/efi/$(cat /etc/machine-id)/ and indexes them in /boot/efi/loader/entries/, but the GRUB kernel (and `sudo grubby --info=ALL`) looks in /boot/loader/entries/ and loads kernels from /boot/.
    - https://discussion.fedoraproject.org/t/f39-kernels-fail-to-install-when-boot-efi-machineid-is-present/96086 suggested renaming /boot/efi/$(cat /etc/machine-id)/, but `sudo dnf reinstall kernel-core` would fail because the boot partition was full. If I remove the folder entirely, `sudo dnf reinstall kernel-core` recreates this folder again.

Comment on attachment 186829 [details]
Shell script to enable /sys/power/wakeup_count and trigger a failed sleep.

(In reply to nyanpasu64 from comment #27)

> Unfortunately I will probably not be able to report a kernel bug soon.

Perhaps, submit it to RHBZ as an intermediate step? I expect that they'll file at the kernel's BZ if you can't.

I've reported my specific issue to the LKML at https://lore.kernel.org/linux-mmc/a242799a-d427-48e1-85ef-923f34df843a@gmail.com/T/#u. It's been close to a day so far with no response. TBH my past bug reports have not had a reply either, and a patch I sent was discussed but ultimately ignored.

I don't know if my "vanilla" kernel downloaded from a Fedora COPR is allowed for a bug report, or I'm supposed to build it from scratch instead. I did notice an issue where NetworkManager would think my Wi-Fi password is incorrect upon bootup, which would sometimes fix itself or rebreak after sleeping and waking the system. I suspect it's a kernel Wi-Fi bug but am not sure, and in any case don't feel like reporting it.

(In reply to nyanpasu64 from comment #29)

> I've reported my specific issue to the LKML at
> https://lore.kernel.org/linux-mmc/a242799a-d427-48e1-85ef-923f34df843a@gmail.
> com/T/#u. It's been close to a day so far with no response. TBH my past bug
> reports have not had a reply either, and a patch I sent was discussed but
> ultimately ignored.

That's why I suggest kernel Bugzilla. You'll get an explicit closure reason there, insofar as the report is well-formed. If you can prove that this affects users across distributions, they're usually receptive, from my experience.

> I don't know if my "vanilla" kernel downloaded from a Fedora COPR is allowed
> for a bug report, or I'm supposed to build it from scratch instead.

If you can empirically prove that the bug is in upstream source, how you build it doesn't matter. The closer to upstream, the better, however. They just want actionable information.

> I did
> notice an issue where NetworkManager would think my Wi-Fi password is
> incorrect upon bootup, which would sometimes fix itself or rebreak after
> sleeping and waking the system. I suspect it's a kernel Wi-Fi bug but am not
> sure, and in any case don't feel like reporting it.

*That* would be best reported to the COPR repository, via its Pagure issue section.

*** Bug 512022 has been marked as a duplicate of this bug. ***

I also ran into this for hibernation; "systemctl hibernate" and from the startmenu works, but not from the lock-screen. But even when triggered there is sometimes a case of the hibernation stalling (forever) after the journal message `PM: hibernation: hibernation entry`.
Active wake-up source for my laptop reports "PM: last active wakeup source: ADP1", which if i understand my quick search correctly, is the "AC-Adapter-1", but my laptop, at the time, is not even plugged in.

This did not happen with plasma 6.3.6 (yes old, but the only one available for some time in manjaro).
This happens with any kernel i tried

Removing the executable bit from "/usr/lib/kf6/kauth/wakeupsourcehelper" seem to work for me for all 3 hibernation cases (systemctl, start menu, lock screen) AND seemingly fixes the "hibernation stalling forever after X message".

Removing the executable bit from "/usr/lib/kf6/kauth/wakeupsourcehelper" seem to work for me for all 3 hibernation cases (systemctl, start menu, lock screen) AND seemingly fixes the "hibernation stalling forever after X message".

Finally, while testing this is got locked-out (and almost a second time) as the lock screen *for some reason* tries to log-in automatically with a empty password field, even though i have setting "Screen Locking -> Delay before password required" set to "require password immediately" and i cant find another related setting to turn this off.

About:
Operating System: Manjaro Linux 
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1
Kernel Version: 6.18.1-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 7 155H
Memory: 16 GiB of RAM (15,1 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: LG Electronics
Product Name: 17Z90SP-G.AA78G
System Version: 0.1

For reference, the discussions in manjaro's update threads:
- https://forum.manjaro.org/t/stable-update-2025-12-08-25-1-anh-linh-preview/183479/101
- https://forum.manjaro.org/t/stable-update-2025-12-15-kernels-nvidia-plasma-cosmic-firefox/183888/80

Good? news, Ulf Hansson has replied to my LKML message: https://lore.kernel.org/linux-mmc/CAPDyKFq55Vqfd7cMdmQZBzvS1Xr-Z4QaTzEeuWWn3EX4HBbP3A@mail.gmail.com/
Though he said he'd "get back to you in a couple of days", and it's been a week without reply. I didn't want to report to the bug tracker since the kernel was in a merge window, but I don't know when he'll reply on the mailing list.

(In reply to hasezoey from comment #32)
> I also ran into this for hibernation; "systemctl hibernate" and from the
> startmenu works, but not from the lock-screen. But even when triggered there
> is sometimes a case of the hibernation stalling (forever) after the journal
> message `PM: hibernation: hibernation entry`.
> Active wake-up source for my laptop reports "PM: last active wakeup source:
> ADP1", which if i understand my quick search correctly, is the
> "AC-Adapter-1", but my laptop, at the time, is not even plugged in.
> 
> This did not happen with plasma 6.3.6 (yes old, but the only one available
> for some time in manjaro).
> This happens with any kernel i tried

I'm not sure what's going on here. Looking at https://github.com/torvalds/linux/blob/40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb/drivers/base/power/wakeup.c#L859, it seems like you're *not* getting a wake from an active wakeup source, but one that was *deactivated* before Linux logs the failed suspend.

- I assume you saw the message by enabling `echo 1 > /sys/power/pm_debug_messages`? Or did you get it some other way?
- Do you see "PM: Wakeup pending, aborting suspend" directly before "last active wakeup source"?
- My next idea would be to check if there's a kernel stack trace of aborted sleep:
  - Clone https://github.com/nyanpasu64/bcc, cd into the directory, and run `sudo ./examples/tracing/stacksnoop.py pm_wakeup_ws_event wakeup_source_register`.
  - With stacksnoop running, download https://bugs.kde.org/attachment.cgi?id=186829, open a new terminal panel/tab, and run `sudo ./badsleep.sh` to attempt sleep.
  - Send the contents of both terminal tabs as text (truncated if neccessary). Preferably attach your `journalctl --system -b0 > journal.txt` to give a more complete picture. If it's too long to read, you can reboot before running the test, or trim the journal after saving it.

> Finally, while testing this is got locked-out (and almost a second time) as
> the lock screen *for some reason* tries to log-in automatically with a empty
> password field, even though i have setting "Screen Locking -> Delay before
> password required" set to "require password immediately" and i cant find
> another related setting to turn this off.

I've gotten this issue too. Though I didn't know it was an *actual* failed login that could trigger lockouts, I thought it was just a kscreenlocker_greet cosmetic error. Would you mind reporting it separately and linking it here so I can CC?

Created attachment 187732 [details]
badsleep.sh journalctl log

(In reply to nyanpasu64 from comment #33)
> I'm not sure what's going on here. Looking at
> https://github.com/torvalds/linux/blob/
> 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb/drivers/base/power/wakeup.c#L859,
> it seems like you're *not* getting a wake from an active wakeup source, but
> one that was *deactivated* before Linux logs the failed suspend.
> 
> - I assume you saw the message by enabling `echo 1 >
> /sys/power/pm_debug_messages`? Or did you get it some other way?

Yes, i gathered the data via the instructions in Comment #26 ("echo 1 | sudo tee /sys/power/pm_print_times" & "echo 1 | sudo tee /sys/power/pm_debug_messages")

> - Do you see "PM: Wakeup pending, aborting suspend" directly before "last
> active wakeup source"?

Yes:
kernel: Filesystems sync: 0.032 seconds
kernel: Freezing user space processes
kernel: PM: Wakeup pending, aborting suspend
kernel: PM: last active wakeup source: ADP1
kernel: Freezing user space processes aborted after 0.000 seconds (51 tasks refusing to freeze, wq_busy=0):

> - My next idea would be to check if there's a kernel stack trace of aborted
> sleep:
>   - Clone https://github.com/nyanpasu64/bcc, cd into the directory, and run
> `sudo ./examples/tracing/stacksnoop.py pm_wakeup_ws_event
> wakeup_source_register`.
>   - With stacksnoop running, download
> https://bugs.kde.org/attachment.cgi?id=186829, open a new terminal
> panel/tab, and run `sudo ./badsleep.sh` to attempt sleep.

When i had *not* used the script yet, i already had a stacktrace, might this be helpful or related?
kernel: Freezing user space processes aborted after 0.000 seconds (51 tasks refusing to freeze, wq_busy=0):
kernel: task:QDBusConnection state:R stack:0     pid:1805  tgid:1804  ppid:1      task_flags:0x400040 flags:0x00080003
kernel: Call Trace:
kernel:  <TASK>
kernel:  ? __schedule+0x420/0x1320
kernel:  ? obj_cgroup_charge_account+0x145/0x420
kernel:  ? __memcg_slab_post_alloc_hook+0x18d/0x370
kernel:  ? schedule+0x27/0xd0
kernel:  ? schedule_hrtimeout_range_clock+0x117/0x120
kernel:  ? remove_wait_queue+0x1a/0x70
kernel:  ? poll_freewait+0x3f/0xa0
kernel:  ? do_sys_poll+0x47c/0x590
kernel:  ? update_load_avg+0x7b/0x730
kernel:  ? update_curr+0x8e/0x1a0
kernel:  ? sched_balance_newidle+0x358/0x450
kernel:  ? update_entity_lag+0x71/0x80
kernel:  ? psi_group_change+0x10c/0x2c0
kernel:  ? psi_task_switch+0x113/0x2a0
kernel:  ? __schedule+0x418/0x1320
kernel:  ? schedule+0x27/0xd0
kernel:  ? __refrigerator+0xb9/0x130
kernel:  ? get_signal+0x5ba/0x840
kernel:  ? arch_do_signal_or_restart+0x3f/0x270
kernel:  ? exit_to_user_mode_loop+0x78/0x160
kernel:  ? do_syscall_64+0x1f1/0x7f0
kernel:  ? __sys_sendmsg+0xcd/0xf0
kernel:  ? do_syscall_64+0x81/0x7f0
kernel:  ? ksys_read+0xcd/0xf0
kernel:  ? do_syscall_64+0x81/0x7f0
kernel:  ? do_syscall_64+0x81/0x7f0
kernel:  ? exc_page_fault+0x7e/0x1a0
kernel:  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
kernel:  </TASK>
kernel: OOM killer enabled.

>   - Send the contents of both terminal tabs as text (truncated if
> neccessary). Preferably attach your `journalctl --system -b0 > journal.txt`
> to give a more complete picture. If it's too long to read, you can reboot
> before running the test, or trim the journal after saving it.

Note that i had tried to run stacksnoop, but it says "no module named bcc" , which was fixed with a "pacman -S bcc bcc-tools python-bcc" as their install guide says.
I have tried running it, but "stacksnoop" script does not output more than the "TIME(s) FUNCTION" headers and badsleep only outputs what the script already includes: "./badsleep.sh: line 14: echo: write error: Device or resource busy".
Though when using badsleep, the "last active wakeup source" is listed as "serio0". (see attachment "badsleep.sh journalctl log" for journalctl log of that time)

Note that this test has been done with "sudo chmod +x /usr/lib/kf6/kauth/wakeupsourcehelper" again (plus a reboot beforehand).

> > Finally, while testing this is got locked-out (and almost a second time) as
> > the lock screen *for some reason* tries to log-in automatically with a empty
> > password field, even though i have setting "Screen Locking -> Delay before
> > password required" set to "require password immediately" and i cant find
> > another related setting to turn this off.
> 
> I've gotten this issue too. Though I didn't know it was an *actual* failed
> login that could trigger lockouts, I thought it was just a
> kscreenlocker_greet cosmetic error. Would you mind reporting it separately
> and linking it here so I can CC?

I also thought it was only cosmetic, until i tried hibernation, which failed immediately, then tried to auto-login, then i tried putting in my password (incorrectly mind you, twice), then it said "3 failed attempts, locked for 10 minutes"(or something along the lines), looking in the journal also listed "pam_unix" failed login attempts corresponding to those times.
https://bugs.kde.org/show_bug.cgi?id=513476

---

PS: should this bug maybe be reopened?

I just re-read the fix from comment 24 (https://bugs.kde.org/show_bug.cgi?id=510992#c24 / https://invent.kde.org/plasma/powerdevil/-/commit/3eeb71e10083a6ed811b4662dd44ae303d1fe86b), and noticed that this workaround only reads "/sys/power/mem_sleep", and from my knowledge, that file does not actually say what suspend mode is currently taking place, meaning the script assumes anything but hibernation (suspend to disk), so the wakeup helper takes the "bad" path of writing to "/sys/power/wakeup_count" for hibernation.

For context:
$ cat /sys/power/mem_sleep
[s2idle]
$ cat /sys/power/state
freeze mem disk
$ cat /sys/power/disk
[plaform] shutdown reboot suspend test_resume

(In reply to hasezoey from comment #34)
> Created attachment 187732 [details]
> badsleep.sh journalctl log
> 
> (In reply to nyanpasu64 from comment #33)
> > I'm not sure what's going on here. Looking at
> > https://github.com/torvalds/linux/blob/
> > 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb/drivers/base/power/wakeup.c#L859,
> > it seems like you're *not* getting a wake from an active wakeup source, but
> > one that was *deactivated* before Linux logs the failed suspend.

Yeah, it does look like your system wake is not caused by an (active?) wakeup source. This time the last wakeup source is serio0 instead of ADP1.

> When i had *not* used the script yet, i already had a stacktrace, might this
> be helpful or related?

I'm not sure. If the process had deadlocked (eg. a syscall is blocked on a frozen FUSE process) while suspending, the backtrace would be useful. Here it's merely what the kernel was doing when it got interrupted immediately.

> I have tried running it, but "stacksnoop" script does not output more than
> the "TIME(s) FUNCTION" headers and badsleep only outputs what the script
> already includes: "./badsleep.sh: line 14: echo: write error: Device or
> resource busy".

Yeah this doesn't look to be caused by `wakeup_sources`. I do still think `pm_wakeup_pending()` is failing on `ret = (cnt != saved_count || inpr > 0)`, but don't know what code set these flags. I don't know when I'll be able to figure out though, I'm not dual-booted into my kernel development OS install.

I *would* suggest testing `sudo ./examples/tracing/stacksnoop.py pm_print_active_wakeup_sources` and then attempting sleep. But this may be less useful, since it only checks *when* it's being tested, not who's writing to it. On my computer, with suspend interrupted by my SD card reader, suspend is aborted at `async_suspend() > device_suspend() > pm_wakeup_pending() > pm_print_active_wakeup_sources()`. If you see a different chain of function calls, post the text here!

> PS: should this bug maybe be reopened?

Not a maintainer, but I'm going to tentatively reopen it, since you're seeing it on 6.5.4 and it was supposedly fixed on 6.5.3. Is there a possibility that Manjaro's 6.5.4 failed to properly include the changes from KDE's repos? I'm not knowledgeable enough to say.

(In reply to hasezoey from comment #35)
> I just re-read the fix from comment 24
> (https://bugs.kde.org/show_bug.cgi?id=510992#c24 /
> https://invent.kde.org/plasma/powerdevil/-/commit/
> 3eeb71e10083a6ed811b4662dd44ae303d1fe86b), and noticed that this workaround
> only reads "/sys/power/mem_sleep", and from my knowledge, that file does not
> actually say what suspend mode is currently taking place, meaning the script
> assumes anything but hibernation (suspend to disk), so the wakeup helper
> takes the "bad" path of writing to "/sys/power/wakeup_count" for hibernation.
> 
> For context:
> $ cat /sys/power/mem_sleep
> [s2idle]
> $ cat /sys/power/state
> freeze mem disk
> $ cat /sys/power/disk
> [plaform] shutdown reboot suspend test_resume

Not sure what this means, hopefully you can talk to a powerdevil maintainer and work this out?

For what it's worth, I updated to 6.5.4 on arch a week ago and my hibernate issue persists.  I have to run 'sudo chmod -x /usr/libexec/kf6/kauth/wakeupsourcehelper' again.