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
flar@allandria.com
Reply to: