问题现象描述

硬件配置：

机型：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驱动相关的报错：

   

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

   

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

   

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

   

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

   

5. 追踪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

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

   

   

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

   

   

8. 追踪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#

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

无

备注

无