kthreadd卡在D状态说明其正等待底层资源且被深度阻塞，常见原因包括设备驱动未响应、存储栈挂起或文件系统元数据锁死，需通过/proc/2/stack定位内核栈顶调用并结合dmesg和设备状态排查。
![进程 d 状态卡在 [kthreadd] 的 uninterruptible sleep 深挖方法](https://img.php.cn/upload/article/001/242/473/177020947095580.jpeg)
为什么 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 <pid>
最常被忽略的一点：D 状态本身不可被 ps 或 top “刷新”出新信息，它的存在意味着内核已放弃上层干预能力；所有诊断必须围绕“谁让 kthreadd 等待”展开，而不是试图唤醒它。
