Description of problem: Kde has started to act up after a resume from suspend. Not always, but give it a few cycles (less than five though) and it's hanging. Shortcuts don't launch, wlan doesn't get up due to lacking secrets or it's just totally hung. Cursor moves about and I can easily get to console in tty2, but the kde is unresponsive. A few times it has also taken one cpu with it. I just don't know where to look for more information. I didn't see anything suspicious in dmesg or other logs, but I'm no kde expert. Version-Release number of selected component (if applicable): 4.11.14-3 How reproducible: Quite, a few suspends, especially if I give it some time in between, an hour or so. I'll look into this shortly. Steps to Reproduce: 1. suspend 2. resume Actual results: the screen lock may or may not be there and behind that kde may or may not work Additional info: lenovo thinkpad x1, I've kept f19 and f20 through for two years now and haven't experienced anything like this before. This started late last week. I update almost daily and I'm probably gonna rollback as soon as I figure out the reproducibility. I don't mind looking into this deeper, but I don't really know where to look. Just as for more info and I'll be sure to help.
It's easily reproducible now that I know what to look for. Three four suspend cycles and it's dbus-daemon and kded4 that hog one processor for about 30 seconds and then no much happens after that. Some features, like window switching still works, but most dbus related signaling seems to be down. I downgraded some January updates that might have anything to do with this based on my yum history in /var/lib/yum/history, but no help from there. (dbus, kde-runtime, kdelibs, NetworkManager, kde-settings, systemd and even linux-firmware) Some hints about what to look for or what to try would be appreciated. The only remedy so far has been to take down X with c-a-bs and relogin after which it works again for a few resume cycles.
Try any older kernels?
I did. A mainline 3.18.1 which I used with f20 and the same problem now. It used to work. I can give some of the 3.17 series f20 kernels a whirl, but I didn't use them that much during December, but just to be sure.
Same problem with 3.17.7-200.fc20.x86_64. 3rd resume and dbus-daemon and kded4 got wild after which custom keys and other things no longer work. Menu pops up, but doesn't launch anything and so forth.
The regression aspect of it is now pretty much confirmed. As I had upgraded from f20 to f21 on right at the end of December, it served as a good spot for a verification and I downgraded every upgrade since. I literally grepped my yum.log files for Upgrades in January, tidied with sed and in one fell swoop downgraded some 240 packets. And the bug's gone. I'll try to find some time to bisect this further, but that probably won't be today.
Ok, bisected it and found it. It's the bluedevil. And since there's another bug (#1183230) about it I'll close this as duplicate of that bug. *** This bug has been marked as a duplicate of bug 1183230 ***
undup'ing, but marking fixed by, https://admin.fedoraproject.org/updates/bluedevil-2.1-4.fc21