AC和强制重启，GPU会出现GPU获取不到温度的告警

bmc_core SIG
1

基于2509的openUBMC构建的版本

AC和强制重启时，应该是因为GPU芯片还没准备好，因此会出现类似0这样的异常温度读值。但是又不能对0这种读值完全过滤，万一真的异常是要报出来的。

image
image1510×789 179 KB

为了区分这种正常情况和异常情况，openUBMC中有没有类似post complete的机制，即OS启动完成，这种情况下GPU应该都准备好了，不会再出现这种误告警。

2

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

:pushpin: 总结建议

项目 建议
是否支持“Post Complete”机制 :cross_mark: 无标准接口，但 :white_check_mark: 有 OS Startup State 可用作等效替代
是否应过滤 0 值温度 :cross_mark: 不建议直接过滤，应结合上下文判断
短期缓解措施 配置传感器读取失败防抖（如连续失败 5 次再告警）
长期根本解决方案 利用 OS Startup State 或 GPU 就绪信号作为告警使能条件
验证方法 使用“一键收集日志”分析 event、app.log、sensor 数据

:light_bulb: 建议行动项：

  1. 在当前 25.09 版本中，优先配置 GPU 相关传感器的 防抖机制。
  2. 推动将 OS Startup State 集成到 Event 管理框架中，实现基于系统状态的动态告警控制。
  3. 在后续版本（如 OpenUBMC 26.03）中，将此类启动瞬态告警问题纳入 通用观察点测试项，防止回归。
点击此处查看详细分析解答

openUBMC 中关于 AC/强制重启后 GPU 温度读取失败告警的分析与解决方案

在基于 OpenUBMC 25.09 构建的系统中，用户反馈在 AC上电（通断电） 或 BMC 强制重启 后，系统频繁上报 GPU/Pcie卡温度获取失败告警（事件码 0x08000005），提示“Failed to obtain data of the PCIe Card X (XX) Chip/Board/HBM temperature”。

此类现象在系统启动初期较为常见，其本质是 硬件初始化时序未完成 导致的 瞬态/误告警（Transient Alert），而非真实硬件故障。本文结合 openUBMC 的机制、社区实践和可靠性设计原则，分析此问题的成因，并探讨可行的解决方案。

:magnifying_glass_tilted_left: 一、问题成因分析

  1. GPU 芯片初始化滞后

    • 在 AC 上电或 BMC 重启后，BMC 启动速度远快于 GPU/PCIe 加速卡的固件加载和链路稳定过程。
    • 在 GPU 主控芯片（MCU）尚未完成初始化、I2C/SMBus 接口未准备好前，BMC 已开始周期性轮询传感器数据。
    • 此时读取操作会失败或返回无效值（如 0、-127°C 等异常值），触发告警。

  2. 事件机制未区分“启动阶段”与“稳定运行”

    • OpenUBMC 的事件管理模块（Event Manager）默认对所有传感器数据异常立即响应，缺乏对系统启动状态的上下文感知能力。
    • 例如，当前系统缺少一个明确的标志（flag）来标识“OS 启动完成”或“GPU 硬件准备就绪”，导致无法判断温度读取失败是暂时性延迟还是真实故障。

  3. 告警处理策略不足

    • 若直接过滤所有“0值”或“无效值”，可能掩盖真实故障（如传感器损坏、I2C 通信永久中断），存在安全隐患。
    • 若不加处理，则会产生大量瞬态告警，干扰监控系统、触发误报，影响客户准入测试与生产环境稳定性。

:white_check_mark: 典型问题表现：

  • 告警集中在 AC 或 BMC Restart 后几秒内集中爆发。
  • 数分钟后自动恢复（Deassert），无真实硬件更换。
  • 一键日志中可看到相关 PCIe 卡的 BDF 信息上报延迟、MCU 初始化日志滞后。

:puzzle_piece: 二、OpenUBMC 是否存在类似 “Post Complete” 的机制？

目前 OpenUBMC 尚未提供完全等同于传统 iBMC 中“Post Complete” 的标准全局信号，但已具备实现该功能的技术基础与组件机制：

:white_check_mark: 1. OS 启动状态监控能力（OS Startup State）
  • 实体支持： OS Startup State 作为全局属性已存在于 OpenUBMC 系统模型中。
  • 设计目标： 用于标识操作系统当前是否已进入稳定工作状态（Running），进而作为其他服务（如传感器告警、遥测上报）的启用条件。
  • 引用关系：
    {"entity1": "OS Startup State", "entity2": "openUBMC", "description": "The openUBMC system requires a global attribute to represent the OS startup state for accurate sensor event triggering."}
  • 意义： 此属性理论上可作为“GPU 应已准备就绪”的判断依据，避免在 OS 未启动完成前上报硬件传感器告警。
