2603版本risercard3报告警

交流互助区
1

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

问题描述

服务器静置时小概率性的产生risercard3失败告警

image
image865×299 54.2 KB

环境信息

  • 软件版本：OpenUBMC2603

分析

该告警是通过发送0x1A opcode查询链路状态通信是否正常，连续三次失败就会产生告警。对MCU命令实际的读写分析，发现pciecard3容易出现链路不同的情况产生。

图一为risercard3的命令读写打印，可以看到很多error。小概率会连续三次失败。

图片
图片1066×573 184 KB

图二为pciecard2的读写命令打印，多次轮训读写都未发现error，链路稳定。所以未产生告 警

图片
图片1053×436 162 KB

结论：通过打印可以一看到报的错误码为290，查询文档后，该错误码含义是表示Hisport总线读写操作未完成，通常是硬件链路不通的问题，但是升级iBMC后正常，不存在这个问题，目前的差异还是在BMC版本上

2

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

4. 总结建议

  • 关于错误码 290：上下文未提及该错误码含义（Hisport 总线读写未完成），无法直接基于现有资料分析，建议查阅对应 MCU/板级文档或 iBMC 的官方说明。
  • 可能关联点：
    • RiserCard3 的通信链路稳定性问题与 0x08000095（PCIe 卡通信失败）类似，但错误码不同，需确认是否属于同一类故障。
    • BMC 版本差异（OpenUBMC 2603 vs iBMC）可能影响对链路状态的轮询超时、重试次数或错误处理逻辑，从而导致告警触发阈值变化。
  • 进一步排查方向：
    • 检查 /opt/bmc/conf/event_def.json 中是否有与 RiserCard3 通信失败相关的事件定义，并确认版本号是否与实际一致。
    • 对比正常（无告警）的 RiserCard2 与异常 RiserCard3 的 RunningStatus 值，观察是否出现 0 异常状态。
    • 利用 D-Bus 路径 /bmc/kepler/Systems/1/Boards/RiserCard/RiserCard_1_01010101 查看对应 RiserCard 实例的属性，确认 ObjectIdentifier 和 SerialNumber 是否匹配。

由于上下文信息的局限性，以上内容仅能提供参考框架，具体根因还需结合更详细的硬件链路日志和 iBMC 版本对比进行分析。

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

根据您提供的上下文信息，对 OpenUBMC 2603 版本中 RiserCard3 告警 问题进行分析如下。需要说明的是，上下文并未直接包含错误码 290（Hisport 总线读写未完成）的具体解释，因此无法完全确认该告警根因；但可以从中提取与 RiserCard、通信故障及 BMC 版本相关的信息，为诊断提供参考。

1. RiserCard 与告警相关实体

  • Riser3 Card
    在知识图谱中被描述为 a PCIe riser card, indicating normal operation（指示正常运行的 PCIe riser 卡）。但在您的场景中产生了告警，表明该组件实际处于异常状态。

  • 通信失败事件码
    上下文记录了以下与通信失败相关的告警代码：

    • 0x08000095 – iBMC 与 PCIe 卡（如 Raid Card 9560-8i）之间的通信失败，会引起重大告警。
    • 0x03000013 – openUBMC 与 PSU 之间的通信失败。
      这些代码与您提到的 0x1A opcode 查询链路失败在机制上可能类似，但错误码内容不同。

  • RunningStatus
    RiserCard 等组件具有 RunningStatus 属性（U8 类型），值为 1 表示正常，0 表示异常。该属性由 BMC 动态更新，可用于监测 RiserCard 是否处于正常工作状态。

  • 系统信息
    关系显示 “System Information displays that 2 out of 3 Riser Cards are installed”，说明系统中可能只安装了两块 RiserCard，第三块（RiserCard3）可能未安装或处于异常状态，这与您观察到的告警可能有关联。

2. BMC 版本差异分析

  • 您提到在升级 iBMC 后告警消失，差异在于 BMC 版本。
  • 上下文中的 Document Chunk #8（openUBMC 版本号自定义不生效问题分析）指出：

    仅修改 manifest.yml 的 show_version 仅影响包命名，不能改变运行时的版本。BMC Web界面显示的版本号实际上是根据 /etc/version.json 中的 openUBMCVersion 字段决定的。
    这意味着不同 BMC 版本（如 OpenUBMC 2603 与 iBMC）可能因版本配置、组件差异导致对同一硬件链路的处理逻辑不同，从而影响告警的产生。

3. 告警配置机制参考

上下文中的 Document Chunk #7（告警配置机制介绍）说明了告警的两种方式（CSR 配置告警与事件 RPC 告警），并提供了 event_def.json 文件的结构与版本管理。如果事件定义文件内容为空或版本不匹配，可能导致部分告警无法正常触发或恢复。这与您问题中提到的“连续三次失败才产生告警”可能有关，但上下文并未给出关于 0x1A opcode 或错误码 290 的具体配置。

4. 总结建议

  • 关于错误码 290：上下文未提及该错误码含义（Hisport 总线读写未完成），无法直接基于现有资料分析，建议查阅对应 MCU/板级文档或 iBMC 的官方说明。
  • 可能关联点：
    • RiserCard3 的通信链路稳定性问题与 0x08000095（PCIe 卡通信失败）类似，但错误码不同，需确认是否属于同一类故障。
    • BMC 版本差异（OpenUBMC 2603 vs iBMC）可能影响对链路状态的轮询超时、重试次数或错误处理逻辑，从而导致告警触发阈值变化。
  • 进一步排查方向：
    • 检查 /opt/bmc/conf/event_def.json 中是否有与 RiserCard3 通信失败相关的事件定义，并确认版本号是否与实际一致。
    • 对比正常（无告警）的 RiserCard2 与异常 RiserCard3 的 RunningStatus 值，观察是否出现 0 异常状态。
    • 利用 D-Bus 路径 /bmc/kepler/Systems/1/Boards/RiserCard/RiserCard_1_01010101 查看对应 RiserCard 实例的属性，确认 ObjectIdentifier 和 SerialNumber 是否匹配。

由于上下文信息的局限性，以上内容仅能提供参考框架，具体根因还需结合更详细的硬件链路日志和 iBMC 版本对比进行分析。

3

日志：

KunTaiR722K2_KS008310S729100028_20260801-0235.tar.gz (6.7 MB)

4

请问这个问题，使用的riser编码是多少呢，riser上是否有插卡

AC后，RAID卡下硬盘概率性出现定位灯关灯失败，长时间闪烁
5

插了SP681网卡

image

7

该问题目前已经分析清楚，26.03版本sdk中框架组件处理通信信息的逻辑异常，导致这里有概率发不通，会上报告警。26.06版本sdk已修复该问题，建议使用新版本sdk或等待问题修复。如果需要临时规避该问题，可以先删除上报告警的相关csr配置