设备os下电问题排查

交流互助区
1

问题描述

设备运行过程中发现os发生了下电，日志看到pmu状态发生了变化，是否是cpld或acpi上报的os供电状态，是否有日志可以确认os下电原因

wecom-temp-188746-95d030baf0a36a75ca570589576f9704
wecom-temp-188746-95d030baf0a36a75ca570589576f97042532×463 166 KB

环境信息

  • 软件版本：OpenUBMC2506
2

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

:white_check_mark: 七、结论与建议

:check_mark: 最终结论：

  • pmu status change to 0 是由主机侧硬件模块（如CPLD或IMU）上报的OS电源状态变化信号，BMC通过 mctp_mdb_mgmt.lua 捕获并记录。
  • 该信号不是ACPI直接上报，而是底层硬件依据ACPI状态或电源监控结果生成的数字信号。
  • 不能仅凭此日志断定是异常故障，需结合：
    • 是否有BMC下发指令
    • 是否有AC事件
    • 是否伴随BMC重启
    • 是否存在OS内核错误

:hammer_and_wrench: 建议后续动作：

  1. 完整收集日志包（含 app.log, framework.log, dmesg, sel 等）
  2. 定位 pmu status change to 0 的时间点前后1分钟内的所有相关日志
  3. 确认是否有“操作日志”或“远程命令”
  4. 检查CPLD/BMC/BIOS版本配套性
  5. 升级至最新稳定版OpenUBMC（≥2509）以修复已知电源管理Bug
点击此处查看详细分析解答

设备OS下电问题排查分析

根据您提供的日志信息和环境背景，以下是对设备运行过程中OS发生下电问题的系统性排查与分析。

:magnifying_glass_tilted_left: 一、问题描述总结

  • 现象：设备在运行过程中发现操作系统（OS）无故下电。
  • 日志线索：在 app.log 中观察到 pmu status change to 0, OS Power OFF，表明OS电源状态变为关闭。
  • 疑问点：
    1. 此PMU状态变化是否由CPLD或ACPI上报？
    2. 是否有日志可以进一步确认OS下电的根本原因？

:puzzle_piece: 二、关键机制说明：PMU状态变更的来源与含义

:white_check_mark: 1. PMU状态变化由哪一方触发？

根据知识库信息：

  • Pmu_status Change to 1：由 mctpd 模块检测并记录，表示 OS Power ON。
  • pmu status change to 0：同理表示 OS Power OFF。
  • OS Power ON/OFF 是通过监控 PMU（电源管理单元）硬件信号 或 SMBIOS 状态变更 来判断的。

关键脚本：mctp_mdb_mgmt.lua

  • 该脚本运行在BMC侧，负责监听和解析来自前端系统（如CPU/IMU/CPLD）的电源状态信号。
  • 其日志条目：
    mctpd NOTICE: mctp_mdb_mgmt.lua(242): mctp_mdb_mgmt: pmu status change to 0, OS Power OFF
    表明：PMU状态是通过MCTP协议从主机侧（通常是IMU或CPLD）传递到BMC的。

:small_blue_diamond: 结论：

  • PMU状态变化由主机侧（例如IMU、CPLD）上报给BMC，并非直接由ACPI上报。
  • ACPI状态虽可用于辅助判断系统运行状态，但OS上下电主信号来源于PMU硬件信号，通常由CPLD或SoC生成。
  • 因此，pmu status change to 0 极大概率是由CPLD或IMU上报的硬件级电源信号变化引发的。

:white_check_mark: 2. 谁处理 PMU 状态变更？

  • mctpd 是 Baseboard Management Controller (BMC) 中的核心服务，用于管理 MCTP（Management Component Transport Protocol）通信。
  • 它会监听两个关键信号判断上电事件：
    1. PMU Status
    2. SMBIOS Status

≥ 任一信号变为“1”即认为 OS已上电。

反向推导：当 pmu status change to 0 时，表示系统检测到OS关机信号，并不一定意味着人为执行了关机命令，可能是异常掉电。

:books: 三、如何定位OS下电的真实原因？

尽管 mctp_mdb_mgmt.lua 记录了状态变更，但它只是“通知者”，不是“决策者”。要定位根本原因，需结合其他模块日志进行交叉分析。

:magnifying_glass_tilted_right: 排查步骤与建议

步骤1：确认是否为AC掉电（整机断电）

:warning: 关键区别：

  • OS Power OFF（PMU=0）：操作系统关闭，但系统可能仍有DC供电。
  • AC掉电：整机完全断电，包括BMC辅助电源。

判断方法：

  • 查看日志中是否有 AC下电事件 触发记录。
  • 若存在以下行为：系统所有活动文件被删除、BMC重启、日志中断写入 → 则为AC掉电。

:white_check_mark: 推论：

  • 如果只有 pmu status change to 0 而无BMC重启，说明是OS级关机，非整机掉电。
  • 若伴随BMC重启或日志丢失 → 倾向于 AC掉电（整机断电）。

步骤2：检查 bmc_soc 模块是否检测到异常复位

  • bmc_soc 组件负责检测整个SOC系统的状态，包括：
    • OS Reset
    • Power-off
    • 异常重启

