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 提示里一闪而过的驱动函数名——把这些碎片拼起来，才可能还原出硬件信号抖动 → 驱动等待超时 → 内核线程卡死 → 看门狗复位的完整链路。漏掉任意一环，排查就可能退回原点。
