Linux内核挂死全解析：从现象到kdump实战排查

干内核这一行的人，最怕的其实不是进程崩溃，也不是磁盘写满，而是那种半夜被电话叫醒，电话那头只说一句“机器连不上了，ping 不通，屏幕卡死，按什么都没反应”。这种时候，十有八九是 Linux 内核挂死。

“linux 内核挂死”这个词听着挺硬核，但它离普通用户并不远。你用的云主机、公司机房的物理服务器、路由器、甚至智能设备，底层跑的都是 Linux 内核。一旦内核挂死，不是某个 docker 容器挂了，而是整台机器变成一块“砖头”，网络断开、CPU 空转、磁盘不响应，唯一的办法往往是强制断电重启。这个现象背后的原因、排查手段、以及怎么提前把“现场”留下来，就是这篇文章想聊透的东西。

文章适合谁看？一个是做运维和 SRE 的，另一个是写内核模块或者驱动开发的工程师，还有那些被领导临时拉去处理“内核 panic 工单”的人。我会从现象分类、常见诱因、现场取证、实战复盘、工具清单这几个角度展开，尽量用说人话的方式把技术细节讲清楚，也把我自己踩过的坑一并交代了。

1. 内核挂死到底是什么

1.1 先给“挂死”画个像

内核挂死，本质上是内核失去了“继续推进”的能力。你可以把内核想象成一栋大楼的总控室，里面有很多值班员，各自负责调度 CPU、内存、硬盘、网络。如果其中一个值班员突然拿着钥匙卡死在一扇门前，后面排队的人全部被堵住，整栋大楼的所有业务就会停摆。更麻烦的是，这个卡死往往发生在很底层的地方，连报警电话都打不出来。

它跟用户态进程崩溃有本质区别。普通程序崩了，内核会清理它的资源，其他进程照跑；但内核自己挂死，没有“更高优先级”的角色来收拾残局。硬件还在通电，指示灯还亮着，但操作系统已经没有“灵魂”了。

从表现上看，内核挂死有两种极端形态。第一种是“有声响”的挂死，比如控制台不停打印类似Kernel panic - not syncing的堆栈信息，然后系统自动重启或者永远卡在 panic 状态。第二种是“死寂式”挂死，屏幕上什么都没有，网络全断，CPU 也不跑，连硬件中断都没反应，像极了断电，但风扇还在转。这两种形态对应的取证手段完全不同，后续会细说。

注意：有些被当成“内核挂死”的现象，其实只是负载过高、内存耗尽、或者 disk I/O 卡住导致的系统“假死”。区分真假很重要，假死往往还能通过 SSH 进去或者用 SysRq 键救回来，真挂死通常只能重启。

1.2 挂死的四种典型形态

我在实际工作中见过大量内核挂死问题，它们可以被归纳成四类，每一类的内核机制、日志特征、检测方式都不一样。先看一张速查表：

所谓 panic，就是内核发现自身状态已经无法恢复，主动触发“一键终止”。它能打印出调用栈，通常还伴随Call Trace信息，信息量最大，也最好查。

soft lockup 和 hard lockup 这两个词容易混淆。soft lockup 表示某个 CPU 在内核态里长时间处于禁止抢占的状态，比如死循环或者长时间自旋，其他用户态任务排不上队，但是硬中断可能还能进来。hard lockup 更严重，表示 CPU 在关中断状态下跑飞了，连 NMI（不可屏蔽中断）都响应不了。检测 hard lockup 依赖 NMI watchdog，没有硬件支持或者被虚拟化屏蔽时，是检测不到的。

hung task 则是一个任务在 D 状态（不可中断睡眠）下卡死超过默认的 120 秒。注意，D 状态本身不一定是故障，特别是存储系统抖动时，进程经常短暂进入 D 状态；但如果长时间不退出，就一定有问题，内核会主动打印出该任务的调用栈。

