AC重启，PMU状态异常，导致vrd信息未获取

[baominmin (kunlun_Baominmin)]

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

问题描述

PMU状态异常，导致vrd信息未获取

环境信息

• 软件版本： OpenUBMC LTS SP1

PmuKunLun2480V2_2102315GCE10R9100001_20260321-0156.part2.rar.txt (2.9 MB)
PmuKunLun2480V2_2102315GCE10R9100001_20260321-0156.part1.rar.txt (9 MB)

[ubmc_assistant (openUBMC_Assistant)]

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

结论与建议行动项

动作	描述
短期应对	在compute服务中增加对.Status == 1的等待逻辑，避免过早访问PMU。
中期改进	实现重试机制 + 超时告警，提升鲁棒性。
长期保障	验证PMU固件与OpenUBMC LTS SP1的兼容性，必要时联系PAE获取官方认证版本。
提交日志	若问题持续存在，请将完整app.log、journalctl日志提交至 OpenUBMC社区论坛 进一步分析。

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

PMU状态异常导致VRD信息未获取问题分析与解决方案

根据您提供的信息，系统在进行AC重启后，PMU（Power Management Unit）状态异常，导致VRD（Voltage Regulator Downstream）信息无法正常获取。以下将从问题现象、根因分析、排查步骤以及解决方案等方面进行详细阐述。

---

问题描述

• 环境信息：

  • 软件版本：OpenUBMC LTS SP1
  • PMU固件包：
    • PmuKunLun2480V2_2102315GCE10R9100001_20260321-0156.part1.rar.txt（9 MB）
    • PmuKunLun2480V2_2102315GCE10R9100001_20260321-0156.part2.rar.txt（2.9 MB）

• 关键日志：

  2026-03-20 16:54:53.260964 compute NOTICE: pmu_object.lua(207): update pmu status of system 1 to 0  
  2026-03-20 16:54:56.276016 compute NOTICE: pmu_object.lua(207): update pmu status of system 1 to 1
  

  表明：PMU状态在短时间内由 0（异常/未就绪） 变为 1（正常/就绪）。

• D-Bus对象状态（通过busctl查看）：

  .Status     value: 0
  .PmuVersion value: ""
  

  • Status = 0：表示PMU当前状态为不可用或初始化失败。
  • PmuVersion = ""：表明PMU版本信息未成功读取，进一步验证通信未建立。

• 最终影响：
  VRD相关信息无法从MCU/PMU获取，导致电压调节模块监控缺失，存在电源管理风险。

---

根因分析

核心问题：AC重启后PMU初始化延迟或失败

1. PMU状态机初始化滞后

   • AC上电后，PMU需要一定时间完成自检与固件加载。
   • 日志中显示状态从 0 → 1，说明其经历了从初始化失败或未完成状态恢复为正常的过程。
   • 在此窗口期内，BMC尝试读取VRD信息时，PMU尚未准备好，导致数据获取失败。

2. BMC未等待PMU就绪即发起查询

   • BMC子系统（如compute服务）可能在系统启动早期即调用pmu_object.lua中的接口来获取设备信息（例如VRD版本、四元组等）。
   • 若此时PMU尚未上报status=1，会导致CustomReadInfo类方法返回空或无效数据。

3. PMU版本获取依赖通信链路稳定

   • VRD信息通常通过I²C/SMBus由BMC → MCU → VRD芯片读取，而该路径依赖于PMU作为中间管理单元的状态正确性。
   • 当PMU未激活时，链路中断，导致后续命令超时或响应异常。

4. 固件兼容性或配置问题（潜在）

   • 所使用的PMU固件（PmuKunLun2480V2_...）是否与当前OpenUBMC版本完全适配？
   • 特别是在openUBMC LTS SP1环境下，若PMU驱动未对新硬件特性做适配，可能导致初始化异常。

---

排查建议与验证步骤

步骤1：确认PMU状态变化时机与服务启动顺序

# 查看系统启动时间线，确认PMU状态变为1的时间点
journalctl -u compute | grep "update pmu status"

# 检查compute服务启动时间
systemctl status compute

预期结果：compute服务应在pmu status == 1之后再执行VRD信息采集逻辑。

步骤2：检查PMU D-Bus属性是否已更新

# 实时监控PMU对象状态
busctl monitor bmc.kepler.Systems.Pmu

