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: <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? -- You are receiving this mail because: You are watching all bug changes.
