hk1089
(Hk1089)
1
问题描述
Riser使用过程中，某次上下电后riser卡本身和插在riser上的AI卡均识别不到
环境信息
-
操作系统：
-
软件版本：OpenUBMC2509
-
硬件配置：
重现步骤
-
环境上3张Riser，riser本身和插得卡都正常识别
-
某次上电后，发现Riser卡无法识别，其中一张riser能识别，但是插在riser上的AI卡
期望结果
RIser卡和插在riser上的pcie卡都应该正常识别，不应该因为AC上下电导致失效
实际结果
Riser使用过程中，某次上下电后riser卡本身和插在riser上的AI卡均识别不到
尝试过的解决方案
问题根因：
1、无法识别riser卡：eeprom的数据被修改，无法提供正确的在位信号，因此BMC无法加载。
2、识别riser卡但无法加载riser上的AI卡：由于eeprom被修改，BIOS无法通过AI获取带宽信息，无法完成建联；无法提供四元组给BMC加载AI卡。
下一步计划：1、当前对比异常和正常eeprom的数据，发现不同点都在重要数据段，不像是随机破坏写入；怀疑是有相应的流程刷写了新的csr到eeprom。对齐出现问题的两个环境未进行其他操作（如装备脚本等）。
答案内容由AI生成，仅供参考：
结论
本次故障的核心是Riser卡EEPROM数据被异常修改，破坏了硬件自描述机制。建议立即采取措施防止类似事件再次发生，并加强对关键配置数据的保护和监控。
点击此处查看详细分析解答
Riser卡及AI卡无法识别问题分析报告
问题概述
在使用Riser卡的过程中，某次上电后出现Riser卡本身和插在其上的AI加速卡均无法被系统识别的故障。该问题在OpenUBMC2509版本中出现，影响系统的稳定性和可靠性。
环境信息
- 操作系统：未具体说明
- 软件版本：OpenUBMC2509
- 硬件配置：S920X20平台，配备3张Riser卡（型号BC83PRUR），其中部分Riser卡连接AI加速卡
问题现象
- 正常情况：3张Riser卡及其连接的AI卡均可正常识别
- 异常情况：
- 部分Riser卡无法被识别
- 部分Riser卡虽能被识别，但无法加载其上的AI卡
根本原因分析
主要原因
问题的根本原因是 Riser卡EEPROM中的数据被修改，导致硬件自描述信息异常。
根据对异常(PRUR_ERR_CSR.BIN)和正常(PRUR_OK_CSR.BIN)EEPROM数据的对比分析发现：
-
数据修改特征明显：
- 差异点集中在重要数据段
- 不是随机破坏写入，而是有特定模式的写入
- 推测是有特定流程刷写了错误的CSR数据到EEPROM中
-
具体数据差异（通过二进制文件比较得出）：
- 在偏移地址
0x00000011附近：
- 正常文件：
90 01 00 00 A0 01 A1
- 异常文件：
84 02 00 00 00 00 00
- 在偏移地址
0x0000007D附近：
- 正常文件版本信息为
R1.0
- 异常文件版本信息有偏差
影响机制分析
-
Riser卡无法识别的原因：
- EEPROM数据损坏导致无法提供正确的在位信号
- BMC系统基于EEPROM中的Self-Description Record进行硬件自发现
- 由于CpuBoard1 RiserCard1和CpuBoard1 RiserCard2组件的Self-Description Record读取失败（如Document Chunk 1中所示），触发系统告警，最终导致Riser卡加载失败
-
AI卡无法加载的原因：
- EEPROM数据异常导致BIOS无法获取AI卡的带宽信息
- 缺少必要的四元组信息，BMC无法完成PCIe卡建联
- 使用
IdentifyMode配置进行组件识别时出现问题，该模式依赖EEPROM中的配置数据
影响的技术要点
1. EEPROM在天池架构中的关键作用
根据搜索结果[5]《整机PSR配置指导书》，天池架构规范规定：
- 每个组件必须存在I2C总线上地址为0xAE的存储器件（通常为EEPROM）
- 用于存储硬件自描述信息，包括头部、电子标签、组件自描述信息（CSR/PSR）等
- SR的存储载体I2C地址固定为0xAE
2. Riser卡加载流程依赖EEPROM数据
从搜索结果[8]《硬件自发现》可知：
graph TD
A[开始自发现] --> B{EEPROM读取成功?}
B -->|是| C[解析CSR数据]
B -->|否| D[触发Fail事件]
C --> E[生成对象组]
E --> F[发布对象数据]
F --> G[加载下级设备]
3. BMC系统对Riser卡的管理
- Riser卡作为**Field Replaceable Unit (FRU)**进行管理
- 通过
Uid（如00000001040302023942）唯一标识每个Riser卡
- 使用
IdentifyMode参数控制识别策略，模式2对应非天池加载方式
解决方案建议
短期解决方案
-
数据恢复：
- 使用已知正常的CSR数据备份恢复EEPROM内容
- 确保刷写过程中电源稳定，避免中途断电
-
验证方法：
# 检查Riser卡在位状态
ipmitool fru print
# 查看具体Riser卡的EEPROM信息
hexdump -C /sys/bus/i2c/devices/i2c-X/X-0054/eeprom | head -20
长期解决方案
-
排查异常写入来源：
- 检查是否存在装备脚本或其他自动化工具意外修改EEPROM
- 审计所有可能访问EEPROM的软件模块
-
增强EEPROM保护机制：
- 实现写前校验机制
- 添加数据完整性校验（如CRC32）
- 在关键操作前自动备份原始数据
-
改进故障诊断能力：
- 增加EEPROM数据变更日志记录
- 实现EEPROM数据版本追踪
- 开发专用工具用于EEPROM数据比对和验证
验证步骤
- 恢复EEPROM数据后重启系统
- 检查是否报出以下错误：
Failed to access the Self-description Record of CpuBoard1 RiserCardX
- 确认所有Riser卡及AI卡均能正常识别和工作
- 进行多次AC上下电循环测试，验证问题不再重现
结论
本次故障的核心是Riser卡EEPROM数据被异常修改，破坏了硬件自描述机制。建议立即采取措施防止类似事件再次发生，并加强对关键配置数据的保护和监控。
hk1089
(Hk1089)
3
hk1089
(Hk1089)
4
BMC有没有什么流程或者场景，会去主动修改eeprom里面的CSR数据呢？从被修改的段落来看，应该是写入了一个完整的CSR
检查日志后，发现3月11日7点29分升级了名为pre_psr.hpm的CSR文件，8点10分升级了PSR_25.09.03.03.B005.hpm，8点20分升级了PSR_25.09.03.03.B005.hpm。请确认下是否是这几个文件升级到eeprom导致的？
