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.