更新到25.12后bmc一直重启的问题

交流互助区
1

问题描述

更新到25.12版的bmc后，网页和ssh都无法登录，网络也ping不通，通过串口可以看到bmc一直在重启且一直报组件的call trace错误

image
image1920×947 89.2 KB

完整重启log如下：
25.12error.txt (1.0 MB)

重现步骤

之前一直用的2506版的bmc，后来更新了最新的环境（conan和bmc_sdk）并且拉了最新的manifest，编译出的hpm包直接在网页上进行了更新。

请问为什么会出现这种现象？

2

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

更新到25.12后BMC持续重启问题分析与解决方案

根据您提供的问题描述和日志信息，系统在从 OpenUBMC 25.06 升级至 25.12 版本后出现 BMC 持续重启、无法访问 Web 与 SSH、网络不通 的现象，且串口日志显示反复打印 Call trace 错误，表明系统内核级组件存在异常，导致无法正常启动。

:magnifying_glass_tilted_left: 问题现象总结

  • 升级方式：通过 Web 界面上传并安装 25.12 版本的 HPM 固件包。
  • 升级后现象：
    • BMC 持续重启，无法进入正常运行状态。
    • Web 界面无法访问，SSH 无法登录，网络无法 ping 通。
    • 串口日志频繁输出 Call trace 堆栈信息，涉及 idle_cpu, load_balance, gpio_isr_start, btc_probe 等模块。
  • 日志关键线索：
    [ 264.923029] Call trace:
idle_cpu+0x20/0x4c
load_balance+0x16c/0xd28
...
gpio_isr_start+0xdc/0xfc [gpio_drv]
btc_probe+0x1c/0x25c [btc_drv]
platform_drv_probe+0x6c/0xe8
    表明在内核驱动加载阶段（特别是 btc_drv、gpio_drv）出现异常，可能引发崩溃并触发自动重启。

:puzzle_piece: 问题可能原因分析

1. 驱动或内核不兼容（核心原因）

  • btc_probe 和 gpio_isr_start 出现在调用栈顶层，说明 BTC（Baseboard Management Controller to Host Communication）驱动 在初始化时触发了异常。
  • 从 25.06 升级到 25.12，底层内核、驱动或硬件抽象层可能发生不兼容变更。
  • 日志中 Call trace 循环频繁出现，说明系统在启动过程中执行到驱动加载即崩溃，形成“无限重启循环”。

2. 固件编译环境不一致

  • 您提到“更新了最新的 conan 和 bmc_sdk 并拉了最新的 manifest”：
    • Conan 包版本不一致 可能导致构建依赖的库（如 bmc_soc, libproto-mc4c）与目标运行环境不匹配。
    • bmc_sdk 版本（如 bmc_sdk_latest 指向 conan.openubmc.cn）若未按工程版本锁定，可能导致编译出的 HPM 包包含非预期组件。

3. HPM 固件包完整性或签名问题

  • 社区版本固件偶尔因 签名密钥不匹配 或 解密失败 导致升级后运行异常。
  • 如知识库所示，曾有“升级密钥解密失败”的问题（见文档 1），虽在 v1.0.30+ 修复，但 25.12 若未集成该修复，仍可能受影响。

4. 硬件初始化时序或资源冲突

  • load_balance 和 idle_cpu 异常出现在调度器层面，结合 gpio 中断处理失败，可能反映 硬件资源冲突或 GPIO 配置错误，尤其是在新版本中硬件适配策略变更时。

:white_check_mark: 解决方案建议

:white_check_mark: 方案一：使用 ipmcset -d rollback 回退固件（推荐优先尝试）

您已在文档 1 中尝试过回退，但 SSH 仍无法登录。请按以下步骤操作：

1. 通过 串口登录 执行回退命令：

ipmcset -d rollback

此命令将 BMC 固件恢复至上一可用版本（即 25.06），适用于当前 25.12 启动失败场景。

2. 若 ipmcset 命令无效或命令未找到：

  • 检查是否因 bmc_core 服务未启动导致命令缺失。
  • 查看 /etc/version 确认当前实际运行版本。
  • 强制触发回退：断电后按住 BMC 恢复按钮（如有）再上电，进入恢复模式。

:white_check_mark: 方案二：重新刷写 25.06 可靠版本固件

若回退失败，建议通过 串口 + HPM 重新烧录：

步骤：

  1. 准备一个已验证的 25.06 正式版 HPM 包。
  2. 通过串口登录系统（若当前系统能短暂启动）。
  3. 使用命令上传并升级：
    ipmcset -t image -d upload -v /tmp/firmware_25.06.hpm
ipmcset -t image -d activate -v /tmp/firmware_25.06.hpm
  4. 系统将重启并应用旧版固件。

:warning: 注意：确保 HPM 包与硬件型号、SDK 版本严格匹配。

:white_check_mark: 方案三：检查并修复驱动或配置问题（适用于开发者）

若您有开发权限，可尝试定位根本原因：

1. 禁用 btc_drv 模块测试是否为根本原因

  • 在构建时临时移除 btc_drv 模块，或在内核启动参数中添加 modprobe.blacklist=btc_drv。
  • 观察是否仍出现 Call trace。

2. 检查 config.cfg 或设备树配置

  • 确保 MODULE_NAME 设置正确（参考 FXX 建议）。
  • 检查 platform_drv_probe 所依赖的硬件资源是否定义正确。

3. 更新至修复版本

  • 如知识库中提到，某些问题已在新版本中修复（如 IPMI trace 文件、核心崩溃等）。
  • 建议升级至 25.09 或更高版本（如 openUBMC 25.09 支持自恢复机制）。

:hammer_and_wrench: 预防建议

