https://bugs.kde.org/show_bug.cgi?id=510992
--- Comment #33 from nyanpasu64 <[email protected]> --- 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.
