PSU 信息同步延迟问题分析与解决方案

问题描述

在 AC 服务器中，当一个 PSU 插线而另一个未插线时执行 AC 操作，使用 dmidecode -t 39 命令查看电源状态，发现两个电源均显示为 “OK”（正常），但预期结果应为一个电源正常（OK），另一个因无输入电源而处于关键状态（Critical）。该问题的根本原因是 The AC/DC input of PSU 2 is lost or out-of-range (0x0300000D) 告警生成时间较晚，未能及时将 PSU 状态同步至 BIOS 和 psu_info.json 文件。

此现象导致 OS 在热重启前获取的电源状态不准确，从而上报错误信息给 BIOS。

根本原因分析

1. 告警生成延迟

根据知识库信息：

• 事件代码 0x0300000D 对应告警 “The AC/DC input of PSU 2 is lost or out-of-range”。
• 此告警依赖于 BMC 监控 GPIO 中断信号并完成 AC 丢失状态处理流程。
• 日志中多次出现重复的 Get AC lost signal 和 Process AC lost complete 记录（如文档 chunk 3 所示），表明系统需要一定时间检测和确认 AC 掉电事件，在此之前无法生成准确告警。

示例日志：

power_mgmt NOTICE: log_service.lua(235): Get AC lost signal
power_mgmt NOTICE: log_service.lua(241): Process AC lost complete

这意味着告警的生成具有时间滞后性，无法在 AC 断开后立即通知上层系统。

2. 信息同步链条断裂

告警 → SEL 日志 → psu_info.json → BIOS 的同步流程

阶段	状态	说明
PSU 输入异常	发生	PSU2 无输入电压
BMC 检测异常	延迟	需等待 GPIO 中断处理完成
生成 SEL 告警 (0x0300000D)	延迟	同步依赖于 power_mgmt 组件处理流程
更新 psu_info.json	失败或延迟	未及时捕获最新状态
OS 使用 dmidecode 读取	错误输出	获取的是旧状态，两个 PSU 都显示 OK

知识库明确指出：

“整机功耗值由所有电源输出功耗总和，但若存在某个电源不健康（未接线），则整机功耗值计算不进行对应刷新。”

这说明：当 PSU 状态不健康时，系统可能跳过其状态更新逻辑，导致状态同步失效。

3. 热重启虽可触发更新，但前提条件不满足

虽然 OS 热重启时可通过 dmidecode -t 39 获取最新状态，但前提是：

• BMC 已经完成对电源状态的采样；
• psu_info.json 文件已被正确更新；
• DMI 表已反映最新 PSU 状态。

如果热重启发生在告警生成之前或中间过程，则仍会读取到错误的状态。

解决方案建议

方案一：确保 BMC 状态先于 OS 启动前完成更新（推荐）

核心思路：延迟 OS 启动，确保 BMC 完成电源状态检测与告警生成后再加载 OS。

实现方式：

1. 启用 AC Cycle 后 BMC 延时启动机制：

   • 配置 BMC 在 AC 恢复后延迟 5~10 秒启动 power_mgmt 服务。
   • 使用 ACCycle 类（见 CSR 配置文档）控制 AC 重启时序。

2. 利用 SetRestorePolicy 设置合适的上电策略：

   ipmitool chassis policy always  # 确保 AC 恢复后自动上电
   

3. 在 BMC 初始化脚本中插入等待逻辑：

   # 在启动 OS 前等待 AC 状态处理完成
   sleep 8
   # 触发 psu_info.json 更新
   /usr/bin/update_psu_status.sh
   

方案二：主动触发电源状态刷新（强制同步）

通过 IPMI 命令强制同步 PSU 状态

使用以下命令主动查询并刷新 PSU 状态：

# 获取 AC 掉电状态
ipmitool raw 0x04 0x27

# 触发手动重新扫描 PSU 状态
ipmitool dcmi get_psu_capabilities

编写 BMC 脚本定期刷新 psu_info.json

-- 示例：在 power_mgmt 组件中添加
if GetACLostStatus() == 1 then
    UpdatePSUStatus("PSU2", "Critical")
    SyncToDMI() -- 强制同步到 DMI
end

参考：GetACLostStatus 是标准 IPMI 命令，用于获取上次 AC 掉电状态。

方案三：修改电源监控策略，提前生成告警

优化 power_mgmt 组件行为

• 缩短 log_service.lua 中 Process AC lost complete 的处理周期；
• 减少重复日志频率，提升事件响应速度；
• 在检测到 Input Voltage = 0 V 时立即标记 PSU 为非健康状态。

修改建议：

# config: power_monitor_start 周期
- interval: 5000ms
+ interval: 1000ms

参考文档 chunk 4 提到：“该版本存在电源拔插问题，最新版本已经修复”，说明可通过升级 power_mgmt/1.70.162@openubmc 组件解决此类问题。

方案四：通过 CSR 配置增强信号检测及时性

配置 PGSignal 对象，实时监测 Power Good 状态变化

"PGSignal_1": {
  "PowerGDState": "<=/Scanner_PowerGd.Value"
}

结合日志中的 PowerGDStatus changed to power on 信息，可通过监听此信号在系统上电初期即判断 PSU 是否有效工作。

配置 ACCycle 对象触发同步动作

"ACCycle_1": {
  "AC": "#/Accessor_AC.Value"
}

在 AC 事件发生后，自动触发 PSU 状态重检和同步流程。

最佳实践总结

措施	描述
升级 power_mgmt 组件	使用最新版本（>1.70.162），修复已知的插拔检测延迟问题
引入 BMC 启动延迟	AC 恢复后延迟 OS 启动，等待电源状态稳定
强制刷新机制	在 OS 启动前调用脚本主动更新 psu_info.json
缩短监控周期	将 PSU 电压/电流轮询间隔从 5s 改为 1s，加快异常发现
绑定 DMI 更新到 SEL 事件	当 0x0300000D 告警 Assert 时，强制触发 DMI 表更新

附加建议：验证方法

1. 检查 SEL 日志确认告警时间戳

   ipmitool sel list | grep "0x0300000D"
   

   确认告警是否在 AC 操作后 3~5 秒内生成。

2. 查看 psu_info.json 更新时间

   stat /var/lib/bmc/psu_info.json
   

   比对与 SEL 告警时间差。

3. 使用 IPMICFG 工具查看 PSU 实时状态

   ipmicfg -wdt info
   

4. 抓取 BMC 日志验证流程

   journalctl -u power_mgmt.service
   

   查看 Process AC lost complete 是否成功执行。

结论

当前问题根源在于 告警生成延迟 + 状态同步机制不足，导致 psu_info.json 更新不及时，进而使 dmidecode -t 39 查看的信息失真。

推荐解决方案组合：

1. 升级 power_mgmt 到最新版，修复插拔检测问题；
2. 在 BMC 启动脚本中加入延迟 + 强制刷新；
3. 通过 CSR 配置 PGSignal 和 ACCycle 实现事件联动；
4. 建立自动化测试验证机制，确保类似问题不再复发。

关键提示：BIOS 层依赖 BMC 提供的状态信息，必须确保 BMC 在 OS 启动前已完成完整电源健康检查。否则，无论 OS 如何重启，都可能读取到错误状态。

相关链接：

1. 【电源异常告警】频繁产生电源AClost事件（0x0300001F）
2. 电源在位，不插电源线，拔插电源未重新生成输入告警
3. web当前整机功耗显示为0
4. X20 AC 测试过程中 产生core dump 导致bmc 重启
5. power_mgmt | 文档中心 | openUBMC