3

Context : sometimes my laptop won't go to sleep mode with the error

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

I know this is an indication that a workqueue is misbehaving (https://askubuntu.com/questions/692700/what-does-wq-busy-1-indicate-in-a-failure-to-suspend) and after much fiddling, I ended up checking the output of magic 't' SysRq, and that indicated a workqueue related to memstick was apparently stalled. The output of cat /proc/WORKER-PID/stack was always stuck in a function called memstick_set_rw_addr. IIUC this function is from a kernel module called memstick. This module is required by another module named rtsx_pci_ms, which I then tried to unload. I did modprobe -r rtsx_pci_ms but it showed nothing and wouldn't return (and I couldn't even kill modprobe once it was running, it simply did not react to killall -KILL modprobe nor to Control+C). [I then had to poweroff so I can't test anything right now but the situation happens about once or twice a week so I will encounter it again.]

So now the question is how do I force kill whatever a module is doing if "modprobe -r" is stuck ?

2

You cannot force-kill kernel code if it doesn't want to be killed. Kernel code can't be killed at arbitrary times because it might be in the middle of accessing a peripheral, it might hold a lock, it might have allocated some resources that need to be freed… Userland code can be killed because the kernel holds all these resources on behalf of the process and cleans them up if the process dies. But inside the kernel, each piece of code must handle its own cleanup.

Normally, kernel code will check for signals and cleanly quit what it's doing if it receives a signal. But you've encountered a kernel bug. In this case, you're out of luck. If the code is stuck, it's stuck. Since the stuck code is executing in the context of a process's system call, that system call will never return (unless the situation inside the kernel somehow corrects itself). The process is in the middle of a system call, so it can't be killed. The KILL signal is queued up, and if the system call ever returned then the process would die immediately, but if the system call doesn't return, the process is stuck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.