理解这几种形态能帮你快速缩小排查范围。比如看到soft lockup，优先怀疑锁竞争、死循环和 CPU 调度；看到 hung task，优先怀疑文件系统、块设备层和驱动层面的卡死；看到 panic，则要重点分析调用栈里的最后几个函数。

2. 哪些原因会触发内核挂死

2.1 锁与并发：最隐蔽的元凶

我在实际处理内核挂死的经验里，锁相关的并发问题至少占了一半。Linux 内核里有大量的自旋锁、读写锁、互斥锁、信号量和 RCU 机制，多核 CPU 同时访问共享资源时，必须通过锁来保护。锁用得不好，就会死锁。

一个经典场景是“锁顺序反转”。假设 CPU0 持有锁 A，想继续拿锁 B；CPU1 持有锁 B，想继续拿锁 A。两个 CPU 各自都不放手，互相等待，系统里的其他任务被越堵越多，最终表现为 soft lockup 或者 hung task。这种问题在代码评审阶段很难看出来，因为需要两个 CPU 同时踩到特定路径，概率可能只有百万分之一。但一旦某些外部条件变化，比如网络流量增大、磁盘吞吐升高、中断频率变化，复现概率就会急剧上升。

自旋锁还有一个更隐蔽的坑：在中断上下文里尝试获取一个已经被占用的自旋锁。自旋锁的特性是“等不到就原地打转”，如果持有锁的进程被其他 CPU 打断，而新来的中断处理函数也去争抢同一把锁，就会形成“ABBA 死锁”。这种情况连调用栈都很混乱，经常看到两个 CPU 都停在_raw_spin_lock上。

RCU 的问题也值得提。Linux 内核的 RCU 机制设计得再精巧，在某些深度嵌套的场景下也可能出现“读者永远退出不了临界区”的情况，导致宽限期无限延长，后续的回收操作全部卡死。这类问题在普通日志里很难看出端倪，只能靠 lockdep 和 RCU stall 检测日志提供线索。

2.2 驱动和硬件：现场最惨烈

驱动代码质量参差不齐，是最容易导致内核挂死的另一个大头。尤其是网卡、存储控制器、GPU 这类高性能设备驱动，它们要跟硬件中断、DMA、内存屏障打交道，任何一步写错，都可能直接让系统崩掉。

我遇到过一类很典型的问题：驱动在设备热插拔时没有正确处理中断亲和性。设备移除后，它申请的中断号被重新分配给了其他设备，老的中断处理函数还在旧中断号上注册，结果新的中断事件触发了一个“野指针”处理函数，CPU 直接跑飞，最终 hard lockup。这种问题往往只在切换硬件、热插拔操作后出现，极难复现。

还有一个高频元凶是中断风暴（interrupt storm）。某些硬件异常会导致设备不断产生中断，CPU 被中断处理程序占满，几乎没有时间运行其他任务。这不是严格意义上的“挂死”，但用户感知就是系统完全卡住。中断风暴在日志里通常表现为/proc/interrupts里某个中断号计数飞速上涨，或者 soft lockup 的调用栈反复落在中断处理函数里。

硬件本身也可能背锅。内存的不可纠正错误会触发 Machine Check Exception，轻则杀掉触发进程，重则直接 panic。PCIe 设备的 AER 错误、NVMe 设备固件 bug、ACPI 固件实现不正确，都可能导致内核在错误处理的路径上再次出错，形成二次故障。所以排查内核挂死时，不能只盯代码，还要监控硬件报错日志。

实操心得：处理驱动导致的内核挂死，最有效的动作不是现场 debug，而是先收集完整的内核版本、驱动版本、设备型号和固件版本。很多驱动 bug 都有已知修复补丁，只要版本对上，答案基本就出来了。

2.3 内存回收和文件系统：慢得像挂死

有些“内核挂死”并不是真的逻辑死锁，而是内核内存管理或文件系统在极端情况下慢得离谱，但没有彻底死透。这种问题更折磨人，因为看起来是挂死，但系统偶尔又有点反应。