:white_check_mark: 2. 组件健康与启动状态检查机制
  • OpenUBMC 引入了 MACA（Micro-component Auto Control Agent） 框架进行组件生命周期管理。
  • 支持组件间依赖关系、启动成功标志检测，并可通过 cpu_board.lua 等脚本监控关键系统状态：
    -- 示例：cpu_board.lua 检查 BMC 启动完成标志
if get_bmc_start_flag() then
    notify_system_ready()
end
  • 这为实现“系统准备就绪”信号提供了底层支撑。
:white_check_mark: 3. 防抖机制（Debounce Mechanism）广泛应用
  • OpenUBMC 社区已有完善的 硬件监控防抖机制，用于抑制瞬态信号波动。
  • 如文档《硬件监控防抖机制参考》中所述，推荐对温度类传感器采用 median_s5、midavg_s4 等滤波算法。
  • 特别地，对于 “读取失败”类事件，可配置延迟触发（Delay Assert）策略：连续失败 N 次后再上报告警。

:hammer_and_wrench: 三、建议解决方案

为解决 AC/强制重启后 GPU 温度误告警问题，建议从 “状态感知” 与 “告警抑制” 两个维度入手：

方案一：引入 “系统就绪后才启用GPU告警” 机制（推荐）

  1. 定义系统准备就绪信号

    • 利用现有 OS Startup State 属性，由主机通过 IPMI Set System Boot Options 命令或 Redfish ResetType: On 后的状态反馈置位。
    • 或由 BMC 内部组件（如 compute 模块）上报“PCIe 枚举完成”、“GPU MCU Ready”事件。

  2. 配置 Event 规则依赖此状态

    • 在 CSR 配置中为 GPU 相关传感器添加 条件触发规则：
      IF OS_Startup_State == Completed THEN
    ENABLE Alert for GPU_Temp_Fail
ELSE
    IGNORE or LOG without Alerting
ENDIF

  3. 优势：

    • 从根本上避免误报，无需复杂滤波。
    • 可推广应用至其他 PCIe 加速卡（NPU、FPGA、AI 卡）。
方案二：实施传感器读取失败防抖策略（短期可用）

  1. 为 GPU 温度传感器配置防抖参数

    • 使用 contbin 配置，设定 连续失败次数阈值（如 5 次） 和 检测周期（如 10s）。
    • 仅当连续失败达到阈值后才生成 SEL 日志或告警事件。

  2. 结合启动窗口期抑制（Startup Suppression）

    • 在 BMC 启动后的前 60 秒内，屏蔽特定 GPU 卡槽的温度读取失败告警。
    • 可通过 Event 模块配置 suppression_window=60s 实现。

  3. 优势：

    • 无需修改业务逻辑，仅调整配置即可。
    • 符合 OpenUBMC 已有设计模式（参考《CSR硬件监控防抖机制》）。
方案三：增强日志与可观察性以便排查
  • 启用一次性日志采集： 使用 “一键收集 openUBMC 日志” 功能，分析 app.log、dmesg_info 中 GPU/MCU 初始化时间线。
  • 检查 PCIe 枚举顺序： 通过命令 ipmitool raw 0x30 0x90 或 ReportPcieCardBDFInfoToBMC 接口确认 BDF 上报延迟情况。
  • 查看组件启动依赖： 检查 compute、vpd、fru 等组件的启动顺序是否影响 GPU 识别。

:white_check_mark: 社区实践参考

  • 类似问题已存在多个案例：

    • Topic 5325：SLOT2 NPU 卡温度丢失，重启 openUBMC 恢复。
    • Topic 5028：AC 长稳偶现 CPU/内存温度获取失败，初步定位为 ipmb 通道注册延迟。
    • Topic 5821：AC 掉电事件日志记录不全，涉及电源事件丢失。

  • AI助手 ubmc_assistant 的建议倾向：

    • 推荐使用 防抖配置 和 状态依赖判断。
    • 强调通过 一键日志分析时序 来定位根本原因。

:pushpin: 总结建议

项目 建议
是否支持“Post Complete”机制 :cross_mark: 无标准接口，但 :white_check_mark: 有 OS Startup State 可用作等效替代
是否应过滤 0 值温度 :cross_mark: 不建议直接过滤，应结合上下文判断
短期缓解措施 配置传感器读取失败防抖（如连续失败 5 次再告警）
长期根本解决方案 利用 OS Startup State 或 GPU 就绪信号作为告警使能条件
验证方法 使用“一键收集日志”分析 event、app.log、sensor 数据

:light_bulb: 建议行动项：

  1. 在当前 25.09 版本中，优先配置 GPU 相关传感器的 防抖机制。
  2. 推动将 OS Startup State 集成到 Event 管理框架中，实现基于系统状态的动态告警控制。
  3. 在后续版本（如 OpenUBMC 26.03）中，将此类启动瞬态告警问题纳入 通用观察点测试项，防止回归。

如需进一步技术支持，可访问 OpenUBMC 论坛相关讨论：

3

尝试增加时延或者询问硬件厂商是否有心跳检测机制