首先记录内核恐慌时的错误信息，特别是Call Trace；接着配置Kdump生成vmcore文件；然后使用Crash工具分析vmcore，定位崩溃路径；同时检查硬件与驱动兼容性，排除内存或第三方模块问题；最后可通过ramoops保留日志。
如果您在使用LINUX系统时遇到内核恐慌（Kernel Panic），系统会停止所有操作并显示错误信息，这通常意味着内核遇到了无法恢复的致命错误。以下是针对此问题的排查步骤：
本文运行环境：Dell PowerEdge R750，CentOS Stream 9
一、收集崩溃日志与现场信息
获取完整的错误输出是定位问题根源的第一步。内核恐慌发生时，控制台会打印出关键的调试信息，包括“Oops”或“Aieee”提示、调用栈（Call Trace）以及寄存器状态。
1、立即记录下屏幕显示的所有错误信息，特别是包含函数名和内存地址的“Call Trace”部分。
2、如果系统配置了串口控制台，请通过串口线连接另一台主机，捕获更完整的日志输出。
3、关键提示：确保错误信息完整截取，尤其是最后几行的堆栈回溯，这是分析模块或驱动故障的核心线索。
二、启用并利用Kdump生成vmcore文件
Kdump是一种可靠的内核崩溃转储机制，它能在主内核崩溃后，由一个预先加载的捕获内核（capture kernel）将内存内容保存为vmcore文件，供后续深度分析。
1、检查系统是否已安装kexec-tools：yum install kexec-tools。
2、编辑/etc/default/grub文件，在GRUB_CMDLINE_LINUX行添加crashkernel=256M参数以预留内存。
3、更新GRUB配置并重启：grub2-mkconfig -o /boot/grub2/grub.cfg，然后重启系统。
4、启动kdump服务：systemctl enable kdump && systemctl start kdump。
5、触发一次测试性崩溃，验证vmcore是否成功生成：echo c > /proc/sysrq-trigger。
6、系统重启后，检查/var/crash/目录下是否存在新的vmcore文件。
三、使用Crash工具分析vmcore
Crash-Utility是一个功能强大的开源工具，专门用于解析vmcore文件，其界面类似GDB，可以深入查看内核数据结构和执行流程。
1、安装crash工具及对应内核的debuginfo包：yum install crash kernel-debuginfo。
2、加载vmlinux符号文件和vmcore数据：crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/。
3、在crash命令行中执行bt
命令，查看完整的进程调用栈，确定导致panic的代码路径。
4、使用set 切换到相关进程上下文，并通过gdb info locals查看局部变量值。
5、重要操作：结合Call Trace中的函数名和偏移量，对照内核源码进行逐行分析，以确认具体的错误指令。
四、检查硬件与驱动兼容性
硬件故障或不稳定的第三方驱动是引发内核恐慌的常见原因，尤其是在中断处理程序中访问非法内存地址时。
1、使用dmesg | grep -i error和journalctl -k -b -1检查上一次启动的日志，查找硬件相关的I/O错误或ECC内存报错。
2、运行内存测试工具，如memtest86+，排除物理内存条损坏的可能性。
3、检查当前加载的内核模块列表：lsmod，重点关注非Red Hat/CentOS官方提供的第三方驱动，例如特定型号的网卡或RAID卡驱动。
4、尝试在系统启动时通过GRUB菜单进入单用户模式，然后手动卸载可疑的第三方模块进行隔离测试。
五、配置ramoops持久化存储日志
对于无法配置Kdump或没有外接存储设备的嵌入式系统，ramoops提供了一种将oops日志写入保留内存区域的方案，确保重启后日志不丢失。
1、修改内核编译选项，启用CONFIG_PSTORE_RAM、CONFIG_PSTORE_CONSOLE等pstore相关配置。
2、在设备树（Device Tree）中定义一块保留内存区域，并设置compatible属性为"ramoops"。
3、指定record-size、console-size等参数，分配用于存储panic日志、控制台输出的空间大小。
4、系统重启后，检查/sys/fs/pstore/目录下是否生成了dmesg-ramoops-*等日志文件。
5、直接读取这些文件的内容，即可获得上次崩溃的详细内核日志。