内存紧张时，内核会进行直接内存回收（direct reclaim）。如果系统有大量 page cache 需要回写，或者内存碎片严重，直接回收路径可能在页表遍历和 LRU 链表操作上卡很长时间。特别是开启了 THP（透明大页）的虚拟机里，khugepaged线程在合并页表时可能长时间持有锁，让其他内存操作全部排队。

文件系统也是重灾区。ext4 的日志提交线程（jbd2）在日志刷盘时如果遇到存储设备不响应，可能让大量进程阻塞在 D 状态。当存储控制器出现故障或网络存储延迟异常，会出现一整批进程卡在journal相关栈上，最终触发 hung task。我在项目里查过很多次这种“存储挂了导致所有进程 D 状态”的情况，根因往往在存储链路，而不是内核代码。

内存回收还有一个隐蔽问题：cgroup 内存限制。当某个容器达到内存上限时，内核会在容器内部进行回收，如果该容器的 page cache 太多太碎，回收线程可能在 memcg 的 LRU 锁上长时间自旋，把容器所在节点的 CPU 拖死。这个现象在 Kubernetes 环境里尤其常见。

2.4 误配置和内核版本回归

除了代码和硬件，配置和内核版本问题也会造成挂死。最常见的是内核启动参数里设置了不合适的 poll 机制、ACPI 休眠相关配置、或者 NUMA 相关参数，导致在特定硬件上初始化失败。很多时候新装系统后首次重启就挂死，大概率不是运气差，而是内核和主板固件之间的兼容性问题。

内核版本回归同样不可小觑。某个原本稳定的系统升级内核后突然频繁 soft lockup，不要急着怀疑业务，先查这个版本的内核变更日志。我遇到过一例，某版本改动了块设备层的 IO 调度队列，导致特定 SSD 型号的响应路径出现长时间自旋，直到下一个补丁版本才修复。生产环境的“内核更新”必须作为重要变更管理，不能看到有更新就顺手升级。

3. 挂死现场信息采集：没有数据一切免谈

3.1 串口和 Netconsole：让内核开口说话

内核挂死往往伴随着网络、显示和输入设备全部失效，这时候唯一可靠的“逃生通道”是串口。串口是独立于操作系统之外的物理设备，内核只要能运行最低级的打印代码，就能把日志输出到串口，哪怕屏幕已经黑了、网卡已经死了。

要开启串口输出，你需要在内核启动参数里加上类似下面的配置：

console=ttyS0,115200n8 earlyprintk=serial,ttyS0,115200n8 ignore_loglevel

其中console指定内核日志输出到串口，earlyprintk让早期启动阶段的打印也走串口，ignore_loglevel则是不按日志级别过滤，把能打的都打出来。配置改完后，需要重新生成引导配置并重启生效。在常见的 systemd 发行版上，修改/etc/default/grub里的GRUB_CMDLINE_LINUX后执行update-grub或grub2-mkconfig -o /boot/grub2/grub.cfg。

串口也有局限：距离远、线缆多、不方便统一管理。另一个实用方案是 netconsole，也就是通过网络把内核日志送到远端日志服务器。即使系统本身网络服务已经卡死，内核的 netconsole 使用的是自己的协议栈，很多时候仍然能输出日志。内核参数配置方式类似这样：

netconsole=514@10.0.0.10/eth0,514@10.0.0.20/00:16:3e:00:00:01

这个格式是“源端口@源IP/网卡名,目标端口@目标IP/目标MAC”。目标 MAC 最好显式指定，否则可能依赖 ARP，而内核挂死时 ARP 不一定会正常工作。远端用nc -u -l 514或者 rsyslog 接收即可。

注意：设置串口和 netconsole 后，一定要在业务低峰期做一次强制 panic 测试，看看远端到底能不能收到完整日志。很多系统配了日志通道，但从未验证过，真出事时才发现格式不对或目标不可达，那就白白浪费了最重要的现场。

