文档中心
IPMI管理定位问题
更新时间： 2025/10/15
在Gitcode上查看源码

BT通道相关 ​

【Q1】Os启动失败，BTC通信异常，报Read_data_error: Time_out失败，bmc日志打印unknown DestLun 2 ​

原因分析 pcie和黑匣子功能没开导致pcieflag没有使能，影响了pcie建链，btc通信异常 *查询pcie置为命令：*busybox_x hexdump -s 0x400000 /dev/mmcblk0p8 -n 1024 -C

解决方案 打开黑匣子功能，重启OS

【Q2】ipmi_core资源树查询不到，重启bmc无ipmi_core组件启动日志打印 ​

原因分析 ipmi_core.db文件被破坏，导致创建本地表报错，终止了启动流程，导致ipmi_core启动失败，无法提供消息转发等能力 解决方案 删除ipmi_core.db文件后重启bmc

【Q3】bt over localbus问题排查思路 ​

检查配套，btc切换bt over localbus需要配套升级，升级要求如下： ​

升级的几个步骤，需要保证升级过程中不出现异常告警、BIOS启动异常现象：

第1步、上电状态下，升级并生效BMC ——生效后，需要保证BT走BTC通信正常，无异常告警

第2步、上电状态下，升级并生效CSR ——生效后，需要保证BT走BTC通信正常，无异常告警

第3步、上电状态下，先升级CPLD（扩展板、基础板，不做生效），升级MCU

第4步、升级BIOS固件

第5步、通过下电命令/生效命令/复位命令触发AC，生效CPLD、BIOS固件 ——生效后，需要保证BT走Localbus通信正常，无异常告警

如下图：

1）升级之前版本：即为现网运行主流版本（TR5-1），基于BTC通信。

2）升级过程版本：即为升级过程中间一个版本，基于BTC通信，无异常告警。

3）升级结束版本：即为最终目标版本，基于Localbus通信。

bt over localbus需要配套升级，否则很容易出现BT不通，配套 ​

配套依赖基础板CPLD、扩展板CPLD、基础板MCU、Bios等

判断bmc bt驱动加载是否正确 ​

1、lsmod|grep bt查看驱动加载的是bt还是btc，此方法无法区分是否为localbus，只能区分是否为bt

2、dmesg|grep bt 查看驱动加载的bt驱动类型，bt over localbus，btc mode值为2，1则会btc

3、查看app.log,确定加载的bt驱动类型,bmc启动时会明确记录加载的bt驱动类型，如下图（注意启动时间较早可能会转储）

shell
cat /var/log/app.log|grep "load bt"

bt一直中断导致bmc复位 ​

cpld中断信号持续拉高，引发中断风暴（通过devmem工具查看H2B_ATN是否持续置位），sdk没有过频保护，触发bmc复位

需联系cpld定位，同时bmc需带上sdk过频保护的合入，保证bmc不复位。触发过频保护，关闭中断，bt消息就收不到了，需cpld定位

【Q4】BTC is busy, b_busy ​

定位思路：如图为bios上电的第一条IPMI命令，但是直接报IPMI不通，可以确认为BT ctrl状态寄存器初始值不正确，原因为cpld复位未清除bt ctrl状态，恢复bt功能

【Q5】ReportBiosVersionToBmc.efi、Read data: Time out ​

问题如图，ReportBiosVersionToBmc.efi里一般是bios发送的第一条ipmi，用于上报bios版本号；

报错打印bt ctrl: 0x0，代表BIOS发送了数据，但未等到对端返回，bios会等待bt ctrl中对应的bit置位后再读取ipmi返回数据；

常见问题原因为bt中断异常导致，需要检查cpld逻辑；

【Q6】串口疯狂刷btc invalid日志：btc_ioctl_transfer,316,btc read/write index(4) is invalid ​

原因分析 bt驱动加载错误导致该问题

定位方法 出现该问题串口几乎无法输入任何命令，可保存刷日志的串口，搜索关键字‘btc mode’，括号内为2代表加载的是bt over localbus，1代表btc

该问题大概率是硬件Get BT Channel命令字返回了错误的值，导致加载了错误的驱动类型

AC几次恢复环境后一键收集BMC日志确认问题

IPMB通道相关 ​

IPMI管理相关 ​

【Q1】 重启bmc，cdev卸载失败，日志打印rmmod: can't unload module 'bmc_cdev_drv': Resource temporarily unavailable*** ​

原因分析： edma服务启动打开四个字符设备，升级telnet包后busybox_x会起telnetd服务也会占用设备，重启时edma会释放对设备的依赖，但是telnetd服务并没有。所以由于依赖的存在，导致卸载失败

影响： 1、bmc重启性能超基线 2、重启bmc_core，导致edma服务启动失败，edma通道不可用 规避手段： killall busybox_x 解决方法： ipmi_core升级到1.10.30及以后版本,firmware_mgm升级到1.10.44及以后版本可以解决该问题

【Q2】bmc重启，ipmi_core重启超时 ​

原因分析： 1、bmc重启，ipmi_core会执行reboot prepare和action，从日志看action执行有问题没有返回，导致超时 影响： 1、bmc重启时间超基线 2、对业务无影响 解决方法： ipmi_core升级到1.10.31及以后版本，或升级iBMC300 5.3.0.1.B999-ibmc-20231226153510及以后的主干冒烟包

