进程 D 状态卡在 [kthreadd] 的 uninterruptible sleep 深挖方法

kthreadd卡在D状态说明其正等待底层资源且被深度阻塞，常见原因包括设备驱动未响应、存储栈挂起或文件系统元数据锁死，需通过/proc/2/stack定位内核栈顶调用并结合dmesg和设备状态排查。

为什么 kthreadd 会卡在 D 状态？

kthreadd 是内核线程的“父进程”，本身不执行实际任务，只负责 fork 出其他内核线程（如 ksoftirqd、khungtaskd）。它自己几乎不会长期处于 D 状态——一旦看到 kthreadd 被标记为 D（uninterruptible sleep），基本说明其正在等待某个底层资源，且该等待被阻塞在极深的内核路径中，比如：设备驱动未响应、存储栈挂起（如 NVMe timeout、iscsi 连接断开）、或文件系统元数据锁死（如 ext4 journal hang、xfs log stall）。

这不是配置问题，而是内核已陷入无法被信号中断的等待循环。此时 ps 或 top 显示的 D 状态只是表象，真正要追的是它所等待的那个子线程或驱动上下文。

用 /proc/[pid]/stack 定位卡点内核路径

直接读取 kthreadd 进程的内核栈是最快突破口：

• 先查 PID：ps -eo pid,comm,wchan | grep kthreadd → 得到 PID（通常是 2）
• 查看栈：cat /proc/2/stack
• 重点看栈顶几行：若出现 nvme_wait_ready、__nvme_submit_sync_cmd、wait_event_interruptible + 驱动名、xfs_log_force、ext4_journal_start、scsi_queue_rq 等，就指向了具体模块
• 若栈里反复出现 cpuidle_enter_state 或 do_idle，反而说明不是卡住，可能是误判（D 状态瞬时出现又消失）；需配合 watch -n1 'ps -o pid,comm,state,wchan -p 2' 持续观察

检查关联设备与存储栈状态

kthreadd 的 D 状态往往由它派生的子线程触发，而这些子线程多服务于 I/O 子系统。优先排查以下几类：

• 运行 dmesg -T | tail -50，搜索 timeout、reset、stuck、QUEUE_FULL、blk-mq、nvme、ata、iscsi 关键词
• 查块设备健康：cat /sys/block/nvme0n1/device/state（NVMe）或 smartctl -a /dev/sda（SATA）
• 检查 SCSI 主机状态：cat /sys/class/scsi_host/host*/state 和 /sys/class/scsi_host/host*/proc_name
• 若使用 LVM 或 multipath，运行 lvs -o +attr 和 mpathconf --show，确认无 stuck path

避免重启前的临时缓解与取证要点

硬重启可能丢失现场，但有些操作能争取时间或保留关键信息：

• 立即保存栈和日志：cat /proc/2/stack > /tmp/kthreadd.stack.$(date +%s)，再跑一次 dmesg -T > /tmp/dmesg.$(date +%s)
• 不要 kill kthreadd（PID 2）——这等于杀死整个内核调度根基，系统必然 panic
• 若怀疑是某块盘导致，可尝试 echo 1 > /sys/block/nvme0n1/device/delete（仅限热插拔支持设备，慎用）
• 若系统仍部分响应，用 crash 工具加载 vmlinux 和 vmcore（若有 kdump）分析：crash vmlinux vmcore → ps | grep D → bt

最常被忽略的一点：D 状态本身不可被 ps 或 top “刷新”出新信息，它的存在意味着内核已放弃上层干预能力；所有诊断必须围绕“谁让 kthreadd 等待”展开，而不是试图唤醒它。