AC重启时，概率出现psu信息异常情况

交流互助区
1

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

问题描述

1.2U2P服务器插2个900W电源，一个插电源线，一个不插，具体信息如下：

image
image774×566 15.4 KB

2.对服务器跑AC cycle测试，300圈，每次均对比各个硬件信息

[结果]

有些圈在抓取PSU信息时，信息错误，PSU某些信息如PN号，plug状态，max power capacity信息抓取不到，如下图，左侧为当圈信息，右侧为初始信息

image
image966×455 16.3 KB

这些信息很多都没有获取到

环境信息

  • 软件版本：25.12
2

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

结论

该问题并非硬件故障，而是AC重启过程中因PSU状态信息上报与同步机制延迟所导致的偶发性信息不一致现象。
根本原因在于：psu_info.json更新滞后于AC上电操作，且BIOS未正确等待状态同步完成即生成DMI数据。

:white_check_mark: 建议在自动化测试中延迟PSU信息读取时机，并优先使用Redfish/IPMI等实时接口进行采集，以规避该类问题。
:wrench: 长期建议优化power_mgmt与BIOS之间的状态同步机制，提升系统健壮性。

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

AC重启时PSU信息异常问题分析报告

问题描述

在对2U2P服务器执行AC重启（上电/下电）循环测试（共300次）过程中，系统在获取电源信息时概率性出现PSU信息异常，具体表现为：

  • 部分场次中，通过dmidecode -t 39命令获取的电源信息不完整：
    • 部件编号（Model Part Number）显示为"Unknown"
    • 最大功率容量（Max Power Capacity）显示为0 W（应为900 W）
    • 插入状态（Plugged）全部显示为"No"，与实际情况不符
  • 实际硬件配置：
    • 配置两个900W的电源单元（PSU1和PSU2）
    • PSU1已连接电源线（输入电压221V）
    • PSU2未连接电源线（输入电压0V）
    • 型号为PAC900S12-B3，制造商为HUAWEI

此问题在AC重启过程中非每圈发生，具有偶发性，影响BIOS/OS向DMI表上报PSU信息的准确性。

问题根因分析

结合已有知识库信息，该问题源于系统在AC重启早期阶段读取PSU信息的时机不当，与PSU告警机制延迟及信息同步机制存在时间窗口差异有关。

1. 信息同步机制延迟（核心原因）

  • psu_info.json更新延迟：系统通过OS热重启（OS Hot Restart）机制将最新的电源状态更新到PSUI_info.json文件，并通过IPMI命令上报给BIOS。
  • 更新机制非实时：PSUI_info.json文件的更新存在延迟，并非在电源一上电就立即完成，而是在OS重启流程中由power_mgmt模块完成数据采集与写入。
  • 过早读取导致信息不全：若在AC重启后、PSUI_info.json尚未被完全更新前执行dmidecode命令，则读取到的是旧的、不完整的或默认值填充的信息（如Max Power Capacity = 0 W，Model Part Number = Unknown）。

2. 告警上报与状态判断存在时序差异

  • "AC/DC输入丢失"告警延迟触发：当PSU2因未插电而导致输入缺失时，系统需要先检测该异常，再生成告警（如0x0300000D），这一过程存在处理延迟。
  • 状态同步不同步：BIOS依赖BMC通过IPMI上报的PSU状态来生成DMI数据。在告警尚未生成或状态未同步至BMC前，BIOS可能误判所有电源均正常在位且插入（Plugged: Yes），或均未插入（Plugged: No）。

:magnifying_glass_tilted_left: 知识库佐证：

“如果两个电源一个插线，一个不插线，进行AC重启，在OS下发dmidecode -t 39会发现两个电源都是OK，预期应该是一个OK，另一个Critical。这里分析是The AC/DC input of PSU 2 is lost or out-of-range这个告警生成靠后，没有把信息同步到BIOS。” —— Ref#2,6

关键影响因素总结

因素 说明
AC重启时序敏感 电源上电、BMC初始化、power_mgmt运行、psu_info.json生成、BIOS读取DMI等环节存在精确的依赖顺序和时间窗口。
PSU无VIN_PG信号（潜在因素） 若使用类似华为PAC800D12-B1的电源，其不提供VIN_PG/AC_PRESENT信号，仅依赖SMBAlert报告异常。这会导致CPLD/BMC无法快速判断AC是否真实丢失，进一步加剧误判和信息同步延迟风险。
PSU通信与FRU读取依赖稳定电源 未通电的PSU无法响应PMBus/IPMI命令，导致其FRU信息（如PN号、Power Capacity）读取失败或取默认值。

解决方案建议

:white_check_mark: 推荐方案：调整读取时机，等待系统稳定

不要在AC重启后立即执行dmidecode，建议在以下条件下再进行采集：

  1. 等待至少30~60秒，确保BMC、power_mgmt服务、PSU黑盒信息采集均已完成；
  2. 轮询确认PSU状态稳定，例如通过ipmitool或Redfish API查询PSU状态是否已正确识别（如PSU2状态为"Absent"或"Critical"）；
  3. 确认psu_info.json存在且内容完整（可通过SFTP或shell访问验证）；
  4. 在自动化脚本中引入健康检查逻辑，避免在PSU未就绪时读取。
# 示例：等待PSU信息就绪后再读取
while [ ! -f /var/lib/psu_info.json ] || ! grep -q "Max Power Capacity" /var/lib/psu_info.json; do
    sleep 5
done
dmidecode -t 39

:white_check_mark: 替代方案：使用Redfish/IPMI接口作为可信信源

  • dmidecode依赖BIOS缓存的DMI信息，存在延迟和不一致。
  • 建议直接使用Redfish API或IPMI命令获取实时PSU状态，更准确：
# 使用IPMI读取PSU状态
ipmitool sdr type "Power Supply"
ipmitool fru print 0         # 查看FRU信息
ipmitool dcmi power reading # 获取功耗统计

Redfish路径示例：/redfish/v1/Chassis/1/Power

:warning: 修复建议（长期）：改进同步机制

  • 优化power_mgmt启动优先级：确保其在OS早期阶段运行并尽快完成PSU信息采集；
  • 增强PSUI_info.json写入通知机制：写入完成后主动通知BIOS刷新DMI缓存；
  • 引入状态就绪标志：提供一个API供外部检测PSU信息是否已完整加载。

结论

该问题并非硬件故障，而是AC重启过程中因PSU状态信息上报与同步机制延迟所导致的偶发性信息不一致现象。
根本原因在于：psu_info.json更新滞后于AC上电操作，且BIOS未正确等待状态同步完成即生成DMI数据。

:white_check_mark: 建议在自动化测试中延迟PSU信息读取时机，并优先使用Redfish/IPMI等实时接口进行采集，以规避该类问题。
:wrench: 长期建议优化power_mgmt与BIOS之间的状态同步机制，提升系统健壮性。

参考资料引用：
Ref#2, #3, #6: “AC重启时psu_info.json更新不及时”
KG Entity: OS Hot Restart, PSU Info Json, AC Restart, PAC2000S12-B1, HUAWEI

3

这是通过什么查询的，os侧查询的吗

4

对，os下

5

os信息是怎么获取的，bios通过ipmi获取的吗，只获取一次？

6

是的，os重启时，bios会给BMC发ipmi命令，只上报一次信息，上报一个叫psu_info.json的文件，有时候pmbus还没获取到电源信息，BMC就开始和bios交互，就可能出现这种问题