OS下升级AI卡的mcu会上报告警，mcu升级成功后告警消失

[hk1089]

问题描述

OS下升级AI卡的mcu会上报告警，mcu升级成功后告警消失

环境信息

• 操作系统：OS：“openEuler 22.03 (LTS-SP4)” 内核版本：5.10.0-216.0.0.115.oe2203sp4.aarch64

• 软件版本：OpenUBMC2509

• 硬件配置：[如 CPU、内存等]

重现步骤

1. OS下升降级300I A2 64G卡的MCU

   升级命令：npu-smi upgrade -t mcu -i 0 -f Ascend-hdk-910b-mcu_25.53.33.hpm

   

2. 升级过程中，登录BMC Web，查看告警事件->当前告警，上报轻微告警事件：

   

3. mcu完全升级成功后，告警消失

   
   

4. 查看该告警触发条件，关联的是CpldStatus，升级过程中的确会变化，导致事件触发。

   

期望结果

升级过程中与AI卡的连接确实会中断，但是这个过程应该做对应的屏蔽处理；不应当短暂的产生，然后又消失。

实际结果

300I A2 mcu升级过程中的短暂告警，升级完后自行消失

尝试过的解决方案

1.尝试定位触发原因，发现目前的实现就是如此；但是从设计角度来说，应当在升级过程中不报，其他真正通信异常时才上报。

[ubmc_assistant (openUBMC_Assistant)]

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

总结

项目	内容
问题性质	设计缺陷（应屏蔽可预期中断）
根本原因	未识别MCU升级状态，导致将预期中断误判为通信异常
解决方案	引入升级状态感知 + 防抖机制 + 优化告警触发条件
推荐优先级	☆（高频运维操作，易引发误判）
参考依据	openUBMC 25.09已支持VRM/NPU升级禁用上电、自恢复等高级控制，具备实现本优化的技术基础

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

AI卡MCU升级过程中上报通信告警问题分析与建议

在使用openEuler 22.03 (LTS-SP4)操作系统和OpenUBMC 25.09软件版本的环境中，执行AI加速卡（如Ascend 300I A2 64G）的MCU固件升级时，系统会在BMC侧短暂上报**“MCU通信异常”**（事件码 0x0F00001D）的轻微告警。该告警在MCU升级完成后自动消失。本文基于已有知识库信息对该问题进行综合分析，并提出优化建议。

---

问题概述

• 现象：在OS下执行 npu-smi upgrade -t mcu 命令升级AI卡MCU期间，BMC Web界面显示“MCU通信错误”告警。
• 触发主体：PCIe Riser卡1（RiserCard_1）
• 事件码：0x0F00001D
• 告警级别：轻微
• 持续时间：短暂，MCU升级成功后自动清除
• 影响：虽不影响功能，但可能引起运维误判为真实硬件故障。

---

根因分析

1. 告警触发机制分析

从提供的配置片段可见，该告警由以下规则触发：

"Event_McuCommunicationcheck": {
    "EventKeyId": "Riser.PCIeRiserMcuCommunicationAbnormal",
    "Reading": "</RiserCard_1.CpldStatus",
    "Condition": 1,
    "OperatorId": 5, // 等于
    "InvalidReadingIgnore": 1,
    "InvalidReading": 255,
    "Component": "#/Component_RiserCard"
}

这表明：

• 告警判断依据是 RiserCard_1.CpldStatus 的值是否等于 Condition（即 1），当满足条件时触发“MCU通信异常”。
• 在MCU升级过程中，由于I²C通道被占用或MCU重启，CpldStatus 可能临时变为无效状态（如进入升级模式或复位），导致此条件被满足。

虽名为“MCU通信异常”，但实际依赖的是CPLD状态字段，而非直接检测I²C/MCU心跳信号。

2. MCU升级期间的行为特征

根据知识库中的文档和实体描述：

• MCU升级本质是通过SMBus/SMC协议对嵌入式微控制器进行固件写入，过程涉及：

  • 切换I²C通道控制权（BMC ↔ MCU）
  • MCU进入编程模式，暂停正常服务响应
  • 升级完成后需断电或重启生效（见VRD/MCU共享通道机制）

• 在升级阶段：

  • MCU可能无法响应心跳请求
  • I²C总线可能被阻塞
  • 相关传感器读取失败，ReadingStatus 被置为异常（参考NPU卡传感器上报流程）

这些行为在设计上属于预期流程，不应被误判为硬件故障。

3. 防抖机制缺失

尽管系统存在针对带内热升级的防抖策略（如openUBMC 182x大板管理特性设计说明书中所述），但当前场景未应用有效防抖处理：