建议项 说明
升级前备份配置 使用 WebUI 或 CLI 导出当前配置，避免回退后丢失。
使用稳定版 SDK 避免直接使用 latest 分支，应锁定 bmc_sdk 到 25.06 对应版本。
验证 HPM 包完整性 构建后使用 ipmcget -d v 检查版本信息是否正确。
分阶段升级测试 在开发板或非生产环境验证 25.12 稳定性后再部署。
避免跨版本跳跃升级 建议先升级至中间版本（如 25.09），逐步过渡。

:books: 参考资料

:white_check_mark: 总结

当前问题极可能是 25.12 版本中 btc_drv 或 gpio_drv 驱动与硬件或内核不兼容 所致，导致系统在启动过程中崩溃并不断重启。

推荐处理流程：

  1. 立即执行 ipmcset -d rollback 回退至 25.06；
  2. 若失败，通过串口重新刷写已验证的 25.06 HPM 包；
  3. 未来升级时，使用 QEMU 仿真验证新版本稳定性，并锁定 SDK 版本；
  4. 可考虑升级至 openUBMC 25.09 或更高版本，其具备更好的升级容错与恢复机制。

如问题仍无法解决，请提供完整的 dmesg 日志或联系社区技术支持提交 Bug 报告。

相关链接：

  1. 从25.12回退到到25.06后，ssh无法登录
  2. 【教学培训篇】新增组件
  3. 开发板启动过程中在内核解压后无法继续运行
  4. 伙伴过渡包刷到华为bmc后，bmc起不来
  5. 固件升级机制及常见问题 | 文档中心 | openUBMC
3

在构建openUBMC固件的时候把btc_drv.ko这个文件先屏蔽掉试试呢？在启动的时候不加载这个驱动模块

4

是指在编译阶段屏蔽吗？我在manifest.yml中没有找到btc相关的组件，请问是有什么屏蔽的命令或方法吗？

5

嗯，是在出包构建rootfs的阶段中，修改manifest/仓库下build/customization/prototype.py 这个脚本文件，类似下面这样，你可以把这里的bt_drv.ko,改成btc_drv.ko试试，删除这个驱动加载脚本中的insmo btc_drv.ko这一行，这样升级后的包就不会在启动的时候加载这个驱动了

图片

6

记得把 # 这个注释去掉，我是为了要加载bt_drv.ko文件，所以屏蔽了这个语句的执行

7

可以串口切分区收日志看下重启原因

8

您好，重启前报的是

[ 760.300958] INFO: task kworker/2:1:51 blocked for more than 378 seconds.
[ 760.307674] Tainted: G O L 5.10.0 #1
[ 760.312887] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 760.321088] INFO: task skynet:2496 blocked for more than 378 seconds.
[ 760.327624] Tainted: G O L 5.10.0 #1
[ 760.332838] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 760.340702] locked:
[ 760.342819] c9dfb89c (hash) &inode->i_rwsem 3 [<00000000c8e88996(hash)>] __sock_release+0x34/0xec
[ 760.352433] Kernel panic - not syncing: hung_task: blocked tasks
[ 760.358432] CPU: 3 PID: 290 Comm: khungtaskd Tainted: G O L 5.10.0 #1
[ 760.365975] Hardware name: Hisilicon Hi1711 ASIC (DT)
[ 760.371010] Call trace:
[ 760.373458] dump_backtrace+0x0/0x198
[ 760.377112] show_stack+0x18/0x28
[ 760.380424] dump_stack+0xe8/0x15c
[ 760.383821] panic+0x184/0x43c
[ 760.386873] watchdog+0x174/0x520
[ 760.390184] kthread+0x168/0x1a4
[ 760.393408] ret_from_fork+0x10/0x1c
[ 760.396980] SMP: stopping secondary CPUs
[ 760.401232] The raw dump memory did not configured, raw_dump_addr = 0x0000000000000000, raw_dump_size = 0.
[ 760.410848] write reserved mem: make sure reserved mem had configure? returned -22
[ 760.418392] Kernel Offset: 0x24d36d600000 from 0xffff800010000000
[ 760.424465] Module Offset: 0x24d302e40000 from 0xffff800010000000
[ 760.430538] Linear Region Offset: 0x580980000000 from 0xffff000000000000
[ 760.437215] PHYS_OFFSET: 0xffffa7f700000000
[ 760.441385] HKRR parameters: disabled
[ 760.445039] CPU features: 0x0020,00240026,0800a018
[ 760.449815] Memory Limit: none
[ 760.452870] Rebooting in 1 seconds..

完整日志如下：
2512-reboot.txt (87.4 KB)

9

加上了之后还是会报call trace，请问是我加的位置不对吗？

image
image1624×749 111 KB

下面是这次更新的log
2512-error-all.txt (75.2 KB)

10

从你的日志来看，加这里应该没生效的，不好意思，btc_drv.ko的加载位置和bt_drv.ko的加载位置不一样，这个得找一下了。

你这个是从iBMC直接升级到openUBMC的吗？还是说是先升级的华为的过渡包，然后再升级到openUBMC？

另外观察到你这次的call trace像是imklog这个进程在读取日志文件的时候发生了软死锁，这个得具体定位下原因了，和你之前的btc模块加载时出现的现象还是不一样的

11

btc_drv.ko模块这个是在ipmi_core这个组件里进行加载，这个只能找接口人问问了。

图片

12

先升级的过渡包，再升级的ubmc，这次的bug是从25.06升25.12时出现的问题。

我这次直接把ipmi_core整个模块都去掉了也还是不行

image
image545×260 35.7 KB

13

还是内核Panic重启吗？ 这个可能得找下华为那边的PAE问问了，这种一般是内核驱动这块出问题才会会触发Panic重启，看看是不是驱动和硬件方面存在啥兼容性问题