内核日志（dmesg、/var/log/kern.log）是定位Linux卡死根源的首要依据，需在卡死前或瞬间通过SysRq、串口、kdump或dmesg -w捕获；重点关注soft/hard lockup、RCU stall、I/O error、OOM Killer等关键词及上下文调用栈，并结合sysctl调优与硬件检测预防。
Linux系统卡死时，内核日志（dmesg 输出和 /var/log/kern.log）是最直接的线索来源。关键不是等系统恢复后查日志，而是在卡死前或刚卡死时尽可能保留现场信息——尤其是无法操作终端时，需依赖串口、SysRq 或提前配置的日志捕获机制。
卡死时如何获取有效内核日志
系统完全无响应时，常规命令（如 dmesg、journalctl）已不可用。此时可尝试：
- 若启用 SysRq（kernel.sysrq=1），按 Alt+SysRq+R E I S U B 安全同步并重启，重启后立即执行 dmesg -T | tail -n 200 查看最近日志；
- 通过串口控制台（如使用 UART 连接开发板或服务器 BMC）实时捕获卡死瞬间的 oops、soft lockup、hard lockup 或 NMI watchdog 日志；
- 在正常运行时启用 kdump（配合 kexec），触发 panic 时自动生成 vmcore，用 crash 工具分析内核堆栈；
- 将 dmesg -w 后台写入文件（如 dmesg -w > /var/log/dmesg-live.log &），虽不能覆盖完全卡死，但对“假死”（如 UI 冻结但内核仍工作）有帮助。
重点关注的日志关键词与含义
翻阅 dmesg 输出时，以下关键词往往指向卡死根源：
- “BUG: soft lockup”：某 CPU 上某个内核线程持续运行超 20 秒未调度，常见于驱动死循环、中断处理过长或锁竞争；
- “NMI watchdog: BUG: soft/hard lockup”：硬件级看门狗触发，说明 CPU 级别已停滞，可能因内存错误、CPU 故障或严重中断风暴；
- “INFO: rcu_preempt detected stalls”：RCU 机制检测到宽限期停滞，多见于长时间关中断、大页内存压力或虚拟化环境中的 vCPU 调度异常；
- “ataX.Y: failed command: XXX” 或 “end_request: I/O error”：磁盘/SSD 固件异常或链路故障，可能导致进程在 D 状态长期阻塞，拖垮系统响应；
- “Out of memory: Kill process …” 后紧接大量 “task XXX blocked for more than 120 seconds”：OOM Killer 触发后，剩余进程因内存/锁资源争抢陷入深度等待。
结合上下文定位真实诱因
单条警告不足以定论，需结合时间戳、调用栈和前后行为综合判断：
- 看到 “soft lockup on CPU X”，立刻查看该 CPU 上最近的函数调用栈（通常紧跟在警告后），确认是哪个模块（如 nouveau、r8169、nvme）或哪段代码（如 _raw_spin_lock、__delay、copy_to_user）卡住；
- 若卡死前出现大量 “irq X: nobody cared”，说明中断未被正确处理，可能引发中断屏蔽累积，最终导致调度停滞；
- 在虚拟机中卡死，注意检查宿主机 dmesg 是否有 “KVM: stealing halt” 超时或 “MMIO read/write to XXX” 异常，可能是客户机驱动与 KVM 模拟不兼容；
- 启用 CONFIG_LOCKDEP 和 CONFIG_DEBUG_ATOMIC_SLEEP 编译内核，可在复现时提前捕获死锁或非法睡眠，避免等到卡死才暴露。
日常预防与快速响应建议
与其等卡死再分析，不如构建可观测防线：
- 在 /etc/sysctl.conf 中设置：kernel.watchdog_thresh = 30（延长软锁超时判定，避免误报），并开启 kernel.hung_task_timeout_secs = 60；
- 部署 systemd-coredump + coredumpctl，捕获用户态进程崩溃前状态，辅助判断是否由某服务异常引发内核级连锁反应；
- 对关键服务器，配置 rsyslog 将 kern.* 日志实时转发至远程日志服务器，确保本地磁盘损坏时日志不丢失；
- 定期运行 sudo smartctl -a /dev/sdX 和 sudo memtester 1G 3（内存测试慎用），排除硬件隐性故障这一常见卡死源头。
