问题描述
双RAID场景，长时间bmc重启或者AC，环境上俩个RAID的信息都获取不到
XC470C-M-8i 4G + XP270-M2
告警
9560-16i + 9560-8i
告警
环境信息
- 软件版本：OpenUBMC SP2
重现步骤
双RAID场景，长时间bmc重启或者AC
日志无法上传 需要日志的话 给个邮箱 通过邮箱传递
初步分析
raid0正常完成注册后 raid1注册sml的时候超时
然后raid0的i2c也访问不通
伴随其他路i2c大量报错
答案内容由AI生成，仅供参考：
总结
您遇到的问题是双RAID场景下，BMC重启/AC过程中因组件初始化未完成或中间转发服务挂死导致的概率性信息获取失败。
核心建议：
- 在
storage组件的add_controller_to_sml流程中增加日志，定位服务卡死点。 - 复盘BIOS与BMC的启动时序，确认是否为“BMC未就绪，BIOS已发起请求”导致。
- 参考知识库中优化丝印获取时间的PR修复方案，验证是否能降低故障概率。
点击此处查看详细分析解答
根据您的问题描述和提供的上下文信息，您遇到的是在双RAID卡场景下，长时间进行BMC重启或AC（交流掉电）循环测试时，以约1/150的低概率出现两张RAID卡信息均无法获取的问题。
结合知识库中高度相关的案例分析（如920BS双RAID场景，AC自动化时概率性出现获取不到RAID卡信息，概率1/100），以下是对您问题的综合分析与解决方向：
1. 问题原理分析
该问题并非简单的硬件故障，而是一个概率性的软件时序问题。核心机制如下：
- 依赖带外通信：RAID卡（如SP686C-M-16i、9560-8i等）的信息获取高度依赖BMC与RAID卡之间的带外管理通道（如MCTP over PCIe或I2C）。
- 中间服务挂死：在获取信息的过程中，
storage组件会调用独立的smld lua service来转发请求。在AC或BMC重启的瞬间，如果时序不当，这个转发服务可能会挂死。 - 对象已建、数据为空：由于转发请求失败，RAID控制器对象虽然在系统树中已创建，但无法实际获取到RAID卡内的控制卡、物理盘、逻辑盘等数据，最终导致Web界面上显示大量字段为
N/A。
2. 可能的原因（结合知识库）
根据知识库中的相关记录，导致该时序问题的潜在原因包括：
- BMC启动慢于BIOS：BMC组件尚未完全初始化（例如
ssdp、file_transfer等服务启动检查失败），此时BIOS已发起信息查询请求，导致读取超时或失败。 - 组件重启：
framework.log中记录了BMC重启事件，且存在组件（如ssdp、file_transfer）启动检查失败的日志，这可能导致BMC功能尚未就绪时便开始处理硬件信息请求。 - 特定硬件配置触发：知识库中的关系数据显示，**“BMC 25.03版本”在“双Riser双RAID场景”**下会出现自动重启，这进一步增加了系统在重启过程中因初始化未完成而丢失信息的概率。
3. 分析及解决方向
基于知识库中类似问题的成功解决方案，建议按以下步骤排查：
第一步：定位卡死点
- 参考
topic 6551中的分析结论，问题集中在Controller_1执行add_controller_to_sml()的过程中。 - 操作建议：在
self:add_controller_to_sml() → sml.register_controller-> CMD.register_controller链路中添加详细日志，确认smld服务具体卡在哪个函数，以便确认是MCTP通信问题还是Lua服务挂死问题。
第二步：检查启动时序
- 参考**“AC后与BIOS交互的信息概率性获取不到问题分析”**的结论，该问题的根因是 “BMC启动慢，当发起上电时，BMC相关组件未初始化完全，丝印还没准备好，BIOS已经启动发IPMI”。
- 您的场景为长时间BMC重启或AC，可能同样存在BMC服务（如
file_transfer、ssdp）在重启后未完全恢复，导致信息读取失败。 - 解决方向：参考知识库中的PR
[优化丝印获取时间](https://gitcode.com/openUBMC/bios/pull/62/commit)，通过提前丝印获取时间，减少因超时导致的内存、RAID卡等信息加载不上的问题。
4. 关于日志提供
您提到“日志无法上传，需要日志给个邮箱”，知识库中的相关案例显示，社区支持人员（如zll）通常需要通过 app.log 和 framework.log 来分析此类问题。关于邮箱联系方式，知识库中并未提供任何具体的邮箱地址。建议您在OpenUBMC社区论坛中，直接联系该问题的分析人员（如您帖子中的回复者）获取传递方式，或查看论坛私信功能。
总结
您遇到的问题是双RAID场景下，BMC重启/AC过程中因组件初始化未完成或中间转发服务挂死导致的概率性信息获取失败。
核心建议：
- 在
storage组件的add_controller_to_sml流程中增加日志，定位服务卡死点。 - 复盘BIOS与BMC的启动时序，确认是否为“BMC未就绪，BIOS已发起请求”导致。
- 参考知识库中优化丝印获取时间的PR修复方案，验证是否能降低故障概率。
加打印后复现一键收集
KunLun2280V2_2102315PDMD9S4100003_20260915-1852.tar.gz (16.7 MB)
这个链接的问题已经解了 这次的问题跟MCTP没有关系
打开了 storelib 详细日志，最终死在了一处 pthread_join ，怀疑是 storelib 内部有死锁的情况
KunLun2280V2_2102315PDMD9S4100003_20260916-0829.tar.gz (16.9 MB)
KunLun2280V2_2102315PDMD9S4100003_20260916-0829.tar.gz (16.9 MB)
调整了raidlib_conf.ini中的日志级别后的再次复现日志