带内执行ipmitool lan print 1命令卡顿

交流互助区
1

问题描述

带内执行ipmitool lan print 1命令卡顿，同时os内报IPMI BT：timeout in RD_WAIT

os dmesg打印
os dmesg打印685×302 18.6 KB

带内执行ipmitool命令耗时
带内执行ipmitool命令耗时626×288 8.9 KB

其它：

1、带内执行其它命令不会卡顿，如ipmitool fru等；

2、带外执行这个命令不会卡顿；

3、实际是ipmitool lan print 1中的（ipmitool raw 0xc 0x2 01 0 0 0等）卡顿；

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：OpenUBMC2512

重现步骤

  1. 执行DC cycle测试；

  2. DC测试完后，发现执行带内执行ipmitool lan print 1命令卡顿；

期望结果

带内执行ipmitool lan print 1命令不卡顿，无bt相关的timeout

实际结果

1、带内执行ipmitool lan print 1命令卡顿，同时os内报IPMI BT：timeout in RD_WAIT

2、BMC app.log日志中有相关unknown_service WARNING: btc.lua(118): btc[1] request process timeout

尝试过的解决方案

BMC重启后，现象消失

2

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

:clipboard: 总结

项目 内容
根本原因 BT 通信通道因驱动模式不当或 ipmi_core 处理阻塞，导致响应延迟，从而引发带内命令超时
关键证据 内核日志 timeout in RD_WAIT、btc.lua request process timeout、仅带内受影响
解决方案 1. 确保启用 bt over localbus
2. 检查并升级 BMC/CSR/CPLD/BIOS 配套版本
3. 优化 ipmi_core 中阻塞性业务逻辑
验证方式 重启后执行 ipmitool lan print 1，观察是否仍卡顿，同时检查 BMC 日志无超时警告
点击此处查看详细分析解答

带内执行 ipmitool lan print 1 命令卡顿问题分析与解决方案

:magnifying_glass_tilted_left: 问题描述

在带内执行 ipmitool lan print 1 命令时出现严重卡顿现象，命令耗时长达 1分51秒，系统内核日志中频繁输出以下超时错误：

[38149.585848] ipmi_si IP10001:01: IPMI BT: timeout in RD_WAIT
...
[38201.133650] failed 3 retries, sending error response

同时，BMC端的 app.log 中记录了超时警告：

unknown_service WARNING: btc.lua(118): btc[1] request process timeout

该问题仅出现在带内通信场景下，而执行其他命令（如 ipmitool fru）正常，且带外执行相同命令无卡顿。重启 BMC 后问题暂时消失。

:puzzle_piece: 核心原因分析

1. IPMI BT 通道超时机制

  • ipmitool lan print 1 命令通过 BT（Block Transfer）通道进行通信。
  • 系统日志 IPMI BT: timeout in RD_WAIT 表明 BT 接口在等待读取响应时超时。
  • BT 驱动默认重试 3 次失败后返回错误，反映为用户侧的命令执行延迟。

:light_bulb: 相关机制说明：
根据文档知识库，BT 通道使用 ipmi_core 模块处理带内请求，若 ipmi_core 处理负载过高或驱动异常，将导致 BT 通信超时。

2. 带内 vs 带外超时机制差异

通道类型 超时机制 特点
带内 (In-band) 使用 BT 通道，依赖操作系统内核驱动 ipmi_si，由 ipmi_core 在 BMC 端处理请求 响应时间受限于内核驱动与 BMC 服务调度，易受系统负载影响
带外 (Out-of-band) 使用 RMCP+/LAN，由 rmcpd 守护进程处理 独立于操作系统，路径稳定

:white_check_mark: 实验验证：

“带外可以响应而带内不能响应”——duzhou13_51cdj 在 OpenUBMC 社区指出，这是由于不同通道的超时处理策略不同。

3. BMC 端服务处理瓶颈

  • ipmitool lan print 1 是对 IPMI raw 0x0c 0x02 类命令的封装，BMC 端需解析并返回完整 LAN 配置信息（MAC、IP、子网、掩码、RMCP+ 套件等）。
  • 若 BMC 上的 ipmi_core 服务因资源竞争或阻塞未能及时响应，就会引发 BT 超时。

:white_check_mark: 证据支持：

  • WH11003 报告类似问题（Reference ID: 1），确认在业务处理耗时较长时，带内命令超时为框架默认限制（4.5秒）。
  • 当前卡顿时间远超此限制，说明存在深层阻塞。

4. 驱动加载异常或通信模式错配

  • 日志 ipmi_si IP10001:01 显示底层驱动为传统 BT 模式，而非优化的 BTC 或 Localbus 模式。
  • 若系统应启用 bt over localbus 但实际运行在旧 BT 模式，会导致性能下降和通信不可靠。

:pushpin: 参考知识：

  • IPMI管理定位问题.md 提到：bt over localbus 需配套升级 BMC、CSR、CPLD、BIOS，否则易出现 BT 通信异常。
  • 存在 btc mode 日志关键字判别加载模式（1：BTC，2：Localbus）

:white_check_mark: 解决方案与建议

:white_check_mark: 方案一：确认并切换至高效通信模式（BTC/Localbus）

  1. 检查当前 BT 模式

    # 在 BMC 上查看日志是否有模式提示
journalctl -u ipmi_core | grep "btc mode"
    • 若无此日志或显示 mode=1，说明未启用 Localbus。

  2. 确保固件版本配套

    • 升级并生效以下组件至兼容版本：
      • BMC 固件 ≥ 25.12
      • CSR
      • CPLD（基础板 & 扩展板）
      • BIOS

  3. 触发生效流程

    • 执行下电→上电或 reset 命令，使 CPLD/BIOS 更改生效。

:white_check_mark: 方案二：排查 ipmi_core 服务状态与负载

  1. 检查 ipmi_core 是否正常运作

    # 查看服务状态
systemctl status bmc.kepler.ipmi_core
# 检查日志是否频繁报错
tail -f /var/log/framework.log | grep Ipmi_Core

  2. 避免业务阻塞

    • 若 ForeachStatusObjects 等 Lua 脚本因对象缺失（如 OnePower）而阻塞，会导致超时。
    • 建议修改逻辑为非重试或限定重试次数（如 mdb_service.foreach_non_virtual_interface_objects(..., false)）。

:white_check_mark: 方案三：优化 BT 驱动与超时参数（可选）

:warning: 注意：仅用于调试定位，不建议生产环境随意修改

  1. 调整内核参数减少等待时间（快速暴露问题）

    # 修改超时值（单位毫秒）
echo 1000 > /sys/module/ipmi_si/parameters/try_1_time
echo 1000 > /sys/module/ipmi_si/parameters/try_harder_time

  2. 使用 ipmitool 参数控制行为

    # 设置重试次数为1，便于抓包分析
ipmitool -R 1 lan print 1

:white_check_mark: 方案四：重启 BMC（临时规避）

虽然用户已确认“重启 BMC 后现象消失”，但这只是临时措施。需结合上述方案从根本上排查配套状态和服务逻辑。

:clipboard: 总结

项目 内容
根本原因 BT 通信通道因驱动模式不当或 ipmi_core 处理阻塞，导致响应延迟，从而引发带内命令超时
关键证据 内核日志 timeout in RD_WAIT、btc.lua request process timeout、仅带内受影响
解决方案 1. 确保启用 bt over localbus
2. 检查并升级 BMC/CSR/CPLD/BIOS 配套版本
3. 优化 ipmi_core 中阻塞性业务逻辑
验证方式 重启后执行 ipmitool lan print 1，观察是否仍卡顿，同时检查 BMC 日志无超时警告

:link: 参考资源与社区讨论

建议后续将 ipmi_core 升级至稳定版本（≥1.10.31），并建立自动化检测机制监控 BT 通信健康状态，预防此类问题复发。

3

R410KV2_20260323-1118.zip (9.9 MB)

4

你好，分析日志发现btcrequest process timeout伴随有网络dhcp获取地址的流程日志，可以尝试网络使用静态IP配置观测下是否还有该问题

5

感谢回复，

1、当前网络协议是ipv4/ipv6；

2、其中ipv4是静态的，ipv6是dhcp的。

跑os dc cycle出现的。那尝试ipv6也改成静态的试一下

6

好的，验证结果麻烦及时同步，目前看dhcpv6始终没有获取到ipv6地址，命令卡顿可能和这个现象有关，也需要排查下原因。

7

合入解决内存占用率高的问题后，暂未复现

8

好的