冷重启多次测试后，nvme盘的BMC信息磨​损率丢失

交流互助区
1

【问题描述】

1、 服务器正常上电
2、BMC版本为OpenUBMC25.06，执行整机冷重启测试
3、测试后查看nvme盘的BMC信息，所有硬盘磨损率信息丢失

image
image1644×560 27.5 KB

【日志】
查看相关日志有Nvme对象创建失败信息打印

企业微信截图_17587704896179

【环境信息】

  • 主板：S920X21
  • CPU：HUAWEI Kunpeng 920 7272C
  • 测试盘：三星PM9D3a
  • OS：Tlinux3.1
2

mdbctl看下对应Scanner_Remtime的Value值是多少

3

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

问题分析

根据您提供的信息，在执行多次整机冷重启测试后，OpenUBMC系统中NVMe硬盘的磨损率信息丢失，且日志中出现“Nvme对象创建失败”的提示。此问题涉及NVMe盘管理、BMC系统初始化流程以及硬件状态持久化机制。

结合知识库中的信息，该问题可能由以下原因导致：

  1. NVMe设备初始化失败或延迟：在BMC启动过程中，若NVMe设备未能及时响应或初始化超时，可能导致NVMe相关对象（如NVMe.Smart）无法正确创建。知识库中的文档《V3 上适配nvme盘个人总结》提到，NVMe温度和固件版本获取失败曾因CPLD通信链路问题导致，说明NVMe设备的状态读取依赖于稳定的硬件通信路径。冷重启可能加剧了初始化时序问题。

  2. 对象加载依赖未满足：NVMe对象的加载依赖于Connector_ComVPDConnect和BusinessConnector等前置组件。若在冷重启过程中这些依赖组件加载顺序异常或失败，会导致NVMe对象创建失败。知识库中提到：“BMC首先会加载NVMe背板的Connector，命名上会包含背板的UID”，若此步骤失败，后续的14140244_VPD_0.sr等配置文件无法正确加载，进而影响磨损率等属性的读取。

  3. 防抖机制或状态缓存问题：OpenUBMC对硬件状态监控使用了多种防抖机制（如contbin_H5L30用于NVMe预故障检测）。冷重启可能导致状态监控逻辑误判，或将未完成初始化的NVMe设备标记为“无效”，从而跳过磨损率信息采集。此外，若PowerOnHours或UsedPercentage等属性未正确持久化，重启后可能无法恢复。

  4. 驱动或协议适配问题：三星PM9D3a作为测试盘，其NVMe-MI（Management Interface）协议实现可能与OpenUBMC的bmc.dev.NVMe.NVMeMI接口存在兼容性问题。知识库中《【已评审】新增获取硬盘NVMe-MI标准协议信息资源协作接口》提到，需通过GetSmartInfo等方法获取SMART信息，若该接口在冷重启后未能正确调用或返回空值，将导致磨损率丢失。

解决建议

  1. 检查NVMe初始化日志：

    • 查看/var/log/ibma.log或storage组件日志，确认是否有NVME resource初始化失败、I2C通信超时或Chip_SSD_xxx访问失败的记录。
    • 重点关注冷重启后首次启动的日志，确认LibAdapter.py是否成功触发NVME resource的更新事件。

  2. 验证硬件通信链路：

    • 确认NVMe背板CPLD固件为最新版本，避免因CPLD通信异常导致SSD芯片（如SSDChip）访问失败。
    • 使用mdbctl命令手动查询NVMe设备的SMART信息，验证是否能正常读取AvailableSpare、PercentageDriveLifeUsed等属性。

  3. 检查配置文件加载：

    • 确认14140224_VPD_0.sr和14140224_PROTOCOL_0.sr等SR文件是否正确加载。
    • 检查Drive类配置中SSDChip和VPDChip的引用对象是否正确指向实际硬件。

  4. 调整防抖参数或初始化超时时间：

    • 若确定为时序问题，可尝试调整storage组件中NVMe设备的初始化超时时间，或在contbin_H5L30等防抖机制中增加容忍次数，避免因短暂通信延迟导致状态丢失。

  5. 联系社区或硬件供应商：

    • 若问题持续存在，建议在discuss.openubmc.cn提交详细日志，并引用类似案例（如适配大普盘时的通信失败问题），寻求社区或华为工程师支持。

总结

该问题极可能是由于冷重启过程中NVMe设备初始化失败或通信链路不稳定，导致BMC未能成功创建NVMe对象，进而无法获取磨损率信息。建议从日志分析、硬件通信、配置加载和防抖机制四个方面进行排查，优先验证mdbctl能否手动读取SMART信息，以定位是驱动层还是硬件层的问题。