事件码“0x1A00006F”在S920X20的告警处理文档里没有查到。

QA SIG
1

一、测试环境
硬件：S920X20
BMC Version: 25.12
二、问题描述
反复BMC版本升级回退压力测试，查看“系统事件”，有“0x1A00006F”事件码，对应了两个事件的描述。

image
image1770×961 44.4 KB

问题：
（1）“0x1A00006F”事件码在《鲲鹏服务器主板 S920X20 BMC 告警处理 03.pdf》里没有找到。
（2）“0x1A00006F”事件码为什么对应了两个事件描述，一个描述里是"0x2"，一个是“0x10"。
（3）"0x2"和”0x10"是什么意思？

2

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

六、结论总结

问题 解答
(1) 事件码未在文档查到？ 属于 openUBMC 自定义事件，定义在 event_def.json 中，文档未更新所致。
(2) 同一事件码对应多描述？ 该事件为参数化事件，描述中 Cause Code 由运行时动态填充，导致内容差异。
(3) 0x2 和 0x10 是什么？ 0x2 表示正常软重启；0x10 可能表示看门狗或异常崩溃触发的重启。

该现象在压力测试场景下属于可预期行为，但高频出现 0x10 需进一步排查稳定性问题。建议结合日志深入分析异常重启根源，以提升系统可靠性。

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

关于S920X20系统中事件码 0x1A00006F 的分析

根据您提供的信息，针对在 S920X20 硬件平台上、运行 BMC Version 25.12 固件时出现的事件码 0x1A00006F 及其相关问题，以下是基于上下文知识库的综合分析和专业解答。

一、事件码 0x1A00006F 未在文档中查到的原因

结论：该事件码是 openUBMC 平台自定义的系统事件，其配置来源于 event_def.json 文件而非传统文档。

虽然事件码 0x1A00006F 未在《鲲鹏服务器主板 S920X20 BMC 告警处理 03.pdf》中查到，但这并不表示它无效或异常。原因如下：

  1. 事件定义来源不同：

    • 在 openUBMC 架构中，大量系统事件通过 动态配置文件 event_def.json 定义，而不是完全依赖 PDF 文档维护。
    • 正如搜索结果《事件定制》文档所述，openUBMC 的事件需进行静态配置，包括事件码、级别、描述模板等，这些配置通常存储于 /opt/bmc/conf/event_def.json 或 VPD 配置中。
    • 您所查阅的 PDF 文档可能未实时同步最新的事件码定义，尤其对于 自定义或调试用途的事件。

  2. 事件结构分析：

    • 事件码 0x1A00006F 符合 openUBMC 对系统事件的编码惯例。
    • 0x1A0000xx 前缀常见于 BMC/OpenUBMC 子系统内部状态变更事件，如系统重启、状态迁移、模块初始化等。

二、为何同一个事件码对应两个不同的事件描述？

结论：0x1A00006F 是一个参数化事件，其事件描述中的 “cause code”（原因码）由运行时动态传入，导致显示内容不同。

:magnifying_glass_tilted_left: 根本原因解析：

在 openUBMC 系统中，event_def.json 文件支持模板化事件描述，即：

  • 事件码固定（如 0x1A00006F）
  • 描述中包含动态参数占位符（如 {CauseCode}）

当事件触发时，系统会根据传入的实际参数填充模板，从而产生多个不同描述但相同事件码的记录。

例如：

  • "The openUBMC is reset, with the cause code of 0x2."
  • "The openUBMC is reset, with the cause code of 0x10."

这两条记录均由同一事件模板生成，只是运行时的 Cause Code 不同。

:gear: 支持证据：

  • 知识图谱中实体 event_def.json 的描述指出：该文件“提供静态配置数据用于预定义报警事件定义和自定义事件”，并支持“包含关键信息如事件 key ID、codes 和 associated behaviors 和 parameters”。
  • 《事件定制》文档明确说明：事件描述可使用模板语法，支持中英文及参数引用。

三、“Cause Code 0x2” 与 “0x10” 的含义分析

