[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 TraceyC changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||[email protected] Ever confirmed|0 |1 Version|6.5.3 | Fixed/Implemented|| In|| --- Comment #50 from TraceyC --- Setting to confirmed since multiple people have reproduced this -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #49 from [email protected] --- I hadn't tested this in a few months so decided to check whether it was still broken for me. Unfortunately it is. I looked into it a bit further by following some of the suggestions to enable PM debugging and found two different wakeup sources ( hidpp_battery_1 and PNP0C0C:00). hidpp_battery_1 is due to my Logitech USB mouse/keyboard, but when I removed the dongle and tried hibernating I got PNP0C0C:00. In my situation, starting hibernation using systemctl from the command line or from the Session Manager works fine. The problem only exists when I start hibernation using a keyboard shortcut. Operating System: Arch Linux KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.11.0 Kernel Version: 6.19.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: Intel Core 7 150U (10 cores) Memory: 16 GiB of RAM Graphics Processor: Intel Raptor Lake-U Manufacturer: Lenovo Product Name: IdeaPad 5 2-in-1 16IRU9 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 JumpyLionnn changed: What|Removed |Added CC||[email protected] --- Comment #48 from JumpyLionnn --- I am also experiencing this issue. The difference from me and other people here is that I noticed that it fails to suspend only when certain apps are open, like brave browser, elisa music player and maybe arduino ide. when it fails, I have a black screen the fans are still spinning and the lights are on. no matter what I press it doesn't wake up so I need to press the power button for a long time to shut down and then restart. Here are my system details: Operating System: Fedora Linux 43 KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2 Kernel Version: 6.19.10-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-4570 CPU @ 3.20GHz Memory: 16 GB of RAM (15.5 GB usable) Graphics Processor 1: NVIDIA GeForce GTX 750 Graphics Processor 2: Intel® HD Graphics 4600 Manufacturer: ASUS Product Name: All Series -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #47 from [email protected] --- I was recently able to upgrade to Plasma 6.5.5 and I am still seeing the issue, if wakeupsourcehelper is active then sleep does not work properly. Here are my OS details: Operating System: Manjaro Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.8-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Intel® Iris® Xe Graphics Manufacturer: HP Product Name: HP Spectre x360 Convertible 15-eb1xxx -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #46 from [email protected] --- (In reply to Nate Graham from comment #39) > Anyone who was seeing this in the past, are you still seeing it in Plasma > 6.5.5 or 6.5 beta, or current git master, and also with a newer kernel > version? I have tested suspending through: - Application Launcher sleep button - Suspend keyboard shortcut - Lock Screen sleep button - Idling until it suspends and all have been working fine for the past few weeks. I am no longer able to reproduce this issue. My system details: Operating System: Arch Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.2 Kernel Version: 6.18.8-arch2-1 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 9900X 12-Core Processor Memory: 32 GiB of RAM (30,9 GiB usable) Graphics Processor: AMD Radeon RX 9070 XT Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7E51 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Scarlett Moore changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #45 from [email protected] --- (In reply to alexptwomey from comment #42) > Currently on EndeavorOs. > 6.18.7-arch1-1 > Plasma 6.5.5 > Still seeing bug. A little more information, if i `chmod -x wakeupsourcehelper` then i get these logs when I should see sleep triggering: Feb 03 20:38:00 endeavorOs (wakeupsourcehelper)[2795]: dbus-:[email protected]: Unable to locate executable ‘/usr/lib/kf6/kauth/wakeupsourcehelper’: Permission denied Feb 03 20:38:00 endeavorOs (wakeupsourcehelper)[2795]: dbus-:[email protected]: Failed at step EXEC spawning /usr/lib/kf6/kauth/wakeupsourcehelper: Permission denied Feb 03 20:38:00 endeavorOs systemd[1]: dbus-:[email protected]: Main process exited, code=exited, status=203/EXEC Feb 03 20:38:00 endeavorOs systemd[1]: dbus-:[email protected]: Failed with result ‘exit-code’. Feb 03 20:38:00 endeavorOs org_kde_powerdevil[1409]: Failed to write wakeup_count: “DBus Backend error: service start org.kde.powerdevil.wakeupsourcehelper failed: Could not activate remote peer ‘org.kde.powerdevil.wakeupsourcehelper’: unit failed” -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #44 from [email protected] --- (In reply to nyanpasu64 from comment #43) > It's been a bit and I haven't been following this issue, but does sleep also > fail when triggering it through the Win+L lock screen's Sleep button? Yes when I press Win+L I get a black screen but no indications that the PC has gone to sleep like fans stopping. If I wait 1 minute on the black screen for the automatic time out to lock the screen I once again get the 'failed to write wakeup_count' error. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #43 from nyanpasu64 --- (In reply to alexptwomey from comment #42) > Manual sleep mode works when I click from the app menu, but the timed > automatic sleep does not. It's been a bit and I haven't been following this issue, but does sleep also fail when triggering it through the Win+L lock screen's Sleep button? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #42 from [email protected] --- Currently on EndeavorOs. 6.18.7-arch1-1 Plasma 6.5.5 Still seeing bug. I tried applying the fix for wakeupsourcehelper here but that did not work. When I run 'journalctl --user -u plasma-powerdevil -f' and monitor the output, when the system should suspend i get `Jan 31 11:20:37 endeavorOs org_kde_powerdevil[1442]: Failed to write wakeup_count: "DBus Backend error: service start org.kde.powerdevil.wakeupsourcehelper failed: Could not activate remote peer 'org.kde.powerdevil.wakeupsourcehelper': unit failed" ` Manual sleep mode works when I click from the app menu, but the timed automatic sleep does not. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Roke Julian Lockhart Beedell <[email protected]> changed: What|Removed |Added CC|4wy78uwh@rokejulianlockhart | |.addy.io| -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #41 from [email protected] --- I am still seeing it in KDE Plasma 6.5.4 and Kernel 6.18.4-1 on Manjaro. Granted not Plasma 6.5.5, which as far as I'm aware hasn't been released for Manjaro yet. If the wakeupsourcehelper is active, hibernate fails. Checked as of today. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nate Graham changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Ever confirmed|1 |0 Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #40 from [email protected] --- I'm still seeing on Plasma 6.5.5. Arch linux, kernel 6.18.5. Updated system on Jan 15th. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nate Graham changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REOPENED|NEEDSINFO --- Comment #39 from Nate Graham --- Anyone who was seeing this in the past, are you still seeing it in Plasma 6.5.5 or 6.5 beta, or current git master, and also with a newer kernel version? If so, please mention your distro, plasma version, and kernel version. Thanks@ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #38 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #37 from nyanpasu64 --- (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? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 nyanpasu64 changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #36 from nyanpasu64 --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #35 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #34 from [email protected] --- Created attachment 187732 --> https://bugs.kde.org/attachment.cgi?id=187732&action=edit 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: 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: 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
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #33 from nyanpasu64 --- Good? news, Ulf Hansson has replied to my LKML message: https://lore.kernel.org/linux-mmc/capdykfq55vqfd7cmdmqzbzvs1xr-z4qatzeeuwwn3ex4hbb...@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? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #32 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Sam James changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nate Graham changed: What|Removed |Added CC||[email protected] --- Comment #31 from Nate Graham --- *** Bug 512022 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #30 from Roke Julian Lockhart Beedell <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #29 from nyanpasu64 --- I've reported my specific issue to the LKML at https://lore.kernel.org/linux-mmc/[email protected]/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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #28 from Roke Julian Lockhart Beedell <[email protected]> --- Comment on attachment 186829 --> https://bugs.kde.org/attachment.cgi?id=186829 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #27 from nyanpasu64 --- Created attachment 186829 --> https://bugs.kde.org/attachment.cgi?id=186829&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Roke Julian Lockhart Beedell <[email protected]> changed: What|Removed |Added CC||4wy78uwh@rokejulianlockhart ||.addy.io -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 nyanpasu64 changed: What|Removed |Added CC||[email protected] --- Comment #26 from nyanpasu64 --- 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 suf
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #25 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nate Graham changed: What|Removed |Added Version||6.5.3 Fixed/Implemented|| In|| -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Bhushan Shah changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/powerdevil/-/commit/e49f |ma/powerdevil/-/commit/3eeb |9ae776a35016f2f280e752613db |71e10083a6ed811b4662dd44ae3 |9c56df688 |03d1fe86b --- Comment #24 from Bhushan Shah --- 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 -4daemon/wakeupsourcehelper.cpp https://invent.kde.org/plasma/powerdevil/-/commit/3eeb71e10083a6ed811b4662dd44ae303d1fe86b -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Bhushan Shah changed: What|Removed |Added Status|ASSIGNED|RESOLVED Latest Commit||https://invent.kde.org/plas ||ma/powerdevil/-/commit/e49f ||9ae776a35016f2f280e752613db ||9c56df688 Resolution|--- |FIXED --- Comment #23 from Bhushan Shah --- 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 -4daemon/wakeupsourcehelper.cpp https://invent.kde.org/plasma/powerdevil/-/commit/e49f9ae776a35016f2f280e752613db9c56df688 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #22 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/587 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Bhushan Shah changed: What|Removed |Added CC||[email protected] --- Comment #20 from Bhushan Shah --- *** Bug 510814 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Bhushan Shah changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #21 from Bhushan Shah --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #19 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #16 from Dejan --- > There is no /usr/lib/kf6/kauth/wakeupsourcehelper on my system however Try /usr/libexec/kf6/kauth/wakeupsourcehelper -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #18 from [email protected] --- *** Bug 511597 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #17 from [email protected] --- (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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #15 from [email protected] --- 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Dr Liz Asher changed: What|Removed |Added CC||[email protected] --- Comment #14 from Dr Liz Asher --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Dejan changed: What|Removed |Added CC||[email protected] --- Comment #13 from Dejan --- The workaround with the execution bit worked for me too. Thank you. But can we find out which hardware is the culprit? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nate Graham changed: What|Removed |Added Priority|NOR |HI -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Sander van Grieken changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #12 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #11 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #10 from Synthetic451 --- @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? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #9 from [email protected] --- I am wondering why does it work fine when suspending through the Application Launcher? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #8 from Bhushan Shah --- 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? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #7 from Nicolas Fella --- "Some devices failed to suspend, or early wake event detected" comes from https://github.com/torvalds/linux/blob/fd57572253bc356330dbe5b233c2e1d8426c66fd/kernel/power/suspend.c#L519 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nicolas Fella changed: What|Removed |Added CC||[email protected] --- Comment #6 from Nicolas Fella --- https://invent.kde.org/plasma/powerdevil/-/merge_requests/570 and https://invent.kde.org/plasma/powerdevil/-/merge_requests/556 look potentially related -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Nicolas Fella changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 Vasyl Demin changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #5 from [email protected] --- I can also confirm anthonyjbarricelli's behaviour. Sleeping from the Application Launcher works fine. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #4 from Synthetic451 --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 --- Comment #3 from [email protected] --- Created attachment 186149 --> https://bugs.kde.org/attachment.cgi?id=186149&action=edit 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 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] ||m --- Comment #2 from [email protected] --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992 [email protected] changed: What|Removed |Added CC||[email protected] --- Comment #1 from [email protected] --- 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]: [1761402864.7021] manager: sleep: sleep requested (sleeping: no enabled: yes) out 25 15:34:24 desktop-nfp NetworkManager[1892]: [1761402864.7022] manager: NetworkManager state is now ASLEEP out 25 15:34:24 desktop-nfp NetworkManager[1892]: [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]: [1761402864.7202] device (enp9s0): state change: deactivating -> disconnected (reason 'sleeping', managed-type: 'full') out 25 15:34:24 desktop-nfp NetworkManager[1892]: [1761402864.7205] dhcp4 (enp9s0): canceled DHCP transaction out 25 15:34:24 desktop-nfp NetworkManager[1892]: [1761402864.7205] dhcp4 (enp9s0): activation: beginning transaction (timeout in 45 seconds) out 25 15:34:24 desktop-nfp NetworkManager[1892]: [1761402864.7205] dhcp4 (enp9s0): state changed no lease out 25 15:34:24 desktop-nfp kernel: r8169 :09:00.0 enp9s0: Link is Up - 1Gbps/Full - flow control rx/tx out 25 15:34:24 desktop-nfp NetworkManager[1892]: [1761402864.7545] device (enp9s0): state change: disconnected -> unmanaged (reason 'unmanaged-sleeping', managed-type: 'full') out 25 15:34:24 desktop-nfp kernel: r8169 :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]: [email protected]: 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]: [email protected]: 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 510992] Plasma 6.5.0 doesn't suspend to RAM on the first try ("PM: Some devices failed to suspend, or early wake event detected")
https://bugs.kde.org/show_bug.cgi?id=510992
Nate Graham changed:
What|Removed |Added
Keywords||regression
Summary|Plasma 6.5.0 doesn't|Plasma 6.5.0 doesn't
|suspend to RAM on the first |suspend to RAM on the first
|try |try ("PM: Some devices
||failed to suspend, or early
||wake event detected")
CC||[email protected]
--
You are receiving this mail because:
You are watching all bug changes.
