dmesg -T | grep "Call Trace:" 不够用，因它仅输出单行、缺失 panic 前5行预警（如驱动加载失败）和后20行完整调用栈及寄存器状态，无法定位根因。
直接看 dmesg -T 输出里带 Call Trace: 的那一段，但必须配合 -A 20 -B 5 才能抓到完整上下文——单独执行 dmesg 很大概率漏掉关键帧。
为什么 dmesg -T | grep "Call Trace:" 不够用
内核 panic 或 oops 发生时，Call Trace: 后面的函数调用栈是核心线索，但它不是孤立存在的。真正要命的前兆（比如某个驱动模块加载失败、内存分配失败警告）往往在它上面几行；而崩溃后的寄存器状态、CPU 信息则在下面几十行。默认 grep 只匹配单行，会切断逻辑链。
-
dmesg -T | grep "Call Trace:"只输出那一行，没上下文，没法判断是哪个模块触发的 - 不加
-T时间戳，重启后日志混在一起，分不清哪次 panic 对应哪次启动 - 不加
-A 20，看不到完整的调用栈深度（很多关键函数藏在第 10~18 行） - 不加
-B 5，找不到 panic 前最后一条 warning，比如WARNING: CPU: 0 PID: 123 at drivers/net/wireguard/main.c:456 wg_device_init+0x2a/0x100
怎么从 /var/log/kern.log 里捞出有效的 panic 片段
如果系统已重启，dmesg 环形缓冲区早被覆盖，得去文本日志里翻。但 /var/log/kern.log 通常被轮转，最新一次崩溃不一定在 kern.log 里，而在压缩归档中。
- 先查最近一个压缩日志：
zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic" - 如果没找到，继续往前：
zcat /var/log/kern.log.2.gz | grep -A 20 -B 5 "Oops" - 注意：有些发行版（如 Ubuntu）把内核日志写进
/var/log/syslog，得换路径搜：grep -A 20 -B 5 -E "(Kernel panic|Oops)" /var/log/syslog - 别依赖
journalctl -b -1 | grep panic——journal在 panic 瞬间可能根本来不及刷入磁盘
crash 工具解析 vmcore 时，哪些命令最实用
有 vmcore 文件且装好了对应版本的 vmlinux，crash 是唯一能还原崩溃瞬间内存状态的工具。但别一上来就 bt，容易卡在无关线程上。
- 先确认崩溃线程：
ps | grep "RUN|UNINT"，找状态异常的进程（比如R状态但 CPU 占用为 0） - 再定位具体线程栈：
bt <pid></pid>，而不是无差别bt—— 全局bt会列出所有 CPU 的栈，干扰判断 - 查模块嫌疑：
mod列出所有加载模块，重点盯住方括号里的名字，比如[nvidia]、[zfs]、[wireguard] - 看内存页错误：
mem -f配合dmesg里mm_*相关报错，交叉验证是否硬件 ECC 故障
Call Trace 里哪些函数名该立刻停住往下读
调用栈不是从上往下读，而是从最底端（也就是离 panic 最近的那一行）往上推。关键不是看 do_IRQ 或 __schedule 这种通用函数，而是找第一个非内核通用层的符号。
- 看到
ext4_writepages+0x123/0x456？说明问题在文件系统写回路径，立刻查磁盘健康：smartctl -a /dev/sda - 出现
nv_gpu_bind+0x45/0x100 [nvidia]？第三方驱动没适配当前内核，重装或回退驱动 - 全是
try_to_unmap+0x78/0x320、shrink_inactive_list+0x210/0x890？OOM 或内存碎片严重，结合dmesg -T | grep -i "oom\|page allocation failure"确认 - 结尾是
unknown symbol 'some_func' or invalid opcode？内核模块 ABI 不匹配，检查modinfo输出的vermagic是否和当前uname -r一致
真正难的不是找到 Call Trace，而是判断哪一行才是“第一滴血”——它往往藏在 panic 上面第 3~7 行，而且可能看起来只是个 warning，不是 error。
