服务器DC重启测试中， BMC偶现复位

baixin_lixiaohang · 2026 年5 月 27 日 06:47

// 此模板仅供参考，如果不适用可以修改

问题描述

服务器DC重启测试中，偶现BMC异常复位，测试过程中使用pmitool搜集传感器信息，SEL日志，上下电等。查看日志发现

2026-05-24 08:55:26,Normal,0x1A00006F,Asserted,The openUBMC is reset, with the cause code of 0x2.

S920S21_2102315PFS10RC100010_20260525-0910.7z.txt (9.9 MB)

环境信息

操作系统：Euler 22.03
软件版本：OpenUBMC2509
硬件配置：S920S21

重现步骤

期望结果

BMC无异常行为

实际结果

BMC发生了异常复位

尝试过的解决方案

查看日志无coredump文件产生，日志中无maca主动复位BMC的打印，操作日志中没有复位BMC相关记录

分析结论

暂时没有方向进行排查

ubmc_assistant · 2026 年5 月 27 日 06:49

答案内容由AI生成，仅供参考：

总结

在您DC测试场景下，BMC以原因码 0x2 复位的最可能原因是 BMC 的健康检查自愈机制被触发。这通常意味着在复位前，系统内某个关键服务或组件（如 skynet）因持续不稳定而被框架判断为需要复位整个 BMC 才能恢复。

建议优先检查 coredump 文件和相关日志，定位是哪个组件或服务发生了崩溃，这将是解决该问题的关键线索。如果找到 coredump，可以按照文档4中的思路，分析是否是某个特定进程（例如 skynet）导致看门狗超时。

点击此处查看详细分析解答

好的，我们来分析您在DC重启测试中遇到的BMC偶发复位问题。

根据您提供的日志信息 The openUBMC is reset, with the cause code of 0x2，结合知识库中的相关内容，为您提供以下分析和排查方向。

1. 关于事件码 0x1A00006F 和原因码 0x2

事件码 0x1A00006F：在 openUBMC 系统中，该事件码专门用于记录 openUBMC 的复位事件。它会附带一个“原因码 (cause code)”来指示复位的触发原因。
原因码 0x2：根据知识库中的文档记录和社区讨论，原因码 0x2 通常与 BMC 重启 相关联。具体描述为 “升级重启code是0x2” （见知识库文档1）。在另一处描述中也提及，“直接网页重启code显示…也是2”（见文档1）。此外，BMC Restart 这一系统事件会导致 openUBMC 以原因码 0x2 进行复位（见关系图谱）。

2. 原因分析

您已排除在测试过程中进行了BMC固件升级。那么，除手动升级或重启外，还有其他事件同样会触发 BMC 重启，进而被记录为原因码 0x2。根据知识库，有以下几种可能：

BMC 自愈机制：这是最需要关注的方向。知识库的“【MACA】问题定位方法&FAQ”文档（搜索结果1）中提到，BMC 有一个健康检查机制。当组件健康状态检查失败，并在短时间内（例如10分钟内）反复拉起进程失败达一定次数（默认配置为3次）后，框架会自动触发 BMC 复位 以尝试恢复系统。这个机制导致的复位，在系统事件中就可能被记录为原因码 0x2。
进程崩溃导致看门狗超时：文档4中描述了一个 AC测试 中出现 BMC 复位的案例。排查发现，这是因为 skynet 进程不断崩溃并产生 coredump，最终导致看门狗超时，触发了硬件级别的 BMC 复位。虽然您的场景是DC测试，但类似的进程崩溃问题也可能在DC测试的压力下暴露。
标准重启操作：在系统事件中，通过 Web 界面或命令行执行正常的 Restart BMC 操作，也会记录为原因码 0x2（文档1用户回复）。但您已确认测试中未执行此操作。

3. 排查步骤建议

结合以上分析，建议您按以下顺序进行排查：

检查 coredump 文件：这是排查进程崩溃最直接的方法。请检查 BMC 文件系统 /data/var/coredump 目录下，在 BMC 复位时间点附近（2026-05-24 08:55:26 之前）是否有新生成的 coredump 文件。进程崩溃是触发 BMC 自愈复位或看门狗复位的常见原因。
分析 app.log 日志(framework.log)：
- 查找 BMC 复位时间点附近的错误或告警日志。
- 重点搜索：skynet 进程崩溃的日志（如 do_coredump），或健康检查相关的日志（如 continuouslyoffline，HEALTH.NEED_RESTART_NOW）。
- 如文档1中的回复所述，可以检查 framework.log，确认是否有组件异常重启的详细记录（原因码0x10通常与此相关，但0x2也可能由组件的持续崩溃触发）。
检查 syslog 和操作日志：
- 系统日志：查看 BMC 复位前是否有其他异常事件，例如内存错误、文件系统错误或硬件访问超时等。
- 操作日志：如搜索结果5所示，检查 Redfish 接口返回502错误的时间点附近，是否有 BMC 复位记录。nignx 的499/502错误（如连接超时、系统时钟异常）可能是 BMC 即将崩溃或压测过程中资源紧张的前兆。
确认组件健康状态：登录 BMC 命令行，检查各核心服务（如 ipmi_core, bmc_core, redfish 等）的实时运行状态，看是否有服务处于“退避”或反复重启的状态。

总结