3.2 kdump 和 crash：留一份完整的尸体报告

串口日志能告诉我们“最后发生了什么”，但很多时候不够。想要知道内核挂死那一刻所有 CPU 的寄存器、栈、内存里的锁状态，必须依靠 kdump。

kdump 的机制是：这套机制预留一部分内存crashkernel=512M，当内核 panic 时，崩溃的内核不直接停机，而是启动一个预先装载的“救援内核”，把崩溃时刻的内存镜像（vmcore）转储到磁盘。这个 vmcore 就是内核的“尸体报告”，内容极其完整。

配置 kdump 的步骤大致如下：

1. 安装kexec-tools，并安装对应内核版本的 debuginfo 包，至少要包含带符号表的vmlinux。
2. 在内核启动参数中预留内存：

   crashkernel=512M

3. 编辑/etc/kdump.conf，指定 vmcore 保存路径，并确保磁盘空间足够（至少预留内存镜像大小 + 压缩后的空间）。
4. 启动 kdump 服务，并触发一次测试：

   echo c > /proc/sysrq-trigger

   如果配置正确，系统会进入 panic，几秒后救援内核起来，把 vmcore 写到目标路径，然后按配置重启。

拿到 vmcore 后，用 crash 工具分析。crash 是内核调试的瑞士军刀，常用命令包括：

crash vmcore /usr/lib/debug/lib/modules/$(uname -r)/vmlinux

进入 crash 交互环境后，先bt查看当前崩溃线程的栈，再用foreach bt遍历所有 CPU 的调用栈，用ps查看当时进程状态，用files查看打开的文件。如果怀疑锁问题，还可以用lock查看锁依赖，用dis反汇编关键函数。这些信息组合起来，基本能还原挂死瞬间的完整画面。

3.3 ramoops/pstore：日志的最后一块遮羞布

有些环境既没有串口也没有网络，比如边缘设备、嵌入式开发板，或者虚拟机里被禁用了一些输出通道。这时候还能指望 pstore 子系统。

pstore 的原理是把内核崩溃前后的日志写到一块不会因重启而丢失的存储区域里，常见实现是 ramoops，用内存里的一段保留区域来保存日志。只要内核配置了CONFIG_PSTORE和CONFIG_PSTORE_RAM，并通过设备树或内核参数指定保留内存地址和大小，系统重启后挂载/sys/fs/pstore，就能看到上次崩溃的dmesg-ramoops-0文件。

ramoops 的好处是可读性强，不需要复杂的 kdump 配置，缺点是只能保存控制台打印的日志，不能像 vmcore 那样保存完整的 CPU 现场。但对于很多驱动 bug 和 panic 问题，日志信息已经足够定位了。嵌入式场景下，我通常同时开启 pstore 和串口，双保险。

3.4 SysRq 魔法键：人肉急救时的手动解剖

如果系统还没完全死透，只是 SSH 进不去，网络断了，但内核调度器还在运行，SysRq 键是最后的现场取证手段。通过sysctl kernel.sysrq=1开启后，你可以直接往/proc/sysrq-trigger写字符来触发内核动作。

常用的取证动作是：

echo t > /proc/sysrq-trigger # 打印所有 CPU 的栈回溯 echo w > /proc/sysrq-trigger # 打印 D 状态的任务堆栈 echo m > /proc/sysrq-trigger # 打印内存状态 echo l > /proc/sysrq-trigger # 打印所有在线 CPU 的栈回溯（高级）

这些输出会打到内核日志里，如果之前配置了 netconsole 或串口，就能把堆栈远程抓下来。注意，这一步不是让你救回系统，而是趁它还活着赶紧把现场记录下来。如果完全不想要现场，那当然可以直接echo b > /proc/sysrq-trigger强制重启。

常见误区：有人看到内核卡了就立刻按电源键重启，这等于销毁所有证据。除非已经明确知道是硬件故障且业务需要快速恢复，否则先花两分钟尝试抓栈，永远不亏。

