AC后走设备树版本的网卡会先生成获取温度失败的告警，再几秒后消除，这是符合预期的么？

交流互助区
1

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

问题描述

发现使用设备树的网卡（场景中为HP382和MCX631102AN-ADAT），在AC后会先产生获取温度失败的告警，几秒钟后又消除：

image
image1008×643 43.4 KB

告警触发的来源是PCIeNicCard对象下的TemperatureStatus，根据现象推断，两张网卡的该属性值在ac后先被置为了（或是默认值为）1，再被置为了0，所以会有这种情况。但是每次ac都会有这两条记录也太怪了

2

看了下component_drivers仓库的代码，

image
image1031×701 45.5 KB

TemperatureStatus默认值是3，但是被libmcpp转换成bool类型的true了？之后和硬件通信被设置为正常值0？这个3为默认值是咋考虑的

3

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

:end_arrow: 总结建议

:white_check_mark: 建议采取以下行动：

  1. 将此现象定为“需解决”的瞬态告警问题；
  2. 在BMC侧为设备树网卡温度传感器增加防抖处理；
  3. 优化监控启动顺序，待系统基本稳定后再启用敏感传感器监控；
  4. 作为通用测试项纳入AC/DC/BMC重启长稳测试用例中。

最终目标是：系统启动过程中允许状态不稳定，但不应向用户暴露可预见的、非真实故障的告警事件。

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

AC后网卡获取温度失败告警问题分析

根据您提供的上下文和日志信息，关于AC（上电）后设备树版本的网卡（如HP382、MCX631102AN-ADAT）会先产生“获取温度失败”告警，几秒后自动消除的现象，以下是从技术角度进行的综合分析。

:magnifying_glass_tilted_left: 现象描述

在每次AC（交流电源重启/断电再上电）后：

  • 系统会短暂上报 “Failed to obtain data of the PCIe Card X (CardModel) temperature” 告警（事件码 0x80000005）；
  • 数秒钟后，该告警自动恢复，触发 Deasserted 事件（事件码 0x80000006）；
  • 此现象在HP382、MCX631102AN-ADAT等使用设备树（Device Tree）加载方式的网卡上均出现；
  • 告警源自于 PCIeNicCard.TemperatureStatus 属性的状态变化（值从1变为0）；
  • 重复性高，每次AC都复现。

:white_check_mark: 是否符合预期？

:cross_mark: 不符合预期 —— 尽管系统最终恢复正常，频繁出现瞬态告警在生产环境中是不可接受的。

虽然某些初始化顺序问题可能导致硬件状态短暂不可读，但每次都产生明确告警记录，涉及如下风险：

  • 客户准入测试失败：互联网客户网管系统通常对“瞬态告警”非常敏感，会判定为系统稳定性问题；
  • 误触发自动处理流程：可能触发不必要的人工或自动化干预；
  • 日志污染与可维护性降低：大量重复瞬态告警影响故障定位效率。

因此，即使该现象是由于硬件/固件初始化时序导致的，从用户体验和运维标准来看，也不应出现此类可预测的告警。

:puzzle_piece: 根本原因分析

结合知识库内容和行业实践，本问题的核心原因可归结为以下几点：

1. 硬件初始化时序不一致

  • AC启动期间：
    • BMC先启动并开始轮询传感器；
    • 此时网卡尚未完成固件加载或I²C温度传感器未激活；
    • 传感器访问失败（如LM75芯片不可通信），触发 TemperatureStatus=1（异常）；
    • 数秒后网卡固件启动完成，传感器可读，状态恢复正常；
    • 最终系统自动清除告警。

:pushpin: 这与文档ID 8（OCP网卡热拔插场景）中类似：“Scanner_CardPowerGood先变1，Scanner_NIC_Lm75 status后才变0”，存在50秒级延迟差——说明电源恢复不等于传感器立即可用。