相关实体：OS reset or power-off is detected → 由 soc_mgmt.lua 检测并记录。

排查建议：
在 app.log 中搜索以下关键词：

"OS reset" 
"power-off detected"
"bmc_soc"
"serial_mgmt.lua"

若发现如下日志：

bmc_soc ERROR: serial_mgmt.lua(268): serial_remote.obj is invalid or system_id is not exist, system_id: 1

说明系统在运行中失去连接，可能是异常崩溃或强制断电所致。

步骤3：检查是否触发了 CPLD 主动下电逻辑

  • CPLD 控制着物理层面的电源按钮信号和电源控制逻辑。
  • 下电可通过两种方式：
    1. 短按信号（Soft Power Off）
    2. 长按信号（Force Power Off）

排查建议：
在日志中搜索以下关键字：

"Notify cpld to send short button signal"
"Notify cpld to send long button signal"
"hwproxy Accessor"
"Power off timeout"
  • 若出现上述日志 → 表示BMC向CPLD发送了下电指令。
  • 若无此日志，但PMU状态变为0 → 说明下电指令未经过BMC，可能是：
  • 外部强制断电
  • CPLD自身保护机制触发（如过温、过流）

步骤4：检查是否有 ACPI 异常唤醒/关机事件

虽然PMU信号是主要判断依据，ACPI 也提供软件层状态反馈。

可在系统日志（OS侧）中检查：

dmesg | grep -i "acpi"
journalctl | grep "Shutting down"

:small_orange_diamond: 常见ACPI关机原因：

  • 用户执行 shutdown 命令
  • 内核OOM（内存溢出）自动关机
  • BIOS/ACPI固件Bug导致误报S5状态
  • 温度过高触发Thermal Shutdown

步骤5：排查是否由 固件升级、CPLD更新或BMC操作导致

查阅操作日志或搜索：

"Firmware_Mgmt"
"CPLD Upgrade"
"PowerCycle"

特别注意：

  • 如果CPLD升级策略配置为 SUPPORT_AC_RESET_ACTIVE，则升级后会触发AC重启。
  • 若此时OS正在运行 → 会被强制中断。

:detective: 四、综合分析：可能的根本原因

可能原因 支持证据 排查方式
1. 外部AC掉电（整机断电） pmu status change to 0 后BMC重启或日志中断 检查BMC是否重启、是否存在 AC下电事件
2. CPLD主动断电（保护机制） 无BMC下电指令，但PMU变0 检查是否有过温/过流告警，查看CPLD日志
3. IMU异常上报PMU状态 频繁误报PMU change to 0/1 分析多个时间点日志，看是否抖动
4. OS内核崩溃导致软关机 无BMC指令，无AC事件 检查OS dmesg 和 kern.log
5. 人为/远程下发关机命令 存在 powerapi 调用记录 搜索 powerapi 函数调用路径

:white_check_mark: 五、推荐排查命令与日志关键词汇总

目标 推荐命令或搜索关键字
查看PMU状态变更 grep "pmu status change" app.log
查看是否由BMC发起下电 grep "powerapi" app.log
查看CPLD是否收到下电指令 grep "Notify cpld to send" app.log
检查是否有上电锁 ipmcget -t main -d poweronlock
检查固件升级是否影响 grep "Firmware_Mgmt" app.log
检查AC掉电导致日志丢失 grep "syslog" *.log，关注落盘情况
检查bmc_soc异常 grep "bmc_soc" app.log

:pushpin: 六、参考案例与历史问题

【历史问题一】AC后日志文件丢失

  • 根因：syslog日志缓存未及时落盘，AC掉电导致日志丢失。
  • 解决建议：确保重大操作前日志刷盘。

【历史问题二】异常掉电但无操作记录

  • 根因：早期板卡存在“5小时BUG”或CPLD电源控制逻辑缺陷。
  • 解决建议：确认CPU/CPLD固件是否为最新版本。

【历史问题三】CPLD升级生效方式为AC

  • 升级后自动AC重启 → 导致业务中断。
  • 解决方案：支持DC生效模式（需硬件支持）。

:white_check_mark: 七、结论与建议

:check_mark: 最终结论：

  • pmu status change to 0 是由主机侧硬件模块（如CPLD或IMU）上报的OS电源状态变化信号，BMC通过 mctp_mdb_mgmt.lua 捕获并记录。
  • 该信号不是ACPI直接上报，而是底层硬件依据ACPI状态或电源监控结果生成的数字信号。
  • 不能仅凭此日志断定是异常故障，需结合：
    • 是否有BMC下发指令
    • 是否有AC事件
    • 是否伴随BMC重启
    • 是否存在OS内核错误

:hammer_and_wrench: 建议后续动作：

  1. 完整收集日志包（含 app.log, framework.log, dmesg, sel 等）
  2. 定位 pmu status change to 0 的时间点前后1分钟内的所有相关日志
  3. 确认是否有“操作日志”或“远程命令”
  4. 检查CPLD/BMC/BIOS版本配套性
  5. 升级至最新稳定版OpenUBMC（≥2509）以修复已知电源管理Bug

如能提供更完整的前后时间段日志，可进一步精准定位是软件关机、硬件异常、还是外部断电。