4. 一次内核挂死的实战排查复盘

4.1 现象：客户端大面积失控

前面讲了一堆理论，下面分享一个模拟项目里比较典型的复盘。某公司有一套跑在虚拟化平台上的工作节点集群，某天凌晨监控开始疯狂告警，所有节点几乎同时失联。物理控制台显示屏幕停留在登录界面，鼠标键盘全部无效，网络设备也收不到任何包。第一反应是硬件掉电，但电源灯正常，内存指示灯正常，于是怀疑操作系统层面出了问题。

当时没有任何串口日志，因为新机房还没来得及布串口线，kdump 倒是提前配了，但只覆盖了 panic 场景。运维同事强制重启后系统恢复，随后我去翻/var/log/messages，发现内核日志里大量出现了这样的记录：

watchdog: BUG: soft lockup - CPU#3 stuck for 23s!

同时还有多个进程的 hung task 记录，像是某个宿主机上的存储 IO 全面停滞。这基本可以确定是内核挂了，不是硬件掉电。

4.2 时间线：先有存储告警，然后软锁定

接下来要做的是把日志按时间线对齐。我先把 netconsole 配置到远端，再结合/var/log/messages、内核日志和监控系统的 CPU/磁盘指标画时间线。发现挂死发生前 5 分钟，存储侧已经开始频繁报 SCSI 错误和 NVMe 超时，紧接着某个文件系统的日志线程出现异常，然后才出现 CPU soft lockup。这个顺序很重要，说明大概率不是 CPU 本身先出问题，而是存储链路异常诱发了内核里的某种锁问题。

另外，日志里出现了一个细节：不是所有 CPU 都卡死，只有 CPU3 和 CPU7 两个核的日志特别密集，其他核还在尝试处理网络中断。多核挂死经常表现为“部分 CPU 在死锁，部分 CPU 被排挤”，所以看到软锁定时，一定不要只盯着发生软锁定的那个 CPU，要把所有 CPU 的调用栈都捞出来。

4.3 vmcore 剖析：两个 CPU 在 spinlock 上死锁

因为 kdump 覆盖了 panic，但那次故障最终表现为 soft lockup，没有触发 panic，所以并没有自动产生 vmcore。后来我们复现故障时手动触发了 sysrq c，成功抓到 vmcore。

用 crash 打开 vmcore 后，我执行了：

foreach bt

输出显示 CPU3 停在一个文件系统日志提交线程的路径上，栈里最后一层是spin_lock；CPU7 则停在块设备层 IO 完成的路径上，同样卡在_raw_spin_lock。再结合log命令里两个 CPU 的持锁栈，可以确定这是一对典型的 ABBA 死锁：文件系统日志提交路径持有一个日志锁，等块设备层的完成锁；块设备层完成路径持有了完成锁，又想获取日志锁。两个 CPU 互相等待，谁也跑不掉。

这里要强调一个经验：死锁问题只看单线程栈永远看不出问题。必须把相关 CPU 的栈放一起对比，找到两个栈里互相引用的同一把锁。如果没有 vmcore，你拿到手的只能是“CPU3 卡在 spin_lock”这种表面现象，永远不知道背后还有一个 CPU7 也卡在另一把锁上。

4.4 修复与验证：一个补丁解决问题

根因找到后，问题就解决了一半。我翻看该内核版本在文件系统和块设备层相关子系统的补丁记录，果然发现一个修复“日志提交路径中锁顺序错误”的补丁。这个补丁重新调整了锁的获取顺序，避免在持有一个锁的同时去获取另一个锁，从而打破 ABBA 循环。把内核升级到包含该补丁的版本后，我们在同样环境里做了大量 IO 压力测试，连续跑了一个星期，没有再出现 soft lockup。