# 或轮询查看状态
while true; do
  busctl get-property bmc.kepler.Systems.Pmu /bmc/kepler/Systems/1/Pmu bmc.kepler.Systems.Pmu Status
  sleep 1
done

若.Status长期为0，则需深入排查PMU固件或硬件通信问题。

步骤3：手动触发VRD信息读取（测试通信）

-- 通过Lua调试环境调用底层接口（测试使用）
local pmu = require("pmu_service")
pmu.check_uptree(1)  -- system_id=1

观察是否有错误码返回，如：

• 25, 75, 88：常见于MCU通信异常（参考知识库中VRD升级失败案例）
• INTERNAL_ERROR：表明底层I²C通信失败或MCU无响应

步骤4：检查I²C通信状态

# 列出I²C总线设备
i2cdetect -l

# 探测指定总线上的设备（例如8号总线）
i2cdetect -y 8

确认MCU/PMU对应地址是否存在且可访问。

---

解决方案建议

方案1：【推荐】增加PMU状态等待机制（软件层修复）

修改compute服务中采集VRD信息的逻辑，加入对PMU状态的轮询等待与超时控制：

function wait_for_pmu_ready(system_id, timeout_sec)
    local start_time = os.time()
    while os.time() - start_time < timeout_sec do
        local status = get_pmu_status(system_id)  -- D-Bus读取.Status
        if status == 1 then
            return true
        end
        log:info("PMU not ready, retrying...")
        os.execute("sleep 1")
    end
    return false
end

-- 使用示例
if wait_for_pmu_ready(1, 30) then
    read_vrd_info()  -- 安全执行
else
    log:error("PMU failed to become ready within timeout")
end

适用场景：适用于启动阶段因时序错配导致的信息丢失。

---

方案2：启用主动重试机制

对于关键信息读取（如VRD版本、PCIe四元组），实现指数退避重试逻辑：

local max_retries = 5
for i = 1, max_retries do
    local result = read_vrd_version()
    if result then
        break
    else
        log:warn("Failed to read VRD version, attempt " .. i)
        os.execute("sleep " .. (i * 2))
    end
end

---

方案3：更新PMU固件并验证完整性

• 确保使用的两个分卷文件正确解压合并，并通过校验和验证。
• 使用以下命令刷写PMU固件（需确认接口支持）：

# 示例（具体命令依平台而定）
update_firmware --target PMU --file PmuKunLun2480V2_*.bin

建议在升级后执行AC重启，观察日志是否仍有status=0短暂出现。

---

方案4：添加告警通知机制

当PMU状态异常持续超过阈值时（如>30秒），触发告警：

[ALERT] PMU status remains 0 for more than 30s after AC power-on, possible communication failure.

可通过Redfish或SEL记录事件，便于运维人员及时发现。

---

参考知识库信息支持

实体	支持内容
PMU	是BMC获取PCIe设备四元组（Vendor ID, Device ID等）的关键中介，且负责电源状态上报。
CustomReadInfo	存在返回无效数据的风险，特别是在硬件未就绪时。
mcu_enums.SMC_CALL_STATUS_CODE	定义了MCU通信常见错误码（如INTERNAL_ERROR=2），可用于诊断链路异常。
ipmitool mc info	可用于验证BMC整体可用性与固件状态，辅助判断是局部还是全局故障。

---

结论与建议行动项

动作	描述
短期应对	在compute服务中增加对.Status == 1的等待逻辑，避免过早访问PMU。
中期改进	实现重试机制 + 超时告警，提升鲁棒性。
长期保障	验证PMU固件与OpenUBMC LTS SP1的兼容性，必要时联系PAE获取官方认证版本。
提交日志	若问题持续存在，请将完整app.log、journalctl日志提交至 OpenUBMC社区论坛 进一步分析。

---

如有更多日志片段或拓扑信息（如MCU位置、I²C地址），可进一步精准定位通信路径问题。

[Longbow (ZhangZhiyang)]

cli界面发送这个命令试一下
busctl --user call bmc.kepler.ipmi_core /bmc/kepler/IpmiCore Request a{ss}yyyyyay 010 0x06 0x00 0x01 4 0xdb 0x07 0x00 0x00

[baominmin (kunlun_Baominmin)]

[baominmin (kunlun_Baominmin)]