RAID卡的I2c概率性访问超时

[l00012320 (kunlun_luzhanghui)]

问题描述

9500-16i HBA卡适配，开启带外管理，发现日志报错Timeout，手动调用busctl方法访问RAIDChip，发现概率性超时，不像是器件本身的问题。

拓扑关系如图所示：

重现步骤

1. 代码调用sml库访问RAID卡信息，提示访问超时。
   
   
2. 手动调用busctl命令访问硬件芯片，概率性超时。
   
   
   
   
   

期望结果

I2c访问正常无延迟，RAID卡信息正常获取。

实际结果

i2c概率性超时，导致RAID组件不断重试，获取信息时间过长。

希望得到的帮助

提供I2c定位的思路，确认是框架上因为访问LIB库导致的协程阻塞，还是因为硬件上这条链路的i2c冲突确实比较严重。

[ubmc_assistant (openUBMC_Assistant)]

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

9500-16i HBA卡I²C概率性访问超时问题分析与定位

针对您提出的“9500-16i HBA卡适配中出现I²C概率性访问超时”问题，结合提供的日志、拓扑结构及系统上下文，本报告将围绕问题描述、根本原因分析、定位思路和解决方案建议展开，旨在区分是软件框架阻塞还是硬件I²C通道冲突所致。

---

问题概述

• 设备型号：9500-16i HBA（Host Bus Adapter）
• 故障现象：
  • 开启带外管理后，storage 模块通过 SML 库访问 RAID 控制器时概率性超时。
  • 手动调用 busctl 访问 Chip_RaidChip_0101010A03 设备也出现间歇性超时（如日志中 used time[504s]、wait 39s timeout）。
  • 日志显示：kepler.hwproxy.RequestTimeout、PluginRequest 调用失败。
• 关键特征：
  • 非持续性故障：部分请求能成功返回数据，表明器件本身未完全失效。
  • 超时时间极长（达数百秒），远超正常 I²C 通信时限（通常毫秒级），暗示可能是协程阻塞或总线死锁。
  • 芯片位于 I²C 多路复用器 Pca9545 分支下的 Channel 2，共享一条 Hisport 总线。

---

拓扑结构与通信路径

Hispport_4
├─ Eeprom_3_10_010101
│  └─ Pca9545_PCA9545_0101010A (I²C Mux)
│     ├─ Channel_0 → TempChip, Eeprom
│     ├─ Channel_1 → TempChip, Eeprom
│     ├─ Channel_2 → Chip_RaidChip_0101010A03 ← 目标设备（9500-16i）
│     └─ Channel_3 → MCU, IO Expander, LM75

• 通信链路：BMC → Hisport I²C → Pca9545 多路复用器 → Channel 2 → Chip_RaidChip
• 关键路径依赖：
  • Hisport 为共享总线资源。
  • Pca9545 对各通道切换需时间控制和仲裁。
  • 所有 I²C 操作由 hwproxy 统一管理，并通过插件机制调度。

注意：从日志中访问成功的记录看（例如读取 256 字节返回有效数据），说明通信协议层和地址配置基本正确，排除了芯片物理损坏或地址错误的可能。

---

根本原因分析（基于知识图谱与文档）

根据提供的 Knowledge Graph 和 Search Result 中的技术资料，可归纳出两大类潜在原因：

---

一、硬件层面：I²C 总线竞争与阻塞（高概率主导因素）

支持证据：

1. Huangminghao 报告 I²C Blocking 是瓶颈

   "Huangminghao reported that the information retrieval is slow due to I2C blocking."

   • 明确指出 I²C 阻塞是性能下降的主因，尤其在多设备场景下。

2. Riser 卡可能导致 I²C 总线独占

   "The riser card can block the I2C bus by not loading the RAID card, leading to delayed or failed commands."

   • 若 Riser 卡未正确初始化，或其 CPLD/I²C 驱动异常，可能会长时间占用总线。
   • 同一 Pca9545 下挂多个设备（温度传感器、EEPROM、MCU等），并发访问易引发冲突。

3. I²C 链路本身不稳定

   "The RAID card is connected via the hisport I2c link, which exhibits instability and communication failures."

   • 存在已知的 Hisport I²C 链路不稳定性问题。
   • 特别是在高负载下（如 RAID 卡频繁轮询），更容易触发超时。

