BMC hang后恢复的几种方法

简介:

BMC hang住后恢复的几种方法


在服务器上一般都会有BMC来检测系统并报告系统的健康状况,从而保证服务器的连续稳定运行。由于BMC本身也是一个由硬件、操作系统、监控应用程序组成的软硬件系统,本身也可能发生故障,甚至导致无法响应系统发过来的IPMI请求,这就是所谓的BMC hang。那么,当BMC出现hang的情景后,有哪些措施可以尝试恢复呢?


首先,可以尝试重新加载服务器端host上BMC的驱动,可以运行下面命令去检查之前IPMI驱动有没有加载:

[root@localhost ~]#lsmod | grep “ipmi”

如果这个命令返回空,就表明当前操作系统没有加载IPMI依赖的驱动,需要手动加载解决。否则可以先

rmmod掉先前的驱动,然后参考下面的命令重新加载:


[root@localhost ~]# cd /usr/lib/modules/3.10.0
3.10.0/                3.10.0-229.el7.x86_64/
[root@localhost ~]# cd /usr/lib/modules/3.10.0-229.el7.x86_64/kernel/drivers/char/ipmi/
[root@localhost ipmi]# ls
ipmi_devintf.ko  ipmi_msghandler.ko  ipmi_poweroff.ko  ipmi_si.ko  ipmi_watchdog.ko
[root@localhost ipmi]# lsmod | grep "ipmi"
ipmi_si                53353  0
ipmi_msghandler        45603  1 ipmi_si
[root@localhost ipmi]# rmmod ipmi_si  ipmi_msghandler
[root@localhost ipmi]# modprobe ipmi_devintf.ko
modprobe: FATAL: Module ipmi_devintf.ko not found.
[root@localhost ipmi]# modprobe ipmi_devintf
[root@localhost ipmi]# modprobe ipmi_si
[root@localhost ipmi]# modprobe ipmi_msghandler
You have new mail in /var/spool/mail/root
[root@localhost ipmi]# modprobe ipmi_poweroff
[root@localhost ipmi]# modprobe ipmi_watchdog
加载完成之后,可以再次确认驱动是否加载成功:


[root@localhost ipmi]# lsmod | grep "ipmi"
ipmi_watchdog          24912  0
ipmi_poweroff          14366  0
ipmi_si                53353  2
ipmi_devintf           17572  0
ipmi_msghandler        45603  4 ipmi_devintf,ipmi_poweroff,ipmi_watchdog,ipmi_si


末了,还可以运行一些IPMI命令进一步检查确认,是否IPMI可用:

[root@localhost ipmi]# ipmitool sel elist
   1 | 12/29/2015 | 06:51:39 | Processor | Configuration Error | Asserted
   2 | 12/29/2015 | 06:55:26 | Processor | Configuration Error | Asserted
   3 | 12/29/2015 | 06:55:27 | Processor | Configuration Error | Asserted
   4 | 01/13/2016 | 13:43:24 | Watchdog 2 #0xca | Timer interrupt | Asserted

如果上面办法不能解决问题,可能是KCS接口hang住了,可以参考下面的方法解决。


其次,可以尝试通过网络LAN接口能否重启BMC。

比如有一台服务器上的BMC IP为192.168.1.95,并且已经配置远程用户和密码且允许登录,那么可以尝试下面的命令去重启BMC:
[root@localhost ~]# ipmitool -I lanplus -H 192.168.1.95 -U admin -P admin mc reset cold
Sent cold reset command to MC

如果能够BMC重启,再在服务器端运行IPMI命令,观察是否命令能够运行。如果能够运行,就说明KCS接口已经正常。


再者,可以考虑完全把BMC系统掉电,然后重新上电。MC通常可以控制给host上电、关电,它自身除非AC掉电(拔掉电源)总是处于有电状态。因此,这个时候需要拔掉整个BMC和host主机的AC电源,过一会后再重新上电。等系统起来后,再运行IPMI命令看BMC是否正常。如果一切正常,就表明已经AC cycle后BMC已经恢复。


最后,可以连接上BMC的输出串口,检查重新上电后它是否有输出、以及输出停留的地方,以此来定位BMC无法启动的现场,常见的原因包括:

1. BMC 固件被不小心改变;

2.看门狗超时设置太小,某个启动项耗时太长导致系统不停重启、超时、重启.....

3. BMC 固件升级或者在不停地升级。

















本文转自存储之厨51CTO博客,原文链接: http://blog.51cto.com/xiamachao/1773434,如需转载请自行联系原作者




相关文章
|
4月前
|
监控 Linux 数据安全/隐私保护
问题记录:开机提示emergency mode(紧急模式)如何处理
在依赖Linux作为核心操作系统的环境中,系统的稳定和可靠性通常是我们理所当然的期待。然而,即使是最稳定的系统,有时也会在启动时出现异常,突然推到紧急模式的怀抱。这种模式,通常有被称为“Emergency Mode”,在Linux系统面临关键错误时作为一种安全网,但对于那些不熟悉如何应对此类问题的小伙伴来说,它可能带来困惑甚至恐慌。
问题记录:开机提示emergency mode(紧急模式)如何处理
|
SQL Oracle 关系型数据库
掉电引起的ORA-1172错误解决过程(二)
由于UPS故障,导致机房连续多次掉电,问题解决后,发现一台本地测试数据库打开时报错,ORA-1172、ORA-1151错误。 掉电引起的ORA-1172错误解决过程(一):http://yangtingkun.itpub.net/post/468/465223 尝试打开数据库。
1457 0
|
SQL Oracle 关系型数据库
掉电引起的ORA-1172错误解决过程(三)
由于UPS故障,导致机房连续多次掉电,问题解决后,发现一台本地测试数据库打开时报错,ORA-1172、ORA-1151错误。 掉电引起的ORA-1172错误解决过程(一):http://yangtingkun.
1336 0
|
关系型数据库 数据库 PostgreSQL