• 当前策略仅屏蔽了某些升级场景下的温度告警，未覆盖 MCU通信类告警
• InvalidReadingIgnore 和 InvalidReading 字段虽设置为 255，但未结合升级状态标识进行动态屏蔽

类似场景已在其他组件中实现良好控制。例如，RAID卡开发指南中建议：通过识别“升级中”状态来屏蔽误报；而NPU卡在OS启动阶段也会因无数据产生ReadingStatus=1的情况，但可通过PowerState等属性限制误报（尽管未能完全奏效）。

---

关联知识点支持

概念	关联说明
MCU通信机制	MCU负责管理Riser卡上的硬件控制、传感器聚合和EEPROM访问。OS下通过带外管理协议（SMBus）与其交互。升级过程中会中断正常通信。
BMC告警生成逻辑	sensor模块检测到Sensor ReadingStatus变为异常后，会自动生成SEL事件并上报至Mngmt Health传感器（参考DC-4）。
心跳检测失败告警	如DC-5所示，“MCU communication error”告警本质为BMC与MCU间心跳检测失败，通常由高频率Hisport读写阻塞I²C总线引起。
升级互斥与通道控制	MCU和VRD共用一个升级通道，存在互斥限制（DC-2）；MCU升级前需切I²C通道至BMC侧，否则访问失败（DC-8）。

---

期望行为 vs 实际行为对比

项目	当前实际行为	期望行为
升级过程中的告警	报出“MCU通信异常”告警	不产生告警，升级为预期行为
告警清除方式	升级完成后自动消失	不应触发，无需清除
运维感知	容易误判为硬件问题	清晰区分“升级中”与“真实故障”
系统智能性	缺乏状态识别	应识别升级状态并屏蔽临时异常

---

改进建议

1. 引入升级状态感知机制

在 RiserCard_1 或其关联对象（如 MCUFirmware_1）中引入升级状态标志位（UpgradeState），可通过以下方式获取：

/bmc/kepler/FirmwareComponentInfo_Mcu1 -> UpgradeState (0=Idle, 1=Upgrading)

然后在告警判断逻辑中加入前置条件：

"PreCondition": "</MCUFirmware_1.UpgradeState != 1"

即：仅当不在升级状态时才允许触发通信异常告警。

---

2. 启用通信异常防抖策略

参考DC-5中其他用户的修复思路，可在I²C通信检测中增加防抖（debounce）机制：

• 设置合理的超时时长（如3~5秒）
• 多次检测失败后再上报告警
• 升级期间允许短暂失联，不立即告警

相关日志可记录为INFO级别而非ERROR，避免触发SEL。

---

3. 优化事件关联逻辑

当前告警基于 CpldStatus 字段判断MCU通信状态，存在间接性和误判风险。建议改为直接读取MCU心跳或状态寄存器（如通过Chip_MCU_2e6对象）。

例如：

"Reading": "</Chip_MCU_2e6.HeartbeatStatus"

并通过Lua脚本监控其连续性。

---

4. 提供升级指引或静默模式

在BMC前端界面或CLI中提供选项：

• “允许在升级期间静默相关告警”
• 或在执行 npu-smi upgrade 前调用API通知BMC进入维护模式

# 示例：通知BMC即将开始MCU升级
bmc-tool maintenance start --target=RiserCard_1 --reason=MCU_UPGRADE

升级结束后自动退出维护模式，恢复监控。

---

验证建议

1. 在测试环境中模拟MCU升级过程，验证是否仍上报告警
2. 检查SEL日志和传感器事件队列是否干净
3. 故障注入验证：在非升级状态下断开I²C连接，确认告警仍能正常触发（保证不失活）
4. 多轮升级压测，验证防抖机制稳定性

---

总结

项目	内容
问题性质	设计缺陷（应屏蔽可预期中断）
根本原因	未识别MCU升级状态，导致将预期中断误判为通信异常
解决方案	引入升级状态感知 + 防抖机制 + 优化告警触发条件
推荐优先级	☆（高频运维操作，易引发误判）
参考依据	openUBMC 25.09已支持VRM/NPU升级禁用上电、自恢复等高级控制，具备实现本优化的技术基础

---

建议反馈路径：
将此问题提交至 OpenUBMC论坛 或 GitHub Issue，标题可拟为：
“Enhancement: Suppress MCU communication alarm during OS-triggered upgrade”
并引用相关案例（如 topic_id 2268、4303）以增强说服力。

[Longbow (ZhangZhiyang)]

当下bmc无法感知AI卡mcu通信异常是否是带内升级导致的，且该告警属于正常上报状态，不需要和带内升级mcu状态耦合