开机策略设置为保持上电，未生效

交流互助区
1

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

问题描述

image
image413×643 13.4 KB

image
image451×174 11.7 KB

日志如下

null_19700101-0012 (3).tar.gz (6.9 MB)

期望结果

希望得知问题发生原因以及解决方案

2

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

问题概述

在“通电开机策略”已设置为保持上电的前提下，AC 上电后系统未按策略自动上电；这属于通电开机策略不生效类问题。在知识库中，已有对应的故障模式库记录《通电开机策略不生效》，并且存在相关修复 PR（关联 issue：openUBMC/analysis_assets/issues/5），这说明该现象属于已被识别并跟踪的已知问题类型。

可能导致“保持上电”不生效的原因（基于知识库案例）

1. 上电锁（DPU）与 BMC 复位发生竞态（高度相关案例）

参考同类问题（AC 压测过程中，策略为“保持上电”但偶现服务器不上电）的分析结论：

  • AC 上电后，BMC 存在组件未拉起导致复位的情况；
  • framework.log 显示 certificate 组件拉起异常；
  • 未上电的直接过程是：
    1. AC 后按“保持上电”策略，fructrl 向其他组件下发上电通知；
    2. 当前服务器配有 DPU，因此系统添加了上电锁；
    3. 在 DPU OS 启动完成、释放上电锁的时刻，恰好遇到 maca 触发 BMC 复位，导致正式上电没有完成；
    4. BMC 被复位后，fructrl 读到的 rest_type 为 softreset，因此不再走通电开机策略。

也就是说，策略本身配置正确，但上电流程在“释放上电锁与 BMC 复位”这一时序点上被中断。

2. fructrl 缺少必要对象、powerapi 为 nil

另一类相关案例中（OS 上电失败），核心报错为：

mdb_client.lua(241): rpc call PowerCtrl has error BMC.Error.Unknow:
.../fructrl_obj_mgnt.lua:43: attempt to index field 'powerapi' (a nil value)
  • 含义：fructrl 执行上下电控制时访问 powerapi 字段，但该字段为 nil（未加载或未引用成功）；
  • fructrl 要提供上下电功能，必须拥有 FruCtrl、PGSignal、PowerButton、ThermTrip、RecordFault 这些对象，缺少任意一个都会导致功能异常；
  • 日志中还出现 init.lua(79): register to bus for class, error name: kepler.class.ClassNotDefined，说明某类注册时未定义，可能影响 fructrl 相关对象创建，间接导致 powerapi 不可用。

3. 延迟上电配置的影响

若同时定制了延迟上电参数，需要注意：

定制项 说明 取值
BMCSet_PowerRestoreDelayMode 延迟上电模式 DefaultDelay（默认延迟，机架为 0~2 秒随机延迟）、HalfDelay（取延迟时间一半）、FixedDelay（完全按延迟时间）、RandomDelay（0~120 秒随机）
BMCSet_PowerRestoreDelayTime 延迟上电时间 0~1200，单位 100ms
  • 默认值为 DefaultDelay + BMCSet_PowerRestoreDelayTime=0，且默认延迟模式下延迟上电时间无效；
  • 未配置时，系统把延迟模式设为默认模式、延迟时间设为 0；
  • 若配置了较大的延迟时间或随机延迟模式，表现为“上电动作被推迟”，容易被误判为“策略不生效”。

4. AC 闪断信号误触发（表现为上电或下电行为异常）

在另一案例中，power_mgmt 组件在 init 时注册 GPIO 服务，例行扫描 GPIO 管脚，检测到 AC 闪断信号后上报给 fructrl，fructrl 判断为 AC 闪断后即执行通电开机策略。若该管脚状态异常，会造成上下电行为与预期不符。该案例给出的解决方案是：排查 power_mgmt 例行扫描的 GPIO 管脚是否正常。

排查与定位建议

  1. 确认策略配置值本身是否正确

    • BMCSet_POWERRESTOR 取值含义：poweroff=保持下电；poweron 或不配置=保持上电；powerrestore=恢复掉电前状态；其它值返回错误。
    • 如果该项为空，逻辑上会设置为“保持上电”，默认值即为 poweron。

  2. 检查上电锁状态

    • 使用命令 ipmcget -t main -d poweronlock 查询是否处于上电锁定状态；若回显为 locked，说明存在上电超时事件，也会阻止上电命令。

  3. 检查对象分发是否完整

    • 在日志中搜索 create other objects completed，确认 FruCtrl、PGSignal、PowerButton、ThermTrip、RecordFault 对象是否全部创建成功；缺少某个对象时，需检查对应配置或依赖组件是否正常启动。

  4. 确认 fructrl 初始化状态与 powerapi 加载情况

    • 检查 BMC 启动阶段日志中 fructrl 是否有加载失败或初始化报错；
    • 关注 powerapi 是否为 nil、是否存在 kepler.class.ClassNotDefined 之类的类注册错误。

  5. 检查 BMC 侧组件异常与复位

    • 查看 framework.log 是否有组件（如 certificate 组件）拉起异常；
    • 确认 AC 后是否有 BMC 复位记录，以及在复位后 fructrl 读到的 rest_type 是否为 softreset（该值会导致不走通电开机策略）。

  6. 排查 GPIO 与 AC 闪断信号

    • 检查 power_mgmt 例行扫描的 GPIO 管脚是否正常，避免误上报 ACLost 信号。

  7. 核对延迟上电参数

    • 确认 BMCSet_PowerRestoreDelayMode 与 BMCSet_PowerRestoreDelayTime 的实际取值，排除因延迟导致的“未立即上电”。

解决方向

  • 针对已知缺陷：该现象已在故障模式库中登记为《通电开机策略不生效》，建议合入对应修复（issue analysis_assets/issues/5 关联的修改）。
  • 针对 DPU 上电锁竞态：该案例的根因是“释放上电锁”与“BMC 复位”的时序冲突，需避免在 DPU OS 启动完成释放上电锁的关键窗口发生 BMC 复位（即先解决 AC 后组件拉起异常、certificate 组件拉起异常导致的 BMC 复位问题）。
  • 针对 GPIO 误报：排查并修正 power_mgmt 扫描的 GPIO 管脚状态。
  • 若上述仍无法解决：建议将完整的一键日志提供给 FW 团队进一步分析；同时可参考官方文档《Power On/Off FAQ》（https://www.openubmc.cn/docs/zh/development/faq/Power_on_off_FAQ）中关于上下电流程与策略的说明。

说明

你提供的日志文件（null_19700101-0012 (3).tar.gz）内容未在可解析的上下文中呈现，因此以上内容均基于知识库中同类现象的已有分析结论。若需精确定位本次问题的根因，需要依据上述排查项（poweronlock 状态、create other objects completed、powerapi 是否为 nil、rest_type 取值、certificate 组件状态）对实际日志逐项核对。

3

结合日志和fructrl代码分析下看看是不是硬件问题还是软件流程问题