https://bugs.kde.org/show_bug.cgi?id=522307
--- Comment #8 from [email protected] --- Thanks for the detailed guidance on points 1-4 above — I really appreciate the depth of the suggestions. I have to be upfront though: the gdb breakpoint script, debug symbol setup, and correlating serial/reply_serial pairs across a multi-million-line dbus-monitor capture is beyond what I'm able to reliably do myself at this point. I gave it a try (installed gdb, attempted debuginfod/debug repos) but didn't get clean, symbol-resolved results, and I don't want to send you noisy or misleading data. What I *can* offer, and which I think is solid evidence on its own: I rolled the system back via a Btrfs/snapper snapshot taken immediately before pam_kwallet6 was updated from 6.7.0 to 6.7.1, and have now locked the package at that version: pam_kwallet6-6.7.0-1.1.x86_64 pam_kwallet6-common-6.7.0-1.1.noarch kwalletd6-6.27.0-1.1.x86_64 (unchanged) kf6-kwallet-6.27.0-1.1.x86_64 (unchanged) With pam_kwallet6 back at 6.7.0 (and kwalletd6 untouched at 6.27.0), suspend/resume + screen unlock now works correctly with no CPU loop, across repeated real-world use (not just a one-off test boot). This points fairly specifically at something introduced between pam_kwallet6 6.7.0 and 6.7.1 as the trigger for this behavior in kwalletd6. I'm not able to commit to further interactive debugging sessions (gdb, symbol resolution, raw D-Bus trace correlation) at this point — it's a bit beyond what I can reliably do on my own. Thanks again for taking the time to look into this; hopefully the version regression info is useful in narrowing things down. -- You are receiving this mail because: You are watching all bug changes.