这段复盘的教训是：如果没有串口、没有 vmcore、没有远端日志，几乎不可能定位到这种锁顺序问题。很多人把时间花在“重启后看 dmesg”上，但 dmesg 在挂死那一刻之后的内容早就丢了，重启后看到的只是幸存者偏差。

5. 避坑经验与排查工具速查

5.1 排查工具速查表

根据我的实际操作经验，面对内核挂死时，下面这些工具最常派上用场：

排查时我习惯先看/var/log/messages里有没有watchdog、hung task、kernel panic、BUG:关键字，并列出来。如果没有现成日志，再决定要不要主动复现并打开 trace。

5.2 内核配置和生产调优建议

在能控制内核编译参数的环境里，建议和测试环境区分开。生产环境不要盲目追求把所有 debug 选项全开，但几个跟挂死检测相关的选项必须确认打开：

• CONFIG_SOFTLOCKUP_DETECTOR=y：等于开启 soft lockup 检测。
• CONFIG_HARDLOCKUP_DETECTOR=y：开启 hard lockup 检测，依赖硬件 NMI 能力。
• CONFIG_HUNG_TASK=y和CONFIG_DETECT_HUNG_TASK=y：开启 hung task 检测。
• CONFIG_KALLSYMS=y：在日志中打印可读的符号名，否则调用栈全是十六进制地址。
• CONFIG_DEBUG_INFO=y：生成调试信息，配合 crash 使用。

CONFIG_LOCKDEP和CONFIG_PROVE_LOCKING是锁死锁的利器，在测试环境一定要开，生产环境要谨慎。lockdep 会维护锁依赖图，性能开销明显，但如果你正在排查一类随机出现的死锁问题，短期内开启并伴随压测，往往能直接抓到锁路径。我见过一个团队为了追一个偶发死锁，生产环境开了 lockdep，结果线上吞吐掉了几个百分点，但最终成功定位问题，值回票价。

此外，kernel.hung_task_timeout_secs默认是 120，如果你觉得 120 秒太久，可以适当调小，比如 60 秒，让内核更早打印出 D 状态任务。但不要调得太小，否则正常的 IO 抖动也会触发误报。

5.3 我踩过的那些坑

排查内核挂死，最大的坑是“没留现场”。我早期接手过一个集群，某台节点平均两周挂一次，每次重启后都正常，无奈之下只能加了一个定时脚本，每分钟把/proc/sysrq-trigger的w输出落盘。结果下一次挂死时，脚本也跑了，但磁盘里的日志只写到一半——因为系统在写入日志文件时刚好挂死，文件没有 flush 到磁盘。后来我把脚本输出改成写到 pstore 区域，才总算拿到了完整的 D 状态栈。

第二个坑是“迷信 dmesg”。dmesg 只能显示当前运行内核的环形缓冲区，挂死那一刻之后的内容会因缓冲区的覆盖机制而丢失。所以每次出问题后看到 dmesg 里干净如新，不代表没有日志，而是日志已经被后续打印冲掉了。正确做法是提前配置串口或 netconsole，把日志实时同步到远端。

第三个坑是“忽略 NMI watchdog 的硬件依赖”。在虚拟机里，默认的 hard lockup 检测经常不生效，因为虚拟 CPU 无法提供可靠的 NMI。这时候你认为自己在监控 hard lockup，实际上什么都没监控，安全问题就被漏过去。建议在虚拟化环境里至少打开 soft lockup 和 hung task 检测，同时通过宿主机层面的监控辅助判断。

最后再分享一个通用经验：内核挂死排查是一个系统工程，不能靠一个问题一个手段。串口、netconsole、kdump、pstore 四件套，能配的都配上，并且定期做故障演练。真正遇到问题的时候，你才不会手忙脚乱。很多时候，根因不是“代码写错”那么单纯，而是四个条件刚好同时命中：特定硬件、特定内核版本、特定负载、特定操作顺序。我们在生产里能做的，就是尽量让“现场”完整留下来，剩下的交给技术和一点耐心。