dmesg是离真相最近的日志源，需结合-T时间戳、关键词过滤、上下文分析、kdump验证、软硬复位双钩子及soft lockup检测综合排查内核故障。

看 dmesg 是第一反应，但得会筛、会定时、会关联

内核出问题，dmesg 是离真相最近的日志源——它不经过 syslog 守护进程，直接来自内核环形缓冲区，连 panic 前最后一行都可能留下。但盲目 dmesg 全量输出等于大海捞针。

• 优先加时间戳和过滤：用 dmesg -T | grep -i "error\|warn\|fail\|panic\|oops"，-T 把时间戳转成可读格式，避免对着 [ 12.345678] 猜时间
• 注意复位后日志会清空（除非配置了 log_buf_len 或启用 ramoops），所以要尽早抓；若系统频繁重启，建议搭配 dmesg -T -w 实时监听
• 关键线索常藏在上下文里：比如看到 blk_update_request: I/O error，别只盯这一行，往上翻 10 行，看是不是紧跟着 ata3.00: failed command: READ FPDMA QUEUED —— 这就指向 SATA 链路或硬盘固件问题，而非文件系统层
• 有些错误默认不打印（如 soft lockup 检测被关闭），需确认内核配置：cat /proc/sys/kernel/softlockup_panic 和 /proc/sys/kernel/hardlockup_panic，值为 1 才会触发 panic 并留下完整栈

kdump 不是“开了就行”，得验证捕获内核是否真能启动

kdump 是分析 kernel crash 的刚需手段，但很多现场配置完就以为万事大备，结果真 crash 时 /var/crash/ 下空空如也——问题往往出在捕获内核根本没起来。

• 检查保留内存是否足够：cat /sys/kernel/kexec_crash_size，常见工控机或小内存设备（≤2G）容易因预留不足导致 kdump 失败，建议至少预留 256MB（通过 crashkernel=256M 内核参数）
• 验证捕获流程是否通：手动触发一次 echo c > /proc/sysrq-trigger，观察是否生成 vmcore；若卡在 “Starting kdump service...” 或日志里出现 Failed to start kdump: No memory reserved for crash kernel，说明预留失败
• vmcore 生成后，务必用 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore 快速跑一遍，确认符号表能加载、bt 能打出栈——否则调试时才发现 vmlinux 版本不匹配，就晚了

复位原因不能靠猜，必须硬件+软件双钩子落地

工控场景下“莫名重启”最让人头疼，uptime 显示刚运行 3 小时，dmesg 却一片空白——大概率是硬件复位（看门狗、电源跌落、按键）绕过了内核日志路径。

• 软件侧加钩子：在 arch/arm64/kernel/traps.c（或其他架构对应文件）的 die()、arm64_notify_die()、panic() 入口处插入 pr_emerg("PANIC @ %pS\n", _RET_IP_);，确保 panic 时强制刷屏
• 硬件侧建黑匣子：利用片上 SRAM 或备用 flash 区域（如 SPI NOR 的 last 4KB），在 machine_restart()、arm_pm_restart() 等所有复位入口前，把 __builtin_return_address(0) 和关键寄存器（SP_EL1, ELR_EL1）写入，复位后由 bootloader 或 init 阶段读出并落盘
• 区分复位源：cat /sys/class/watchdog/watchdog0/status 可查看看门狗是否超时；某些 SoC（如 i.MX6）提供 src 寄存器，能直接读出上次复位是 POR / WDOG / SW_RST

别跳过 CPU 异常信号，soft lockup 往往是驱动死循环的前兆

系统没 panic，但响应迟滞、SSH 登录缓慢、top 里 %sy 持续 90%+，dmesg 却无报错？很可能是 soft lockup —— 内核线程在关中断或禁抢占状态下执行太久，被 watchdog 检测到但未触发 panic。

• 确认是否开启检测：cat /proc/sys/kernel/softlockup_panic 若为 0，则只会打印警告，不会 halt；建议设为 1（echo 1 > /proc/sys/kernel/softlockup_panic）并写入 /etc/sysctl.conf
• 典型软锁现场：INFO: task kworker/u8:2:123 blocked for more than 120 seconds. 后紧跟驱动函数名（如 dw_mci_wait_busy），说明 SDIO 驱动在等总线忙标志超时，可能因硬件信号异常或驱动未处理 timeout 分支
• 配合 perf 定位热点：perf record -e irq:softirq_entry -a sleep 10 可捕获软中断密集调用点；再用 perf report --sort comm,dso 查看哪个模块占最多

真正棘手的内核故障，往往不是单点报错，而是多个线索断点式分布：dmesg 里的 I/O error、kdump 里缺失的 vmcore、复位日志中混杂的 WDOG 和 POR 标记、以及 soft lockup 提示里一闪而过的驱动函数名——把这些碎片拼起来，才可能还原出硬件信号抖动 → 驱动等待超时 → 内核线程卡死 → 看门狗复位的完整链路。漏掉任意一环，排查就可能退回原点。

# linux  # var  # ssh  # 关键词  # 看门狗  # 报错  # 重启  # 单点  # 链路  # 让人  # 大海捞针  # 多个  # 线程  # class  # 循环  # 硬盘  # mac  # 栈  # ai  # 热点  # 架构  # echo  # sort  # for  # die  # Error  # 最多