kernel panic 是内核无法安全运行的致命错误，需通过 dmesg -t | grep -a 20 -b 5 -e "(kernel panic|oops|bug:|call trace:)" 快速定位日志，结合 vmcore 分析、模块名排查、硬件诊断及 panic 前 warning 综合判断根因。
Kernel Panic 不是普通错误，它意味着内核已无法继续安全运行，必须立即停机。你没法靠 systemctl restart 或重载服务来修复——得先看懂日志里哪一行在“喊救命”，再决定是换驱动、查内存，还是回退内核。
怎么快速抓到 panic 日志的原始片段？
默认 dmesg 输出太长，混着启动日志和无关警告。真正有用的只有带关键字的几行，且必须包含 panic 前后上下文：
- 用
dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"——-T加时间戳，-A 20向下取 20 行（含调用栈），-B 5往上取 5 行（找前兆） - 如果系统已重启，
/var/log/kern.log可能被轮转，优先查/var/log/kern.log.1.gz；用zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic" - 别信
journalctl -b -1 | grep panic—— journal 日志可能没捕获 panic 瞬间，尤其当 kdump 没启用或 rsyslog 未配置imkmsg
Call Trace 里哪些函数名值得立刻盯住？
调用栈不是从上往下读，而是从最底端（panic 或 __warn）往上推，找到第一个非内核通用函数的位置：
- 看到
[nvidia]、[zfs]、[wireguard]这类方括号包着的模块名？90% 是它干的——第三方驱动没经过主线充分验证，尤其升级内核后没重编译 ko 文件 - 连续出现
ext4_writepages、ext4_da_write_begin？文件系统层异常，检查磁盘 SMART（smartctl -a /dev/sda）和是否在挂载时用了data=journal - 全是
mm_*开头（如mm_page_alloc、try_to_unmap）？内存子系统出问题，结合dmesg -T | grep -i "ecc\|correctable\|uncorrectable"查硬件级内存故障 - 出现
unknown symbol或invalid opcode？内核模块版本不匹配，或 CPU 微码过旧（cpupower frequency-info+ 查主板 BIOS 更新日志）
为什么 dmesg 看不到完整 panic，但 /var/crash/ 下有 vmcore 却打不开？
vmcore 不是“有文件就代表有效”。常见失效原因比你想象中更琐碎：
- 用
file /var/crash/*/vmcore确认类型：输出必须是ELF 64-bit LSB core file x86-64，若显示data或empty，说明 crashkernel 内存预留不足或写入被截断 -
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore进去后输bt，若卡住或报cannot determine vmcore type，大概率是vmlinux符号文件版本不匹配——确认当前运行内核是$(uname -r)，且 debuginfo 包已安装（如 CentOS 的kernel-debuginfo-$(uname -r)） - kdump 服务本身可能根本没起来：
systemctl status kdump查状态，失败常见于/proc/sys/kernel/panic为 0（需设为非零值，如 10），或crashkernel=参数在 grub 配置里太小（建议至少crashkernel=512M）
最常被跳过的动作是查 panic 前几秒的 WARNING 和 Hardware Error——它们不会直接导致 panic，但像倒下的多米诺骨牌第一块。别只盯着 “Kernel panic” 四个字，往上看 10 行，往往藏着 EDAC MC0: UE 或 ACPI BIOS Error 这种真凶。
