Hi,

Previously, suspend to RAM worked 100% of the time. Recently (in the last few months perhaps?), it has started failing frequently, perhaps 10% of the time. I attempt to suspend, and the computer thinks for a bit, but nothing much happens in the end. However, it seems that something has happened, as the wifi no longer works. I had a look at /var/log/pm-suspend.log, which seems to suggest that the computer has suspended then almost immediately resumed.

Code: Select all

Tue Sep 10 16:00:19 EST 2013: performing suspend
Tue Sep 10 16:00:40 EST 2013: Awake.


I also had a look at /var/log/kern.log, which suggest that lancelot and krunner won't sleep.

Code: Select all

Sep 10 16:00:39 sparhawk-XPS-17 kernel: [53448.724859] Freezing user space processes ...
Sep 10 16:00:39 sparhawk-XPS-17 kernel: [53468.756989] Freezing of tasks failed after 20.01 seconds (2 tasks refusing to freeze, wq_busy=0):
Sep 10 16:00:39 sparhawk-XPS-17 kernel: [53468.757049] lancelot        R  running task        0 14138      1 0x0000000c
...
Sep 10 16:00:39 sparhawk-XPS-17 kernel: [53468.757153] krunner         R  running task        0 14264      1 0x0000000c


I'm happy to provide more thorough logs, but I'm not sure if I can send attachments to this forum. Cheers.

Does attaching a debugger to either krunner or lancelot reveal what tasks they are involved in which allows them to block the system from entering sleep? wq_busy is a reference to the workqueues used internally by the kernel.

bcooksley wrote:Does attaching a debugger to either krunner or lancelot reveal what tasks they are involved in which allows them to block the system from entering sleep? wq_busy is a reference to the workqueues used internally by the kernel.

Sorry, I'm not really sure what you meant here. I'm not sure how to go about "attaching a debugger". Also, are you saying that "wq_busy=0" suggests that there are no workqueues used by the kernel? (I'm not really sure what that means either anyway.)

You should be able to use a debugger, such as gdb, to generate a backtrace either during or after the suspend attempt to see what activities both processes are involved in at the time. It may give some clues as to why exactly they are able to block sleep from occurring.

It is rather unusual that an issue would affect Lancelot and KRunner, but not Plasma Desktop or any other workspace component though.

I just wanted to report back that I actually removed my Lancelot widget from the panel just before your reply, and replaced it with the standard launcher. I had already replaced krunner with mangonel previously. Unfortunately, the standard launcher requires krunner to be active for some of its functions, so I couldn't kill that (and krunner has the useful System Activity window). Nevertheless, I haven't had a suspend-related crash since I inactivated Lancelot ten days ago. I found Lancelot a bit more attractive, but there's no real functionality that I miss in the standard launcher, so I'll just stick with this for now.

Thanks again for your help.