DC测试中产生和Riser上MCU的通信告警

交流互助区
1

问题描述

在DC过程中，产生和SWIFT-2200N Pro网卡所在Riser卡上MCU通信告警，

当前网卡在CSR中配置Scanner去获取温度，在代码中通过调用Chip下Read()方法获取MacAddress；

image
image739×325 11.8 KB

image
image1062×733 24.9 KB

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：OpenUBMC2512

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

重现步骤

  1. 去掉对下电和复位的拦截，然后系统强制下电后，则会通过i2c访问网卡寄存器获取温度和mac，报访问失败，

image

然后间隔15秒左右后产生和Riser上的MCU通信告警；

  1. 包括将系统下电后手动call访问对应Chip也会产生和MCU的通信告警

  2. [第三步]

期望结果

1、复现过程中发现，当系统下电后，只要访问过一次网卡寄存器，就会出现和MCU通信失败的告警；但是当系统上电时，是和MCU的通信检测先通，然后过1分钟左右，读取mac才会正常；

想问一下，下电后访问网卡侧寄存器这个动作具体是触发了什么导致和MCU的通信检测也会失败？

2、应该怎么样来避免，当前我在lua和csr中都配置有上电检查，lua中多检查了下复位属性情况，但在长时间DC中还是产生了一次告警。

实际结果

详细日志：

S920X20_20260520-0940.txt (9.9 MB)

后缀更改为.7z后解压缩

DC日志部分打印：
2026-05-20 00:43:24.274622 fructrl NOTICE: pwr_powerctrl_ipmi.lua(118): Ipmi call powerctrl cmd (2).

2026-05-20 00:43:24.311948 thermal_mgmt NOTICE: fructl_data_keeping.lua(56): Power state changes from ON to OFFING
2026-05-20 00:43:40.504149 event NOTICE: events.lua(106): System minor count change 0 to 1 by [Event_McuCommunicationcheck_01010109].

2026-05-20 00:43:40.956869 power_strategy NOTICE: fructl.lua(65): PowerState(system id: 1) changed from ONING to ON

在强制下电命令执行后37毫秒左右上下点状态就变为OFFING，执行强制下电再上电的命令16秒后产生告警，PowerState状态为OFFING、OFF、ONING，告警后状态才变为ON

DC的过程中没在framework.log中看到DC过程中的scanner enabled状态变化打印；只是第一次DC打印了一次：
2026-05-19 17:43:58.523901 hwproxy NOTICE: app_objects.lua(663): scanner: Scanner_NICTemp_0101010901 change scan enabled to: 0

尝试过的解决方案

分析结论

在产生通信告警的那一次DC中，从强制上下电命令执行到告警产生的这16秒，没有找到证据Scanner_NICTemp和lua中的GetMacAdddress Read操作 去访问了寄存器；

暂无结论

2

答案内容由AI生成，仅供参考：
根据您的要求，我原样提取了回答内容中的“总结”章节内容如下：

总结：根本原因是在系统下电后，系统（BMC）仍然尝试通过I2C总线访问已下电的设备（网卡寄存器）。这个失败的访问动作干扰了与MCU的正常通信链路，触发了MCU通信异常检测机制，从而产生了告警。

总结建议：

  • 已验证：您的Lua和CSR代码逻辑方向正确，核心是通过检查电源状态来控制访问。
  • 待优化：
    • 重点排查 fructl.get_power_status() 在强制下电后状态切换的实时性和准确性，是否存在导致状态检查失败的微小时间窗口。
    • 考虑添加对MCU通信链路的就绪状态检查作为额外的保护措施。
    • 检查在连续DC测试场景下，是否有事件导致 ScanEnabled 配置被错误覆盖或绕过。

通过以上措施，可以最大程度地避免在系统下电后因访问网卡寄存器而触发Riser卡MCU通信告警。

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

好的，根据您提供的上下文信息，我对您提出的关于DC测试中产生与Riser上MCU通信告警的问题进行了分析。以下是基于知识库的详细解答。

问题一：下电后访问网卡寄存器为何会触发MCU通信告警？