2. 缺少防抖机制（Debounce Mechanism）

  • 当前系统未对传感器状态进行时间窗口过滤；
  • 一旦检测到一次读取失败即立即上报告警；
  • 正确做法应为：仅当连续多次读失败或持续一定时间无法读取才触发告警；
  • 否则视为初始化过程中的正常暂态。

:white_check_mark: 推荐：引入至少 5~10秒的防抖延迟，避免在系统启动阶段误报。

3. 设备树驱动加载机制特性所致

  • 使用设备树（Device Tree）方式加载的网卡（非标准PCIe枚举）依赖BMC读取E2prom、I²C寄存器或电子标签获取配置；
  • 加载时机可能晚于BMC传感器监控模块启动；
  • 导致模块初始化完成前，温度采集对象尚未建立或未置为“正常”状态。

参见文档ID 4：“AC启动过程中，DPU卡在位默认配置成了在位，在进行在位信号防抖处理时卡状态默认配置为不在位，造成卡会出现误加载后卸载再加载现象”。

:hammer_and_wrench: 解决建议

类别 建议 说明
软件优化 引入温度传感器状态防抖机制 针对 Event_TempFail 设置最小持续时间（如5秒），仅当连续超时未恢复才上报告警
初始化流程控制 延迟网卡温度监控模块的启动 等待 openBMC is restarted 和 ACPI is working 事件完成后再激活传感器轮询
状态处理逻辑增强 将启动阶段的“暂不可读”视为未知状态而非故障 不强制将未就绪传感器标记为 1（失败），而应设为 null 或 unknown，避免触发告警
配置层面优化 在设备树中定义 initialization-delay 参数 明确不同网卡类型的启动等待时间，供BMC参考
日志与观测点管理 在AC流程测试中将“瞬态告警”列为观测重点 参考文档ID 1：“AC/DC/BMC重启场景容易出现瞬态告警问题”

:books: 相关参考资料引用

  1. 文档ID 1《openUBMC通用观察点分享》：

    “正常测试时，客户的任何正常操作（非真实故障或主动模拟场景），均不得出现告警信息或瞬态告警。”

  2. 文档ID 5《Liujie_11提问：AC和强制重启，GPU会出现获取不到温度的告警》：

    “为了区分这种正常情况和异常情况，openUBMC中有没有类似post complete的机制？”

    ➤ 表明业界已有对OS启动完成后再开启监控的设计思考，可用于解决同类问题。

  3. 文档ID 4《openUBMC智能网卡适配经验分享》：

    “AC启动过程中……概率出现网卡温度监控相关对象重复加载报错”。

    ➤ 直接指出AC启动过程中存在温度监控组件加载竞争问题。

  4. 知识图谱实体 Event_TempFail：

    Key: PcieCard.PCIeCardTempFail，触发条件为无法访问OCP Netcard传感器，且依赖电源状态和I²C连通性。

:white_check_mark: 结论

项目 判断
是否正常？ :cross_mark: 不符合预期
是否可接受？ :cross_mark: 不可接受（影响客户验收和运维体验）
是否有解决方案？ :white_check_mark: 有，建议增加防抖和启动时序控制
是否属于已知问题？ :white_check_mark: 是，类似问题已在OCP卡、DPU卡等场景中有记录

:end_arrow: 总结建议

:white_check_mark: 建议采取以下行动：

  1. 将此现象定为“需解决”的瞬态告警问题；
  2. 在BMC侧为设备树网卡温度传感器增加防抖处理；
  3. 优化监控启动顺序，待系统基本稳定后再启用敏感传感器监控；
  4. 作为通用测试项纳入AC/DC/BMC重启长稳测试用例中。

最终目标是：系统启动过程中允许状态不稳定，但不应向用户暴露可预见的、非真实故障的告警事件。

4

目前该问题已在近期解决，尝试升级一下最新component_drivers组件代码看一下问题是否解决？最新代码中TemperatureStatus默认值参照 Scanner详解及数据更新机制 | 文档中心 | openUBMC设置为了4