消失的服务处理器：一次硬核的硬件与软件协同调试之旅

背景

在 Oxide 公司的机架（Rack）架构设计中，一个核心考量是明确哪些部件需要物理访问，以及通过何种方式进行访问。Oxide 机架被设计为仅通过管理网络进行访问的数据中心基础设施。工程师物理访问机架的唯一理由应当是更换故障部件（如磁盘）。因此，其服务处理器（Service Processor, SP）完全通过管理网络进行远程访问和控制。

然而，在将新一代 Cosmo sled（服务器节点）集成到 Oxide 机架的过程中，团队遇到了一个极具挑战性的问题：服务处理器会突然从网络中“消失”。由于失去网络连接，调试变得异常困难，因为工程师无法直接获取 SP 内部的状态信息。这种“失联”现象在机架外部的 sled 上无法复现，进一步增加了排查难度。

核心内容

1. 故障现象与初步假设

当 SP 失联时，系统呈现出以下特征：

• 主机 CPU 存活：AMD 主机 CPU 仍在运行，表明系统整体供电正常。
• 网络无响应：SP 未在管理网络上广播存活信号，且无网络数据计数器增加。
• 风扇异常：风扇以恒定高转速运行。由于 SP 负责风扇控制，这表明风扇控制器可能已回退到紧急全速模式，暗示 SP 的控制功能已失效。

团队最初的理论是软件层面的“任务饥饿”（Task Starvation）。Oxide 的服务处理器运行着自研的操作系统 Hubris。Hubris 并非具有严格截止时间保证的实时操作系统（RTOS），但支持任务优先级。如果某个任务陷入无限崩溃循环并不断重启，可能会占用所有 CPU 时间，导致负责网络通信的任务无法运行。为此，团队增加了任务重启延迟，并将机箱 LED 从常亮改为闪烁，以便在断网时观察 SP 是否仍在进行内部状态切换。

2. 调试深入：从软件到硬件

尽管增加了调试手段，问题依然难以复现且现象矛盾（LED 有时常亮，有时常灭）。由于 Hubris 使用 Rust 编写，缓冲区溢出等常见 bug 已被消除，但栈溢出（Stack Overflow）仍是潜在风险。然而，内核栈空间较大（512 字节），栈溢出的可能性较低。

为了获取更深层的调试信息，团队不得不采取非常规手段：利用制造过程中用于调试的 SWD（串行线调试） 接口。通过同事协助，他们在生产环境中强行连接了调试探头。

调试探头虽然能复现问题，但无法通过标准的“调试暂停”（Debug Halt）功能冻结 CPU，这限制了诊断信息的提取。鉴于 SP 使用的是 Cortex-M7 STM32H7 处理器，导致系统完全停滞的原因非常有限。

3. 锁定嫌疑对象：FPGA 与 FMC 总线

团队将注意力转向了系统架构中的重大变更：第一代 Gimlet 系统引入了 FPGA 来控制主机闪存等更多部件。FPGA 通过传统的并行总线连接，并由 STM32H7 的 FMC（灵活存储器控制器） 访问。

根据 STM32H7 手册，FMC 负责将 AXI 事务转换为外部设备协议。如果 CPU 等待外部设备的总线响应（Bus Acknowledgement）而该响应永远不来，CPU 就会挂起。为了验证这一理论，团队创建了一个 FPGA 测试镜像，其中包含一个读取时会故意阻塞 FMC 总线的寄存器。该测试成功复现了类似的挂起行为，证实了问题很可能出在 FMC 总线与 FPGA 的交互上。

4. 突破性的调试技巧：Vector Catch

由于无法常规暂停 CPU，团队利用了 ARM CPU 支持的 Vector Catch 功能。配置 CPU 在复位时、执行第一条指令之前暂停。这允许团队在不完全破坏系统状态的情况下获取寄存器快照。

• 初步发现：复位后的 Hubris 状态显示，当时运行的任务并未直接访问 FMC。
• 硬件修正：硬件工程师审查 FPGA 时序，发现可能未满足内存接口的时序约束。团队合并了修复代码，并假设之前的 Vector Catch 快照不一致是由于缓存（Cache）干扰所致。关闭缓存后，快照变得一致，但问题仍未复现。

5. 最终突破：Root of Trust 测试

在随后的几周里，团队在开发 Measured Boot（受控启动） 功能时，意外地找到了高频复现问题的方法。SP 的 Root of Trust (RoT) 负责在启动时哈希化 SP 闪存。为了实现安全属性，SP 在首次启动时可能会连续重置多次。

这一测试将问题的复现时间从可能的 24 小时以上缩短至 10-20 分钟。尽管初始快照仍未显示直接证据，但团队坚持怀疑 FMC 总线。

6. 真相大白：CPU 的隐性访问

在经历了多次无效尝试（调整重置率、清除 FPGA 位流、限制任务访问 FMC 等）后，团队重新审视 STM32H7 手册，获得了关键洞察：

CPU 本身可能在执行程序员未预期的 FMC 总线访问。

现代处理器拥有大量程序员不可见的内部状态。除非在特定的同步点或执行缓存指令，否则程序员无法确切知道 CPU 何时会将数据拉入或推出缓存。当 CPU 将数据从缓存写回内存时，这被视为一次内存访问。因此，即使当前程序计数器指向的代码并未访问 FMC，CPU 后台的缓存维护操作也可能触发对 FMC 总线的访问。如果此时 FPGA 的时序存在瑕疵，导致总线响应超时，CPU 就会挂起，从而导致服务处理器从网络中“消失”。

关键要点

• 调试环境的局限性：在生产环境中，当关键组件（如 SP）失联时，传统的远程调试手段失效，必须依赖物理接口（如 SWD）进行底层硬件调试。
• Rust 与 Hubris 的优势与局限：使用 Rust 编写的 Hubris 操作系统消除了内存安全类 bug（如缓冲区溢出），但栈管理仍需手动调整，且栈溢出并非唯一风险。
• 硬件时序与软件行为的耦合：FPGA 的时序约束不满足可能导致 CPU 在等待总线响应时永久挂起。软件层面的“任务饥饿”理论虽然合理，但在本案例中并非根本原因。
• Vector Catch 调试技术：利用 ARM CPU 的 Vector Catch 功能在复位瞬间暂停执行，是获取挂起系统状态快照的有效手段，尽管受缓存影响可能导致快照不一致。
• CPU 缓存的隐蔽影响：现代 CPU 的缓存机制会在后台自动执行内存访问。程序员通常认为只有显式代码才会访问特定总线，但实际上缓存写回等操作也可能触发总线事务，这在调试涉及外部设备（如 FPGA）的系统时极易被忽视。
• 安全机制作为调试工具：原本用于安全目的的 Root of Trust 连续重置机制，意外成为了高频复现硬件时序 bug 的有效测试用例。

意义与影响

这一案例展示了现代数据中心基础设施调试的复杂性，特别是在软硬结合部。它强调了在高度集成的系统中，软件稳定性不仅取决于代码逻辑，还深刻依赖于硬件时序和 CPU 微架构行为。

对于 Oxide 而言，解决这一问题不仅恢复了 Cosmo sled 的可靠性，也验证了其自研操作系统 Hubris 在应对极端硬件异常时的韧性。更重要的是，它揭示了在嵌入式系统开发中，理解 CPU 缓存一致性、总线协议时序以及利用底层调试特性（如 Vector Catch）的重要性。这种深入底层的调试经验，对于构建高可用、可维护的下一代数据中心硬件具有极高的参考价值。