Repository navigation
调度器死锁：fork 后所有任务睡眠、CPU0 卡 idle、CPU1 卡 pick_next_task（lmbench 全量 5/5 复现） #2167
Description
Activity
根因修正：不是调度器死锁，是 vfat root fs 损坏
进一步诊断推翻了"调度器死锁"的初步结论。真实根因是 root fs（vfat）在多轮 QEMU 强制关机（kill -9，模拟断电）后损坏，导致块设备 IO 极慢/卡死。
证据链
- 镜像分区是 vfat（此前误认为 ext4）。DragonOS guest 的 root fs 挂在镜像的 vfat 分区上。
- fsck.fat -n 只读检查（host 侧）：
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.Reclaimed 218153 unused clusters (893554688 bytes)——约 893MB 簇状态错误Invalid '..' entry（/sys、/ext4 目录项损坏）FATs differ（主 FAT 与备份 FAT 不一致）
- guest 内块 IO 慢 500 倍：同一 e2e 内
dd写 root fs 64MB 耗时 154.7s（434 kB/s），而写 ramfs 同大小只要 0.35s（194 MB/s）——vfat 写路径异常。 - 卡点全在依赖块 IO 的位置：
- run.sh ENOUGH 预计算（exec
enough二进制 = vfat 读）→ 卡 - run.sh 收尾
clean_up.sh（rm -f ext4.img= vfat 释放）→ 卡 - process_fork_lat 单独跑完全 ok（fork 不依赖块 IO，3 samples 9971µs）——与"块 IO 卡"完全吻合
- run.sh ENOUGH 预计算（exec
- 逐轮恶化：首轮完整跑完 47 指标（当时 vfat 尚可用），之后每轮 kill -9 进一步破坏 vfat，最终第一个 exec 就卡。
修正后的结论
- 现象（串口静默、任务全睡眠、gdb 看到 idle/pick_next_task）是所有任务阻塞在 vfat 块 IO 的表象，不是调度器本身的死锁
- 诱因是 vfat 无日志 + 断电式关机累积损坏
- 修复：重建镜像（已执行）；长期建议 e2e 结束后优雅关机或对 vfat 做定期 fsck
待验证
镜像重建完成后重跑全量，若 31+ 指标恢复且不再卡死，则本 issue 关闭；若 process_fork_lat 仍超时，再回到调度器方向调查。
关闭原因：根因已定位为 vfat root fs 在多轮强制关机（kill -9）后损坏导致块 IO 卡死，非调度器 bug。重建镜像 + 预置 /ext4 目录后 lmbench 全量恢复正常推进（无卡死）。遗留问题：DragonOS vfat 驱动写大文件（1GB）极慢，将另行跟踪。
现象
在 QEMU+KVM guest 上跑 lmbench 全量测试（
AUTO_TEST=benchmark，runner/run.sh），init.sh 完成后、run.sh 第一个 fork 处死锁：lmbench test environment initialized后完全静默（run.sh 卡在 ENOUGH 预计算的timeout ... enough命令替换的 fork 上）复现
gdb 现场（QEMU -gdb attach）
CPU0（RIP 0xffff800000171856，arch_idle_func 内）：
CPU0 不在正常 halt idle（正常
x86::halt()时 QEMU CPU 应接近 0%，实测 QEMU 占用 ~140%），疑似走了idle.rs的 IRQ 禁用分支spin_loop()。CPU1：
CPU1 卡在调度器选择路径。
初步分析
kernel/src/arch/x86_64/process/idle.rs:26-28：IRQ 禁用时 idle 进入spin_loop()忙转——CPU0 的状态与"中断被关掉/时钟 tick 丢失"一致kernel/src/sched/fair.rs:1704pick_next_task：EEVDF 选择路径卡住影响
lmbench 全量基准无法稳定运行（第一个 fork 就可能死锁），同时解释了此前 process_fork_lat 偶发超时（rc=124）现象。
环境
关联PR、Issue