2506版本 BMC重启时，概率出现PSU冗余失败告警

[yizhonghui (长江计算_易重辉)]

问题现象

跑BMC循环重启脚本时，概率出现PSU冗余失败告警

复现方法：
在OS下循环发IPMI命令：

ipmitool mc cold reset

bmc cold reset 656次，出现56次PSU Lost power supply redundancy告警：

初步定位

由告警码0x03000007出发：

检索到事件 PSU.PSURedundancyLost：

定位到事件源 Event_PSURedundancyLost：

"RedundancyFailure"是静态值，数值由代码进行更新

在开源组件power_mgmt中没有此 RedundancyFailure 关键字，推测为闭源组件 power_strategy的实现

诉求

1、 从现象来看应该是问题，社区这边是否已有相同的问题在处理
2、如何从日志的角度分析此问题

如有需要，请留下邮箱，我发一键日志辅助定位

[yizhonghui (长江计算_易重辉)]

持续定位跟进

通过日志文件查到最新的PSU冗余失效的sel事件是：

查询2025-07-21 07:56:45这个时间左右的app.log，并搜索关键字：Redundancy

由上述日志可知：
07:48:11、07:52:28、07:56:19、07:59:49均有Set RedundancyFailure to true的记录，唯有07:56:19这次持续了28秒才设置false，其他的时间点均是6秒内恢复。
推测：因RedundancyFailure设置为true后恢复时间过长才触发事件，恢复时间短不触发事件。
再次回查sel日志：

07:48:11 对应 07:47:53 openUBMC is reset and started.
07:52:28 对应 07:52:23 openUBMC is reset and started.
07:56:19 对应 07:56:14 openUBMC is reset and started.
07:59:49 对应 07:59:45 openUBMC is reset and started.
推测：每次BMC启动都会有Set RedundancyFailure to true/false的过程，且恢复时间变长会触发事件。
回查07:24:15那次的告警是否能印证推测：

07:24:15这次非常特殊，07:24:14设置RedundancyFailure true，07:24:15就直接告警，6s后恢复RedundancyFailure false，07:24:27 告警恢复。
再次回查其他时间点的日志：

可以印证恢复时间为6~20s
查询Set RedundancyFailure to true前后的日志：

发现是先设置了RedundancyFailure to true然后才加载了OnePower，加载完OnePower才RedundancyFailure to false。考虑RedundancyFailure的数值更新时序是否有问题。

小结

每次BMC重启都会有Set RedundancyFailure to true/false的过程，持续时间6~20s，期间如果Event检测到了RedundancyFailure to true，则会告警，否则不会告警，从而有了概率性告警的现象。

诉求

1、每次BMC重启都会有Set RedundancyFailure to true/false的过程是否正常？这涉及到power_strategy组件的energy_metric.lua(187)的代码走读，需要社区支撑。如果正常，考虑为该数值配置防抖；如果不正常，需要进一步解决。

[fumingquan]

app.log日志搜索下alarm_delay_time = ，看下bmc启动的打印是什么

[yizhonghui (长江计算_易重辉)]

无此打印

[wwhh]

alarm_delay_time这行日志是关键日志，用于查看告警推迟时间

从代码实现来看，当前会根据此进行告警延时的判断