---
title: Atlas 800-3000 CentOS 7.6系统加载ipmi_si驱动失败-昇腾社区
description: 问题现象：脚本运行power cycle测试200次，第31次测试中断，系统无法再次power cycle，查看dmesg日志发现有以下报错： failed 2 retries, sending error respone
keywords: CentOS 7.6;IPMI驱动;dmesg
url: https://www.hiascend.com/document/caselibrary/detail/zh_cn_Atlas_800_3000_00070.xml
section: (其他)
---

# Atlas 800-3000 CentOS 7.6系统加载ipmi_si驱动失败-昇腾社区

URL: https://www.hiascend.com/document/caselibrary/detail/zh_cn_Atlas_800_3000_00070.xml
描述: 问题现象：脚本运行power cycle测试200次，第31次测试中断，系统无法再次power cycle，查看dmesg日志发现有以下报错： failed 2 retries, sending error respone
关键词: CentOS 7.6;IPMI驱动;dmesg

昇腾文档 [了解详情](https://www.hiascend.com/document)

故障案例 [了解详情](https://www.hiascend.com/document/caselibrary)

Atlas 800-3000 CentOS 7.6系统加载ipmi_si驱动失败

Atlas 800-3000 CentOS 7.6系统加载ipmi_si驱动失败

2021/09/06

1.5k

问题信息

| 问题来源 | 产品大类 | 产品子类 | 关键字 |
| --- | --- | --- | ---|
| 版本测试 | 安装部署 | 驱动固件 | CentOS 7.6、IPMI驱动、dmesg |

#### 问题现象描述

硬件配置：

机型：Atlas 800-3000

CPU：Kunpeng 920-5230

BIOS版本：1.12(U75)

iBMC版本：5.00 (U68)

CPLD版本：3.08 (U6076)

问题现象：脚本运行power cycle测试200次，第31次测试中断，系统无法再次power cycle，查看dmesg日志发现有以下报错：

#### 关键过程、根本原因分析

1. 通过查看dmesg日志，发现有和ipmi_si驱动相关的报错：

1. 通过以上的报错分析可知，IPMI设备注册失败，因此判断/dev下并没有创建ipmi设备，因此无法使用ipmitool命令。从实际的power cycle来看，之所以无法继续power cycle，是因为IPMI设备没有生成，而power cycle又需要调用ipmitool来进行power cycle操作，从而发生了无法power cycle的现象。
2. 查找日志IPMI message handler: device id demangle failed: -22打印对应的函数，如下：

1. rv返回非0值，才会报错，因此我们看ipmi_demangle_device_id函数的定义，返回-22是因为返回了EINVAL，加打印观察data_len和data。

发现在异常时data_len的值是1，而data的数据是：

在正常时data_len的值是16，而data的数据是：

1. 追踪bmc_device_id_handler()函数对应的call trace，如下所示：

init_ipmi_si -> try_smi_init -> ipmi_register_smi -> __bmc_get_device_id -> __get_device_id -> i_ipmi_request ->  smi_send -> sender -> check_start_timer_thread ->start_next_msg->return_hosed_msg-> deliver_recv_msg -> ipmi_smi_msg_received  ->tasklet_schedule(&intf->recv_tasklet)-> smi_recv_tasklet -> handle_new_recv_msgs -> handle_one_recv_msg -> handle_bmc_rsp -> deliver_local_response -> deliver_response ->bmc_device_id_handler

1. 注意到start_next_msg()和return_hosed_msg()这两个函数，我们看start_next_msg()函数的定义，从其定义可知，err返回了非0值，所以才会调用到return_hosed_msg()函数。

1. 继续看smi_info->handlers->start_transaction函数的定义，结合第4步中异常时返回了0xd5，因此可以判断在向bmc发get device id请求时BT的状态并不是IDLE的，所以返回了错误。

1. 追踪BT_STATE_IDLE这个宏的调用，发现在BT通道IDLE时会去读BT通道的capabilities。

通过以上的一系列分析可以得出本问题的根因是ipmi_si驱动在初始化的时候会去读bmc的device id，但是在读device id的这个操作的同时也在读BT通道的capabilities，造成了冲突，因此导致无法成功读取bmc的device id。

#### 结论、解决方案及效果

结论：

这是ipmi_si驱动的一个BUG，ipmi_si驱动在读device id的这个操作的同时也在读BT通道的capabilities，造成了冲突，因此导致无法成功读取bmc的device id。这个BUG在Linux社区已经有patch：ipmi: Move BT capabilities detection to the detect call，链接是：https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1872992.html# [了解详情](https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1872992.html#)

解决方案：

1. 对于CentOS 7.6内核内置的ipmi_si驱动，目前尚未合入这个patch。
2. CentOS 7.7和CentOS 8.0已经合入了这个patch，因此你可以将系统升级到这两个版本来解决这个问题。
3. 如果要在CentOS 7.6上解决这个问题，你也可以手动下载CentOS 7.7中ipmi_si的驱动源码，并在CentOS 7.6下编译，然后替换掉CentOS 7.6的ipmi_si驱动即可。

#### 经验总结、预防措施和规范建议

无

#### 备注

无

本页内容

- 问题信息
- 问题现象描述
- 关键过程、根本原因分析
- 结论、解决方案及效果
- 经验总结、预防措施和规范建议
- 备注