4. ContBin 防抖机制中针对 I²C 访问设置了长延迟监控

   contbin_H10L5 ~ H40L5 用于 RAID 卡通信丢失、I²C 器件访问失败等场景

   • 说明系统设计层面已预见到 I²C 通信不可靠的问题。

---

二、软件/框架层面：协程阻塞或调度延迟

支持证据：

1. Storage 组件使用插件式 I²C 访问机制

   “storage组件使用插件式访问调用I2C，如果没有加载raid卡，在获取不到预期信息时会长时间独占总线，导致命令阻塞”

   • 关键点：当 RAID 卡未加载或无响应时，I²C 请求会“长期独占总线” → 此即所谓“命令阻塞”。
   • 若缺乏合理的超时处理和重试策略，会导致后续请求排队等待。

2. I²C 请求经过多层代理与虚拟机隔离

   “调用 sml 库 → PluginRequest → skynet_send → hwproxy → 实际 I²C 发送”

   • 这一过程涉及 Lua 协程、Skynet 消息队列、Worker 虚拟机等多层抽象。
   • 若某次 Read 请求无响应，而协程未被及时唤醒，会造成长时间挂起（表现为 500+ 秒延迟）。

3. RAID 卡 TypeID 配置异常可能影响识别

   "The 9500-16i's typeID is set to 20 in controller_object.lua, which differs from the supported value for out-of-band management."

   • 当前 TypeID=20，但 out-of-band 管理期望为 TypeID 19。
   • 尽管 Huangminghao 表示已为此分配 TypeID 19，若仍使用 TypeID 20，则可能导致管理驱动行为异常。
   • 日志中也出现了 typeid is 20 的提示：
     controller0 start sml_get_ctrl_info 0 times, typeid is 20

4. 日志显示超时来自 hwproxy 服务

   service[bmc.kepler.storage] request timeout: remote service[bmc.kepler.hwproxy]...

   • 表明问题出在 hwproxy 是否正常响应请求，而非仅仅 SML 库调用失败。
   • 可能是 hwproxy 内部正在处理其他阻塞性任务，无法及时处理新的 I²C 插件请求。

---

定位思路与诊断建议

为明确是 硬件链路竞争 还是 软件框架阻塞 导致的 I²C 超时，请按以下步骤逐步排查：

第一步：确认是否有其他设备竞争同一 I²C 通道

# 查看当前 Hisport_4 总线上挂载的所有设备
busctl --user tree bmc.kepler.hwdiscovery | grep Hisport_4

# 检查 Pca9545 分支下的所有设备是否存在异常访问
busctl --user introspect bmc.kepler.hwdiscovery /bmc/kepler/I2cMux/Pca9545_PCA9545_0101010A

• 问题：是否有其他设备（如 MCU、LM75）也在密集轮询？
• 建议：临时禁用非必要设备的轮询服务，观察 Chip_RaidChip 是否恢复稳定。

---

第二步：手动测试不同设备访问延迟对比

# 测试同一 Pca9545 下其他设备（例如温度传感器）
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Complex/Chip_TempChip_0101010A01 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0 0x1

# 测试 EEPROM
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/General/Eeprom_3_6_0101010A bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0 0x10

• 若其他设备也出现概率性超时 → 指向总线级问题（Hispport 或 Pca9545）
• 若仅 RAIDChip 超时 → 更倾向 RAID 卡自身响应慢或驱动兼容性问题

---

第三步：检查 RAID 卡初始化流程是否异常

查看 controller_object.lua 初始化日志：

storage NOTICE: controller_object.lua(150): controller init obj.Id = 255, object_id = 1
storage ERROR: tasks.lua(83): task [Controller.register_controller.0] error: ...Failed to add controller 0, ret: 4357

• 检查错误码 0x11D8（即 4357）是否对应 SML 库加载失败。

• 同时确认 /usr/lib64/libsml_lsi.so 是否存在（博通 RAID 卡依赖该库）：

  ls /usr/lib64/libsml_*.so
  

• 若缺少库文件或加载失败 → 会导致持续重试注册，占用 I²C 通道。

---

第四步：审查 TypeID 配置一致性

在 controller_object.lua 中查找：

if typeID == 20 then
    -- 当前配置为 20，但是否支持带外管理？
end

• 建议：修改为 TypeId 19（已知支持 out-of-band management），并重启 storage 服务验证。

