第 10 章 永不消逝的回响：当内核决定放弃
10.1 技术准备与场地检查
有一类问题，调试它们的过程就像是在没有黑匣子的飞机失坠现场寻找真相。
作为一名经常和内核打交道的工程师，你早晚会遇到那个时刻：屏幕停止滚动，键盘灯毫无规律地闪烁，最后一行日志冷酷地显示着 "Kernel panic - not syncing"。这一刻，往日里那个帮你打掩护、自动恢复错误的操作系统突然「摊牌」了——它拒绝继续执行，因为它发现再走下去只会带来更大的破坏。
这时候，最可怕的不是系统挂了，而是你两手空空。没有抓到崩溃时的内存镜像，不知道是哪个驱动最后触碰了红线，甚至不知道这到底是一次硬件故障还是软件逻辑的恶性死循环。
本章的核心任务，就是建立一套「死后验尸」的能力。我们将探讨内核在遇到无法挽回的错误时（Panic）会经历什么，那些形形色色的「死锁」检测器是如何工作的，以及如何通过 kexec 和 kdump 抓取现场。但在开始这场硬仗之前，我们得先确认手里的工具是否齐全，弹药是否充足。
技术准备
如果你读过第 1 章，那你应该已经装备好了。本章的战场环境和那章完全一致，我们就不重复造轮子了。
为了确保你能跟着我一起复现这些底层机制，你需要满足以下条件：
-
开发与构建环境
- 一个现代的 Linux 发行版（Ubuntu 20.04+ 或 Fedora 是推荐选择，毕竟新工具链对新内核特性的支持更好）。
- 完整的内核编译工具链（
gcc,make,bc等）。 - 足够的磁盘空间——如果你打算开启 kdump，你至少需要和物理内存大小相等的磁盘空间来保存崩溃转储。
-
实验环境
- 强烈建议使用 QEMU/LKVM 虚拟机。为什么？因为在本章的某些实验中，我们需要主动触发内核 Panic 或让 CPU 假死。在虚拟机里，这只是一个窗口关闭的问题；在物理机上，你可能面临强制重启的风险，更重要的是，物理机上的调试往往受限于硬件（比如串口波特率不够快，调试信息会丢）。
- 如果一定要在物理机上玩，请确保你有 JTAG 调试器或者至少有一个可靠的串口连接。
-
代码获取
所有的示例代码、补丁以及测试用的内核模块，都已经打包好了。你可以通过以下命令把它们拉到本地：
git clone https://github.com/PacktPublishing/Linux-Kernel-Debugging
cd Linux-Kernel-Debugging
这不仅仅是一堆代码，它是我们在这一章里用来「炸」内核的各种雷管。
💡 译者注/作者提醒： 这里「技术准备」实际上对应原书的第一节。作为全书实战风格的延续，这一节虽然短，但它是一个「安全检查点」。在内核调试这个领域，环境不对，一切复现都会变成玄学。
请务必确认你的内核源码树已经准备好了，我们在后面修改
panic.c和配置kexec时，需要直接动手编译和替换内核镜像。别偷懒，别直接用发行版自带的内核——那是给「用户」用的，不是给「内核黑客」用的。
如果你都准备好了，那我们就正式进入内核最黑暗的时刻——从 Panic 开始。