根据您提供的日志、代码片段以及知识库中的信息，这个过程可以分解如下：

  1. 系统强制下电：当系统被强制下电后，电源状态变为 OFFING 或 OFF。
  2. 访问网卡寄存器：在系统下电状态下，硬件（如BMC）仍尝试通过I2C总线访问网卡（SWIFT-2200N Pro网卡）的寄存器。根据您的描述，这是为了获取温度（通过 Scanner_NICTemp）和MAC地址（通过 GetMacAddress 函数中的 Read() 方法）。
  3. I2C访问失败：由于系统已下电，网卡和Riser卡上的相关组件可能未处于正常工作状态，导致I2C通信失败。日志清晰地记录了此类错误：
    read macaddress fail, error: ... open channel(1) failed, error: ... response error ...
  4. 触发MCU通信异常检测：BMC持续监控与MCU的通信状态。访问网卡寄存器的I2C操作失败，可能会干扰或阻塞Riser卡上与MCU的正常通信通道。知识库提到，Event_McuCommunicationcheck 是一个告警事件，其数据源为 RiserCard_1.CpldStatus 的Reading值。一个失败的I2C操作可能会影响CPLD的状态，进而触发该告警。最终，Event_McuCommunicationcheck 被映射到 Riser.PCIeRiserMcuCommunicationAbnormal 事件，从而导致您看到的告警。

总结：根本原因是在系统下电后，系统（BMC）仍然尝试通过I2C总线访问已下电的设备（网卡寄存器）。这个失败的访问动作干扰了与MCU的正常通信链路，触发了MCU通信异常检测机制，从而产生了告警。

问题二：如何避免此类告警？

根据您提供的代码和知识库信息，可以从以下几个方面来避免此问题。您当前已经在Lua和CSR中配置了上电检查，这是正确的方向，但可以进一步加强。

  1. 强化上电状态检查的可靠性（您已部分实施）：

    • CSR配置：您已经在 Scanner_NICTemp 中使用了 ScanEnabled 表达式来检查电源状态 (FruCtrl_1_0.PowerState)。请确保该检查在系统下电后能可靠地返回 false，从而禁用Scanner。确认电源状态值在强制下电后能准确反映 OFF 状态。
    • Lua代码：您提供的 GetMacAddress 函数已经包含了电源状态和复位标志的检查：
      if fructl.get_power_status() ~= 'ON' or fructl.get_system_reset_flag() == 1 then
    log:info('[YUSUR] system is not on, do not get mac.')
    return {}
end
      需要检查：fructl.get_power_status() 函数在系统强制下电后的瞬间是否准确返回 'ON' 以外的值。如果存在短暂的状态延迟（例如，在状态变为 'OFFING' 瞬间，旧状态仍为 'ON'），则可能导致检查失效。同时，您还额外检查了 fructl.get_system_reset_flag()，这个逻辑是正确的。

  2. 增加更精细的硬件状态检查：

    • 知识库中提到MCU是Riser卡上负责通信的微控制器。可以考虑在尝试I2C访问前，增加一个直接检查MCU健康状态或通信链路是否就绪的步骤。如果MCU通信链路未就绪，则直接跳过访问，并记录日志。这可以作为电源状态检查之外的第二道防线。

  3. 处理DC过程中的“时间窗口”问题：

    • 您的日志显示，在强制下电命令执行后，约16秒后才产生告警。而您的日志中也提到，Scanner的状态只在第一次DC时被设置为0（change scan enabled to: 0）。这意味着，在大量连续的DC测试中，Scanner可能在下电后的一小段时间窗口内被错误地重新启用，或者存在某个路径绕过了检查。
    • 建议：检查在连续DC操作中，ScanEnabled 条件是否会因为某些事件（如状态短暂闪烁）而被误判为真。确保在电源状态明确为“非ON”时，所有与网卡相关的访问路径都被坚决地阻断。

总结建议：

  • 已验证：您的Lua和CSR代码逻辑方向正确，核心是通过检查电源状态来控制访问。
  • 待优化：
    • 重点排查 fructl.get_power_status() 在强制下电后状态切换的实时性和准确性，是否存在导致状态检查失败的微小时间窗口。
    • 考虑添加对MCU通信链路的就绪状态检查作为额外的保护措施。
    • 检查在连续DC测试场景下，是否有事件导致 ScanEnabled 配置被错误覆盖或绕过。

通过以上措施，可以最大程度地避免在系统下电后因访问网卡寄存器而触发Riser卡MCU通信告警。