内核panic是真正的系统崩溃，表现为控制台卡死、自动重启或红色错误信息；若仅ssh失败而控制台可操作，则多为服务或资源问题。关键判断依据包括ipmi/idrac画面、启动日志中的reboot记录、dmesg或/var/log/kern.log中kernel panic/bug:等关键字，同时需排查kdump是否启用及vmcore是否存在，避免将资源耗尽误判为内核故障。
崩溃后怎么确认是不是内核 Panic
真正意义上的系统崩溃，往往表现为控制台突然卡死、自动重启、或屏幕上刷出大量红色错误信息（比如 Kernel panic - not syncing 或 Oops）。如果只是 SSH 登录失败但控制台还能操作，大概率不是内核崩溃，而是服务或资源问题。
关键判断点：
• 能否通过 IPMI / iDRAC / 云厂商 VNC 看到实时控制台画面？
• 是否有自动重启且启动日志里出现 reboot: System halted 或 Starting new kernel？
• dmesg -T | tail -30 输出末尾是否含 Kernel panic 或 BUG:？
查 /var/log/kern.log 和 dmesg 日志
大多数崩溃会在内核日志里留下线索，优先看这两个来源：
• /var/log/kern.log（Debian/Ubuntu）或 /var/log/messages（RHEL/CentOS）记录了带时间戳的内核事件
• dmesg -T 显示最近的内核环形缓冲区内容，重启后部分信息会丢失，所以必须在崩溃后尽快执行
常见有效命令：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
dmesg -T | grep -i "panic\|oops\|error\|fail"-
tail -100 /var/log/kern.log | grep -i "killed process"（OOM 杀进程痕迹） -
journalctl -b -1 -k | head -50（上一次启动的内核日志）
rsyslog 或日志轮转过早，/var/log 下可能没有完整记录。检查 kdump 是否生效并分析 vmcore
只有启用 kdump 并成功捕获到 vmcore，才能做深度根因分析。先确认是否配置并触发：
• systemctl is-active kdump 返回 active 才算运行中
• find /var/crash -name "vmcore*" 看是否有生成文件（路径可能为 /var/crash/$(uname -r)-$(date +%Y%m%d%H%M)）
• 若有 vmcore，用 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore 进入交互分析
容易被忽略的点：
• kdump 预留内存（crashkernel=）必须在 GRUB 启动参数里设置，且大小要足够（通常 ≥ 128M）
• vmlinux 调试符号包需提前安装（如 kernel-debuginfo），否则 crash 工具无法解析堆栈
区分“假崩溃”和真内核故障
80% 的所谓“服务器崩溃”，实际是资源耗尽导致的响应停滞，而非内核错误：
• uptime 显示 load average 远超 CPU 核心数 → CPU 过载，不一定是崩溃
• free -h 中 available 接近 0 且 Swap 使用率 >90% → OOM 前兆，dmesg 里会有 Killed process
• iostat -x 1 3 显示 %util 持续 100%，await >100ms → I/O 卡死，进程阻塞在 D 状态（不可中断睡眠）
这时候系统还在运行，只是无法响应新请求——别急着重装系统，先杀掉异常进程或清理磁盘。
