crash命令加载匹配的vmlinux和vmcore即可进入交互式分析环境；必备三要素是：带调试符号的vmlinux文件、原始vmcore文件、与崩溃内核完全一致的版本，缺一不可。
直接用 crash 命令加载匹配的 vmlinux 和 vmcore 文件，就能进入交互式分析环境。关键不是“会不会启动”，而是“有没有配对的符号文件+转储文件+正确版本”。只要这三样齐了，分析过程本身是标准化、可复现的。
确认必备三要素是否齐全
crash 无法工作最常见的原因是缺一不可：
-
vmlinux：带完整调试符号的内核映像，路径通常为
/usr/lib/debug/lib/modules/$(uname -r)/vmlinux或/lib/debug/lib/modules/$(uname -r)/vmlinux；不是/boot/vmlinuz-*（那是压缩镜像，无调试信息） -
vmcore：kdump 生成的原始内存转储文件，一般位于
/var/crash/<hostname>-<timestamp>/vmcore</timestamp></hostname> -
版本严格一致：vmlinux 的内核版本号（
uname -r输出）必须与生成 vmcore 时运行的内核完全相同；哪怕只差一个补丁号，符号偏移就可能错位，导致解析失败或误读
启动 crash 并快速定位崩溃根源
执行命令后，crash 会自动输出首屏摘要，其中最需关注的是 PANIC 行：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行：
crash /path/to/vmlinux /path/to/vmcore - 首屏中找类似
PANIC: "BUG: unable to handle kernel NULL pointer dereference"的提示——这就是崩溃类型和直接原因 - 紧接着看
PID、COMMAND、CPU字段，知道是哪个进程、在哪个 CPU 上出的问题 - 输入
bt -v查看完整调用栈（backtrace），它会从崩溃点向上逐层展开函数调用，核心线索就在栈顶几帧
常用诊断命令及其典型用途
进入 crash 环境后，以下命令高频且实用：
-
ps：列出所有进程状态，标有*的是崩溃时正在运行的 task；结合PID可快速聚焦可疑进程 -
log：等价于dmesg，查看崩溃前最后几秒的内核日志，常含驱动报错、资源耗尽、硬件警告等上下文 -
irq：检查中断状态，若某 IRQ 长时间未响应或频繁触发，可能是硬件异常或驱动缺陷 -
kmem -i：查看内存总体使用情况，辅助判断是否因内存耗尽（OOM）、SLAB 泄漏或 page fault 异常引发崩溃 -
dis <function></function>：对关键函数反汇编（如dis do_page_fault），配合bt中的地址，可精确定位出错指令
验证与排查常见卡点
如果 crash 启动失败或输出乱码，优先检查：
- 运行
file /path/to/vmlinux，确认输出含with debug_info；若显示stripped，说明调试符号缺失 - 用
ls -l /var/crash看 vmcore 是否非空（大小应接近物理内存容量）；0 字节说明 kdump 未成功捕获 - 执行
kdumpctl showmem或检查/proc/cmdline，确认crashkernel=...参数已生效且预留内存足够（建议 ≥512M） - CentOS/RHEL 系统上，确保已安装
kernel-debuginfo和kernel-debuginfo-common两个 RPM 包，缺一不可