---

第五步：启用 RAID 卡详细日志分析通信过程

参考文档指引生成详细 I²C 日志：

mount -o remount,rw /
vi /opt/bmc/conf/raid/raidlib_conf.ini

修改以下内容：

DEBUGLEVEL2MASK=0
LOG_PATH=/tmp
LOG_SIZE=100M

重启系统后，在 /tmp 查看生成的 raid_controller_lib.log，搜索：

• I2C Write
• I2C Read
• Timeout
• Chip Address

可清晰看到：

• 每次请求的完整 I²C 报文；
• 是否存在 ACK 失败、NACK、SCL 拉低等问题；
• 是否有来自其他模块的干扰请求。

---

解决方案建议

类别	建议措施	依据
硬件优化	降低 I²C 总线负载，避免多设备并发访问	I2C Blocking 是已知性能瓶颈
	确保 Riser 卡、Pca9545 工作正常，无固件问题	Riser Card can block I2C bus
软件修复	将 9500-16i 的 TypeID 改为 19	TypeId 19 was assigned to resolve recognition issues
	确认 libsml_lsi.so 已正确安装并启用	避免因库缺失导致无限重试
	优化 hwproxy 的 I²C 插件调度策略，加入短超时 + 快速重试机制	减少因单次失败引发长时间阻塞
日志诊断	启用 raidlib_conf.ini 调试日志，抓取完整 I²C 交互	精确定位底层通信失败原因

---

结论

综合分析，9500-16i HBA 卡的 I²C 概率性超时问题极可能是由“软件框架在异常情况下长期占用 I²C 总线”与“硬件链路本身负载高、稳定性差”共同作用的结果。

根本原因判定优先级：

1. 高优先级：storage 模块因 TypeID 不匹配或 SML 库加载失败，导致反复尝试注册 RAID 控制器，从而长时间占用 I²C 通道。
2. 中优先级：共享 Hisport I²C 总线设备过多，在高并发场景下发生资源争抢。
3. 低优先级：RAID 芯片自身故障（因部分读取成功，基本排除）。

---

建议下一步行动

1. 立即验证：将 controller_object.lua 中 9500-16i 的 typeID 从 20 改为 19。
2. 检查依赖库：确认 libsml_lsi.so 是否存在且加载成功。
3. 开启调试日志：配置 raidlib_conf.ini 输出详细 I²C 日志。
4. 隔离测试：关闭其他 I²C 设备轮询，单独测试 RAIDChip 访问。
5. 长期优化：引入 I²C 请求超时熔断机制，防止单点故障拖垮整个总线。

---

通过以上步骤，可有效区分是软件框架缺陷导致的“伪超时”，还是真实硬件通信瓶颈，进而采取针对性措施彻底解决问题。

相关链接：

1. 无法获取raid卡信息，报错1104，控制器初始化未完成
2. 【问题咨询】Raid 卡Controller类TypeId修改意见咨询
3. 【存储管理】搭载双 RAID 场景下，存在 PluginRequest timeout 日志刷屏
4. SP686C-M-16i 4G Raid卡EEPROM is fault告警问题
5. MCU、VRD、CSR、CPLD升级与板卡管理问题指南 | 文档中心 | openUBMC

[yelmh_kno07 (huangminghao)]

raid卡获取数据的方式由并行改为串行防止插件请求队列阻塞-storage-AtomGit | GitCode
你用的storage版本带上这个PR了吗，已经在业务上减少I2C的访问了，最终访问I2C都是串行的，通过plugin中的队列，历史上把队列中任务的数量打印出来过，确实队列阻塞了很多任务，也把每个任务的耗时打印过，快的1s内，慢的也有几秒的。
还有就是对于9500-16i，用历史的库打印过，甚至出现过300s才返回的情况，更换了新的库后，性能有所改善，但仍会因为队列增长速度大于队列中任务处理的速度，导致队列任务堆积而报超时

[l00012320 (kunlun_luzhanghui)]

切换1230基线后，会有如下报错，请帮忙分析一下看看。
打印加法如下：

看起来是调用sml.get_ctrl_info失败了，4356对应0x1104，// 控制器初始化未完成
OS内是能看见这张RAID卡的，帮忙看下有没有什么额外的排查方向？

[yelmh_kno07 (huangminghao)]

这个问题 已经和神码对齐解决了吗