【Q3】构建时，ipmi_core报错 $'\r': command not found ​

原因分析： git 配置core.autocrlf的值为true时，代码检出时会将行尾转换为crlf，提交代码时转换为lf。ubuntu下设置了该属性，构建时会报错 解决方法： git config --global core.autocrlf false；清除缓存后重新构建可解决该问题

【Q4】打开trace功能，ipmi.txt概率性不生成 ​

原因分析 打开trace功能后，如果没关闭的情况下删除文件会造成该问题

规避手段 重启bmc_core

解决方法 ipmi_core升级到1.20.7版本及以后，文件被删除后，再次接收到消息后会重新创建该文件

ps: 文件删除后，如果没有追踪到消息，文件仍不会创建，只有追踪到消息才会重新创建 请规范操作ipmi.txt，尽量不要在未关闭的情况下删除文件。

【Q5】重启framework，导致的ipmi消息概率性不通 ​

原因分析 framework重启进程也会导致ipmi_core重启，启动时ipmi_core会扫描资源树资源接口将ipmi命令加到路由表，但是由于获取资源树上ipmi命令时未判断是否可成功获取到资源，导致该场景下高概率报错，ipmi命令缺失。而后续注册的一键收集、导入导出等接口均未注册而不可用

规避手段 重启bmc_core

解决方法 5.3.6版本升级到1.10.37及以上版本、5.5.0升级到1.20.8及以上版本

【Q6】bmc升级后、ssh可以登录，web打不开、nginx没有起来 ​

原因分析 虚拟网口veth没有起来，lsmode发现bmc_veth_drv驱动未加载 根因：每次编译驱动会检查是否有变动，如果没有变动则不会重新编译。但是rtos版本更新后，由于编译版本不匹配导致驱动加载报错

解决方案 重新编译ipmi_core，让bmc_veth_drv.ko等驱动在新的Rtos环境重新编译 同时要注意sdk版本配套的rtos版本是不是一致

DT问题 ​

【Q1】IT报IpmiCore ‘service not exists’，或者报IpmiCore Path找不到 ​

[:00000008] lua call [c to :8 : 66 msgsz = 18] error : /root/selfV3/bios/temp/opt/bmc/skynet/lualib/skynet.lua:1008: /root/selfV3/bios/temp/opt/bmc/skynet/lualib/skynet.lua:434: /root/selfV3/bios/temp/opt/bmc/libmc/lualib/mc/context.lua:119: /root/selfV3/bios/test/integration/test_bios.lua:343: /root/selfV3/bios/temp/opt/bmc/libmc/lualib/mc/mdb/init.lua:700: service not exists, path:/bmc/kepler/IpmiCore, interface:bmc.kepler.IpmiCore
stack traceback:
        [C]: in function 'error'
        /root/selfV3/bios/temp/opt/bmc/libmc/lualib/mc/context.lua:119: in function </root/selfV3/bios/temp/opt/bmc/libmc/lualib/mc/context.lua:116>
        (...tail calls...)
        /root/selfV3/bios/temp/opt/bmc/skynet/lualib/skynet.lua:384: in function </root/selfV3/bios/temp/opt/bmc/skynet/lualib/skynet.lua:356>
stack traceback:
        [C]: in function 'assert'
        /root/selfV3/bios/temp/opt/bmc/skynet/lualib/skynet.lua:1008: in function 'skynet.dispatch_message'

ipmi_core未对象分发，导致请求IpmiCore下的接口访问不到，it路径下增加IpmiCore的配置，如下：

"IpmiCore_1": {}

【Q2】IpmiCore对象未分发，hwdiscovery打印 ‘ignore object: IpmiCore_01’ ​

2024-08-01 23:39:44.867502 hwdiscovery WARNING: analyse.lua(365): ignore object: IpmiCore_01, class: IpmiCore, error: fail to get class information

在集成测试文件中新增配置如下：

【Q3】ipmi_core ERROR: main.lua(189): ipmi_core app start failed, err:.../V3CODE/temp/opt/bmc/apps/ipmi_core/lualib/chip_info.lua:26: attempt to call a nil value (method 'close') ​

**原因：**ipmi_core组件适配了1712，新增的chip_info文件中需要调用libsoc代码，DT中需打桩 **解决方案：**在集成测试文件夹中按照图示目录结构新增文件sys_info.lua,内容如下：

local sys_info = {}

function sys_info.new()
    return sys_info
end

function sys_info:get_chip_name()
    return '1711'
end

function sys_info:close()
    
end
return sys_info

其他问题 ​

【Q1】 定制化脚本执行报ssh veth connection timed out ​

原因分析 跑定制化时需要veth驱动，首先要确保bma切换到veth然后与bmc通信正常

ibmacli conf show --name iBMA.ini

如果iBMA_network_type不是veth，则需要切换到veth上然后重启bma生效后继续跑定制化 切换方法：ibmacli conf modify --name iBMA.ini --arg iBMA_System.iBMA_network_type --value veth

上一篇传感器适配常见问题指南
下一篇Event常见问题指南