What does wq_busy=1 indicate in a failure to suspend?

wq_busy is apparently the kernel's variable name for the busy flag on a workqueue. Why it was stuck at true for some workqueue on my machine is unclear, because the problem went away while I was trying to diagnose it. In case it's useful for someone in the future, I had done the following:

  1. Repeatedly until all applications were closed:
    1. Close an application.
    2. Attempt, unsuccessfully, to suspend.
  2. Disable networking.
  3. Attempt, unsuccessfully, to suspend.
  4. Reboot (intending to get a clean process list; I was going to progressively disable things in hopes that a non-critical process was the culprit).
  5. Attempt, unexpectedly successfully, to suspend.
  6. Re-enable networking.
  7. Attempt, again successfully, to suspend.

So, strictly based on observations, and not with any understanding of the problem, I would guess that the following is a workaround or fix:

  1. Disable networking.
  2. Reboot.
  3. Re-enable networking.

I had the same issue. wq_busy was 1. I suspected that it had started to happen after 18.10 upgrade.

I did some research and found a post about looking for hardware-specific solutions especially for laptops, and another post about cdemu.

https://forums.gentoo.org/viewtopic-t-952364-start-0.html

In my case, removing gcdemu, cdemu-client, cdemu-daemon, and then autoremove vhba-dkms and libmirage11 made my hibernation working again.

Tags:

Suspend

Dmesg

Log