结论：Cause Code 表示导致 openUBMC 重启的具体原因，0x2 和 0x10 是不同重启触发源的标识符。

尽管知识库中未直接列出 0x1A00006F 的 Cause Code 定义，但可通过其他实体与逻辑进行推断：

:small_blue_diamond: Cause Code 0x2 的含义：

  • 在知识图谱中，存在实体 Cause Code 0x2，明确描述为：

    “Cause Code 0x2 is the specific code indicating the origin of the openUBMC reset event in the BMC system logs.”

  • 结合日志上下文（多次出现）可判断：0x2 是一种常见、已知的 openUBMC 重启原因，可能代表：
    • 用户手动触发重启
    • 固件升级后正常重启
    • 配置生效触发的软重启

:small_blue_diamond: Cause Code 0x10 的含义：

  • 虽然知识库未直接定义 0x10，但从数值规律和系统设计来看：
    • 0x10（十进制 16）可能代表看门狗超时（Watchdog Timeout） 或 异常崩溃后恢复。
    • 在系统中，这类数值常用于标识非正常重启路径。
  • 在您提供的 operation.log 中亦有线索：

    Set watchdog timer use to (OS Load)
    表明系统使用了看门狗机制，若重启发生在该操作附近，0x10 很可能是看门狗触发的结果。

:white_check_mark: 推断总结：

Cause Code 可能含义
0x2 正常软重启，如固件升级、配置更新、用户命令触发
0x10 异常或看门狗触发重启，可能由系统僵死、任务超时或底层异常引起

四、问题根本原因：反复升级回退压力测试引发多种重启路径

您的测试场景为“反复 BMC 版本升级回退压力测试”，此操作会导致：

  1. 频繁的正常重启（Cause Code 0x2）：每次升级/回退后需重启生效。
  2. 潜在的异常重启（Cause Code 0x10）：在版本切换过程中可能出现初始化失败、资源冲突或看门狗超时，从而触发非预期重启。

这解释了为何：

  • 0x1A00006F 频繁出现
  • 其 Cause Code 在 0x2 与 0x10 之间交替

五、建议与排查方法

:white_check_mark: 建议操作：

  1. 检查 event_def.json 文件
    查看 /opt/bmc/conf/event_def.json 或 /data/opc/bmc/conf/ 目录下是否存在以下定义：

    {
  "EventKeyId": "BMC.OpenUBMCReset",
  "EventCode": "0x1A00006F",
  "Description": "The openUBMC is reset, with the cause code of {CauseCode}."
}

  2. 关联日志排查 0x10 成因
    查找 0x10 发生时间点附近的日志（如 debug.log, ipmi.log），确认是否存在：

    • 看门狗超时（watchdog timeout）
    • 进程崩溃（segmentation fault）
    • 升级失败或回滚异常

  3. 验证版本兼容性与升级流程
    压力测试中不同版本间的兼容性可能引发异常。建议：

    • 使用官方发布的兼容版本组合
    • 加入延迟与状态检查，避免连续快速重启

  4. 更新文档与事件码手册
    将 0x1A00006F 及其 Cause Code 含义补充至内部文档，避免后续误判。

六、结论总结

问题 解答
(1) 事件码未在文档查到？ 属于 openUBMC 自定义事件，定义在 event_def.json 中，文档未更新所致。
(2) 同一事件码对应多描述？ 该事件为参数化事件，描述中 Cause Code 由运行时动态填充，导致内容差异。
(3) 0x2 和 0x10 是什么？ 0x2 表示正常软重启；0x10 可能表示看门狗或异常崩溃触发的重启。

该现象在压力测试场景下属于可预期行为，但高频出现 0x10 需进一步排查稳定性问题。建议结合日志深入分析异常重启根源，以提升系统可靠性。

3

事件码定义参考 【已评审】BMC增加软复位原因资源协作接口【2.0】

4

image
image1699×879 44.7 KB

BMC固件升级压力测试，遇到BMC自愈复位"10h"的情况，如何排查原因？

5

这个是BMC重启后就会有这个事件，code是0x10可以看下是否有组件异常重启，检查一下framework.log