https://bugs.kde.org/show_bug.cgi?id=510992
nyanpasu64 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #36 from nyanpasu64 <[email protected]> --- (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.
