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

Solution 1:

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.

Solution 2:

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.

Solution 3:

I enabled hibernation some month ago in my Ubuntu system, now 20.04, but now as in the past I had some issue. So in this last event I found this in "dmsg" during hibernation procedure:

 Freezing of tasks failed after 20.005 seconds (0 tasks refusing to freeze, wq_busy=1)...

I solved with increasing the freezing timeout from 20 sec to 30 sec:

echo 30000 > /sys/power/pm_freeze_timeout

and made I it permanent with sysfsutils and after writing

power/pm_freeze_timeout = 30000

in a file in the /etc/sysfs.d directory