Re: kworker/u4:1+tau stuck on G4 Sawtooth

On Sat, Apr 05, 2025 at 09:19:35AM -0400, Bill deWindt wrote:
> Name:   kworker/u4:1+tau
> Umask:  0000
> State:  D (disk sleep)
> Tgid:   19
> Ngid:   0
> Pid:    19
> PPid:   2
> 
> ...
> 
> and iotop shows virtually nothing hitting the disk, not even the swapfile.

In spite of the name, state 'D' on Linux doesn't really mean disk sleep.
What it means is that the thread is in an uninterruptible sleep. Any
kernel driver that puts the thread to sleep in such a fashion can cause
this, even if it has nothing to do with storage.

What you need to do is look at the stack trace for that thread. Here's
an example from one of my systems (running an older kernel):

$ ps auxww | grep kworker
root         5  0.0  0.0      0     0 ?        S<    2024   0:00 [kworker/0:0H]
root        36  0.0  0.0      0     0 ?        S     2024   0:00 [kworker/u2:2]
root        72  0.0  0.0      0     0 ?        S<    2024   7:27 [kworker/0:1H]
root     11744  0.0  0.0      0     0 ?        S    Feb12   1:30 [kworker/u2:1]
root     17909  0.0  0.0      0     0 ?        S    05:26   0:06 [kworker/0:3]
root     25531  0.0  0.0      0     0 ?        S    14:28   0:00 [kworker/0:1]
root     25840  0.0  0.0      0     0 ?        S    14:33   0:00 [kworker/0:0]
$ sudo cat /proc/25840/stack
[<c02c50b4>] soft_cursor+0x20c/0x220
[<c005ceb8>] worker_thread+0x1c0/0x538
[<c0063ca8>] kthread+0xc8/0xdc
[<c0015420>] ret_from_kernel_thread+0x5c/0x64

If you are running as root, you won't need sudo on that command. Only
root can read the stack trace of a kernel thread.

None of these are in the state you have, but this is both different
hardware (a Mac Mini) and a different kernel version.

If you can get a clean stack trace from that thread, you can see what
code path in the kernel is causing it to sleep this way.

	Brad Boyer
	[email protected]