如何使用 Oracle Linux 中的硬件故障管理

如何使用 Oracle Linux 中的硬件故障管理

in Oracle Linux

作者：Robert Chase

了解、安装、启用和使用 IPMI 和 MCE — Oracle Linux 中的两个硬件故障管理工具。


2013 年 9 月发布

--------------------------------------------------------------------------------

在本文中，我们将重点讨论 Oracle Linux 中的两个硬件故障管理特性以及这两个特性所使用的对应工具：


想对本文发表评论吗？请将链接发布在 Facebook 的 OTN Garage 页面上。有类似文章要分享？请将其发布在 Facebook 或 Twitter 上，我们来进行讨论。

智能平台管理接口 (IPMI) 和 ipmitool 工具
机器检查异常 (MCE) 以及 mcelog、mce-inject 和 mce-test 工具

以下各节将提供技术概述，介绍一些常见用例，并就如何在 Oracle Linux 中安装和配置这些工具提供指导。还通过几个例子展示了如何使用这些工具捕获和报告重要的硬件信息供日常操作使用。

注：这些工具包括许多调优参数和选项，但是这些内容不在本文的讨论范围内。更多信息，请参见“另请参见”部分。

关于硬件故障管理

现代数据中心管理灵活且不断发展。它的任务是推动业务目标并保证任务关键型负载可用，包括各种硬件和软件解决方案，这些方案可能过于复杂，难以有效管理。为了控制风险和满足苛刻的服务级别承诺，各种硬件和软件特性应运而生，从而可以帮助系统管理员监视系统运行状况、及早发现问题。

这些特性被称作故障管理，由多种解决方案和标准构成，旨在提供能够监视、管理、识别和解决那些困扰系统管理员的问题的工具。与数据中心最佳实践（如冗余和高可用性）相结合时，硬件故障管理特性提供强大的工具，可以提升效率、提高认识、降低风险并支持数据中心系统所担负的苛刻目标。

使用 IPMI 和 ipmitool

IPMI 是一个规范，最早于 1998 年由 Intel、Dell、HP 和 NEC 共同制定。其主要目的是提供一个访问系统信息的通用命令接口。它原本是设计成与管理软件无关的；但后来却常与系统特性结合使用。

IPMI 独立于操作系统运行，这意味着您可以“带外”方式或是在操作系统启动之前访问系统。这在操作系统或系统出现故障的情况下非常有用，因为您可以使用它提供的工具在传统系统管理功能不可用时收集关键信息。

IPMI 中有一些预定义的命令和接口可用于读取温度、电压、风扇速度、电源和网络设置。而且 IPMI 规范被设计成可扩展的。因此，厂商可以自定义和创建其他的命令和传感器。例如，Oracle Integrated Lights Out Manager (Oracle ILOM) 符合 IPMI 1.5 版和 2.0 版。HP 的 Integrated Lights-Out (iLO) 和 Dell 的 DRAC (Dell Remote Access Controller) 就是集成了 IPMI 或符合 IPMI 的方案。每个解决方案都提供了一组带外支持特性。这正是本规范的设计意图：提供通用的、跨平台的支持，同时让厂商能够定制自己的个性化解决方案的方法。

在 Oracle Linux 中，使用 ipmitool 实用程序管理和配置支持 IPMI 规范的设备。从 2.4 版开始，IPMI 支持已成为 Linux 内核的一部分。ipmitool 实用程序提供管理现场可更换部件 (FRU)、LAN 配置、传感器读取和远程机箱电源控制的功能。下一节将讨论使用 ipmitool 中特性的安装和使用场景。

安装

第一步是在系统中安装 ipmitool。支持 IPMI 规范的系统中含有 IPMI 特性。这些系统都含有一个基板管理控制器 (BMC)，它是 IPMI 架构的智能核心。使用 OpenIPMI 和 ipmitool，您可以与 BMC 直接连接并与 IPMI 规范实现的特性交互。

为了访问服务器的 IPMI 特性，本地工作站或管理计算机需要位于能访问具有 BMC 的系统的网络，且必须安装了 OpenIPMI 和 ipmitool 工具。要安装这些工具，请转至服务器控制台并键入以下命令：
yum install ipmitool.x86_64 OpenIPMI.x86_64


然后，使用以下命令配置 ipmitool 以便在系统上使用并启动服务。启动服务后，它会加载 IPMI 内核并创建一个 /dev/ipmi0 设备。
chkconfig ipmi on
service ipmi start


还可以在其他含有 BMC 的 IPMI 系统上安装 ipmitool 和 OpenIPMI 软件包，这两个软件包提供配置 IPMI 设置的选项，我们在以下示例中将看到。

安装、配置并运行这些工具后，我们就可以与控制和监视系统的特性进行交互。我们来看看下面这些利用 ipmitool 和 Oracle Linux 的 IPMI 用例。

远程系统访问

IPMI 的一个特性是能够通过网络直接与系统相连。这个动作独立于目标系统上安装的任何操作系统，提供了一个非常有用的管理选项。它为您提供了与服务器 IPMI 接口的直接连接，让您可以远程执行 IPMI 命令。实际上，您可以使用该选项编写脚本，从而能够在一台管理计算机上控制无数台服务器。

要启用此特性，必须先完成几个步骤，比如设置口令以及为 BMC 所在服务器的 IPMI 接口添加 IP 地址。需要注意的是，许多服务器都有一个单独的远程管理以太网端口。查看您的硬件文档，了解有关具体服务器远程管理的更多信息。

通过网络访问 IPMI 的第一步是要为 BMC 所在的系统配置有效的 IP 地址。以下示例演示了如何使用 ipmitool 完成这一配置。（注：该示例使用 Oracle Sun Fire X4170 M2 服务器。）要使用 ipmitool 配置 IP 地址，请在服务器控制台使用以下命令：
ipmitool lan set 1 ipaddr 192.168.1.120
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 192.168.1.1

设置完 IPMI 接口的 IP 地址之后，需要一个方法进行身份验证。在以下示例中，我们将口令改成 root 用户，从而允许使用 PASSW0rd 口令登录。
注意：我们不推荐使用该方法，此处仅用来举例。我们强烈推荐使用安全口令。

首先，我们需要列出用户以获得 ID 号，然后将使用该 ID 号更改口令。
[root@test1 ~]# ipmitool user list 1
ID  Name     Callin  Link Auth  IPMI Msg   Channel Priv Limit
1            false   false      true       NO ACCESS
2   root     false   false      true       ADMINISTRATOR

[root@test1 ~]# ipmitool user set password 2 PASSW0rd


一旦完成这些配置步骤后，您就可以通过向服务器远程发送 chassis status IPMI 请求来测试配置结果。系统将提示您输入所连接帐户的口令。如果一切配置正确无误，机箱状态将显示在本地命令行上。在您的管理系统命令行上，键入清单 1 所示的命令：
[root@mgmt-vm ~]# ipmitool -I lan -H 192.168.1.120 -U root -a chassis status
Password:
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : true
Power Control Fault  : false
Power Restore Policy : always-on
Last Power Event     :
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false

清单 1

ipmitool 的命令语法使用选项 -I 表示 LAN 接口，使用选项 -H 识别远程系统的主机地址 (192.168.1.120)，使用选项 -U 表示用户名（本例中使用 root），使用选项 -a 提示远程用户口令。后面跟着的是您希望查看状态的命令：chassis status。

还可以使用 ipmitool 远程完成其他任务。上一节中所有的例子都可以使用 ipmitool 的 -I、-H、-U 和 -a 选项远程执行。将多台服务器添加到一个 shell 脚本中，我们还可以从一个管理系统或工作站快速关闭布满设备的整个机架或信息中心的电源。

以下是远程关闭服务器电源的示例：
[root@rchase-oracle-linux-vm ~]# ipmitool -I lan -H 192.168.1.120 -U root -a chassis power cycle
Password:
Chassis Power Control: Cycle


我们还可以实时查看服务器硬件的具体数据。例如，使用 ipmitool sdr 命令可以查看服务器组件的电压和温度。在清单 2 的示例中，我们查看 Sun Fire X4170 M2 服务器的输出。每个硬件厂商提供的数据格式可能略有不同，但字段都是类似的。这个例子中的部分输出已被截断。
[root@test1 ~]# ipmitool sdr
sys.id           | 0x02              | ok
sys.intsw        | 0x00              | ok
sys.psfail       | 0x01              | ok
sys.tempfail     | 0x01              | ok
sys.fanfail      | 0x01              | ok
mb.t_amb         | 28 degrees C      | ok
mb.v_bat         | 2.78 Volts        | ok
mb.v_+3v3stby    | 3.25 Volts        | ok
mb.v_+3v3        | 3.29 Volts        | ok
mb.v_+5v         | 4.99 Volts        | ok
mb.v_+12v        | 12.22 Volts       | ok
mb.v_-12v        | -12.20 Volts      | ok
mb.v_+2v5core    | 2.56 Volts        | ok
mb.v_+1v8core    | 1.82 Volts        | ok
mb.v_+1v2core    | 1.22 Volts        | ok
fp.t_amb         | 21 degrees C      | ok
pdb.t_amb        | 21 degrees C      | ok
io.t_amb         | 19 degrees C      | ok

清单 2

诸如系统温度之类的信息提供了数据中心内部环境条件以及服务器冷却功能的信息。该输出中的数据可以帮助您在问题扩大之前加以识别。例如，关于电压的信息对于检测即将发生的电源故障非常有用，或者可以在服务器脱离直流电源运行时用来监视功率电平。风扇转速可能可能会预示风扇即将发生故障，或者高温读数说明服务器内部有一个潜在热点。我们来看看 IPMI 提供关键系统状态数据的几个例子。

系统状态特性

ipmitool chassis status 命令捕获服务器的一般信息及当前状态。在清单 3 的例子中，我们可以看到系统已启动，电源策略设置为 always-off。我们还看到一个电源发生故障或是电线脱落，因为 Main Power Fault 为 true。测试系统还有另外一个电源，但未连线。
[root@test1 ~]# ipmitool chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : true
Power Control Fault  : false
Power Restore Policy : always-off
Last Power Event     :
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false

清单 3

ipmitool 还让您可以读取系统的配置数据以及将配置数据写入系统。例如，如果我们想更改清单 3 中测试服务器的电源策略，可以使用 ipmitool 来完成。

以下命令显示了如何更改测试服务器上的电源策略配置。记住，清单 3 中的 Power Restore Policy 设置为 always-off。以下命令要将该策略更改为 always-on。如果服务器的电源中断，修改后的政策将导致电源恢复时系统重新启动。
[root@test1 ~]# ipmitool chassis policy always-on


如清单 4 所示，我们可以再次查看机箱状态，确认配置已更改为 always-on 的 电源恢复策略。
[root@test1 ~]# ipmitool chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : true
Power Control Fault  : false
Power Restore Policy : always-on
Last Power Event     :
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false

清单 4

我们还可以查看系统事件日志 (SEL) 中的服务器硬件日志，如清单 5 所示。这对于跟踪硬件事件非常有用，可以用来与标准系统日志中的信息对比。
[root@test1 ~]# ipmitool sel list
3501 | 09/29/2007 | 01:48:21 | System Firmware Progress | System boot initiated | Asserted
3601 | 09/29/2007 | 02:05:57 | System Firmware Progress | Motherboard initialization | Asserted
3701 | 09/29/2007 | 02:05:58 | System Firmware Progress | Video initialization | Asserted
3801 | 09/29/2007 | 02:06:08 | System Firmware Progress | USB resource configuration | Asserted
3901 | 09/29/2007 | 02:06:23 | System Firmware Progress | Option ROM initialization | Asserted
...

清单 5

清单 6 显示了服务器的 SEL，有一些重要问题。它显示内存、风扇和 CPU 有预测性故障。预测性故障是 IPMI 传感器就潜在硬件问题的通知。
ca6 | 02/28/2013 | 06:13:31 | Memory #0x39 | Predictive Failure Asserted
ada6 | 02/28/2013 | 06:13:32 | Memory #0x38 | Predictive Failure Asserted
aea6 | 02/28/2013 | 06:13:32 | Fan #0x3d | Predictive Failure Asserted
afa6 | 02/28/2013 | 06:13:33 | Memory #0x2e | Predictive Failure Asserted
b0a6 | 02/28/2013 | 06:13:34 | Fan #0x3b | Predictive Failure Asserted
b1a6 | 02/28/2013 | 06:13:36 | Memory #0x30 | Predictive Failure Asserted
b2a6 | 02/28/2013 | 06:13:37 | Fan #0x3e | Predictive Failure Asserted
b3a6 | 02/28/2013 | 06:13:38 | Memory #0x2f | Predictive Failure Asserted
b4a6 | 02/28/2013 | 06:13:39 | Memory #0x37 | Predictive Failure Asserted
b5a6 | 02/28/2013 | 06:13:40 | Processor #0x36 | Predictive Failure Asserted
b6a6 | 02/28/2013 | 06:13:40 | Fan #0x40 | Predictive Failure Asserted
b7a6 | 02/28/2013 | 06:13:43 | Memory #0x38 | Predictive Failure Asserted
b8a6 | 02/28/2013 | 06:13:43 | Fan #0x3d | Predictive Failure Asserted
b9a6 | 02/28/2013 | 06:13:44 | Memory #0x2e | Predictive Failure Asserted
baa6 | 02/28/2013 | 06:13:44 | Fan #0x3c | Predictive Failure Asserted
bba6 | 02/28/2013 | 06:13:45 | Processor #0x2d | Predictive Failure Asserted

清单 6

ipmitool 还显示了系统上 SEL 的大小。在清单 7 中，我们看到系统事件日志已达到 99%。在某些硬件上，这将导致一个错误提示灯亮起，提醒关注服务器。
[root@test1 ~]# ipmitool sel
SEL Information
Version          : 2.0 (v1.5, v2 compliant)
Entries          : 909
Free Space       : 72 bytes
Percent Used     : 99%
Last Add Time    : 02/26/2013 00:59:11
Last Del Time    : 02/26/2013 00:59:11
Overflow         : true
Supported Cmds   : 'Reserve' 'Get Alloc Info'
# of Alloc Units : 913
Alloc Unit Size  : 18
# Free Units     : 4
Largest Free Blk : 4
Max Record Size  : 0

清单 7

有些服务器的 SEL 满了以后就无法写入，而其他一些服务器会删除最老的条目。使用 ipmitool，您可以用以下命令清空服务器的系统事件日志：
[root@test1 ~]# ipmitool sel clear
Clearing SEL.  Please allow a few seconds to erase.


然后，可以再次执行 ipmitool sel 命令确认日志日志已清空，如清单 8 所示：
[root@test1 ~]# ipmitool sel
SEL Information
Version          : 2.0 (v1.5, v2 compliant)
Entries          : 0
Free Space       : 16434 bytes
Percent Used     : 0%
Last Add Time    : 02/26/2013 01:07:17
Last Del Time    : 02/26/2013 01:09:01
Overflow         : false
Supported Cmds   : 'Reserve' 'Get Alloc Info'
# of Alloc Units : 913
Alloc Unit Size  : 18
# Free Units     : 913
Largest Free Blk : 913
Max Record Size  : 3

清单 8

现在使用了 0%。此时，根据硬件的不同，如果服务器前端有错误提示灯，它可能会关闭。

硬件审计特性

使用 ipmitool，还可以用 fru 选项获取系统部件号。FRU 代表现场可更换部件，是用来描述服务器中发生硬件故障时需要替换的组件、部件号和序列号的术语。此特性对于收集数据中心中需要获得保修服务的硬件系统的信息非常有用。清单 9 显示了 ipmitool fru 命令的输出示例。部分输出已被截断。
[root@test1 init.d]# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Board Mfg Date        : Sun Dec 31 18:00:00 1995
Board Product         : ASSY,SERV PROCESSOR,G1/2
Board Serial          : 1762TH1-0617000504
Board Part Number     : 501-6979-03
Board Extra           : 50
Board Extra           : G1/2_GRASP
Product Manufacturer  : SUN MICROSYSTEMS
Product Name          : ILOM

FRU Device Description : sp.net0.fru (ID 2)  Product Manufacturer  : MOTOROLA
Product Name          : FAST ETHERNET CONTROLLER
Product Part Number   : MPC8248 FCC
Product Serial        : 00:14:4F:26:E4:C4
Product Extra         : 01
Product Extra         : 00:14:4F:26:E4:C4

FRU Device Description : mb.fru (ID 4)
Chassis Type                    : Rack Mount Chassis
Chassis Part Number     : 541-0250-04
Chassis Serial                  : 0226-0615LHF0DED
Board Mfg Date        : Sun Dec 31 18:00:00 1995
Board Product         : ASSY,MOTHERBOARD,A64
Board Serial          : 1762TH1-0618001211
Board Part Number     : 501-7644-01
Board Extra           : 01
Board Extra           : A64_MB
Product Manufacturer  : SUN MICROSYSTEMS
Product Name          : SUN FIRE X4170 SERVER
Product Part Number   : 602-3222-01
Product Serial        : 0624AN1527

清单 9

ipmitool 特性支持为现场服务人员激活定位器 LED。要使用该选项，您必须确定服务器配备何种 LED。您可以使用清单 10 中所示的命令实现此目的：
[root@test1 ~]# ipmitool sdr list generic
sys.psfail.led   | Generic @20:18.3  | ok
sys.tempfail.led | Generic @20:18.4  | ok
sys.fanfail.led  | Generic @20:18.5  | ok
sys.power.led    | Generic @20:00.0  | ok
sys.locate.led   | Generic @20:00.0  | ok
sys.alert.led    | Generic @20:00.0  | ok
bp.power.led     | Generic @20:2D.0  | ok
bp.locate.led    | Generic @20:2D.1  | ok
bp.alert.led     | Generic @20:2D.2  | ok
fp.power.led     | Generic @20:18.0  | ok
fp.locate.led    | Generic @20:18.1  | ok
fp.alert.led     | Generic @20:18.2  | ok
io.hdd0.led      | Generic @20:1A.0  | ok
io.hdd1.led      | Generic @20:1A.1  | ok
io.hdd2.led      | Generic @20:1A.2  | ok
io.hdd3.led      | Generic @20:1A.3  | ok
p0.led           | Generic @20:2D.6  | ok
p0.d0.led        | Generic @20:1C.0  | ok
p0.d1.led        | Generic @20:1C.1  | ok
p0.d2.led        | Generic @20:1C.2  | ok
p0.d3.led        | Generic @20:1C.3  | ok
p1.led           | Generic @20:2D.7  | ok
p1.d0.led        | Generic @20:1C.4  | ok
p1.d1.led        | Generic @20:1C.5  | ok
p1.d2.led        | Generic @20:1C.6  | ok
p1.d3.led        | Generic @20:1C.7  | ok
ft0.fm0.led      | Generic @20:18.7  | ok
ft0.fm1.led      | Generic @20:19.1  | ok
ft0.fm2.led      | Generic @20:19.2  | ok
ft1.fm0.led      | Generic @20:19.3  | ok
ft1.fm1.led      | Generic @20:19.4  | ok
ft1.fm2.led      | Generic @20:19.5  | ok

清单 10

从清单 10 的输出可以看到该硬件有一个 LED 选项 sys.locate.led。使用以下命令可以打开定位器 LED：
[root@test1 ~]# ipmitool sunoem sbled set sys.locate.led fast
fp.locate.led    | FAST
bp.locate.led    | FAST


命令发出后，服务器前端的 LED 灯将立即打开。可以使用以下命令禁用 LED 灯。再次执行命令后，指示灯将关闭。
[root@test1 ~]# ipmitool sunoem sbled set sys.locate.led off
fp.locate.led    | OFF
bp.locate.led    | OFF


注意：以下信息适用于开发系统和测试系统，不适用于任何生产系统。

我们还可以使用 ipmitool 在系统上注入假的硬件事件进行测试。以下命令将生成一个假的服务器硬件温度警告，并将该警告存储到系统事件日志中。请记住，这将显示为一个实际的硬件问题，测试完成后应清除。
[root@test1 ~]# ipmitool event 1
Sending SAMPLE event: Temperature - Upper Critical - Going High
   0 | Pre-Init Time-stamp   | Temperature #0x30 | Upper Critical going high


命令发出后，我们就可以在 ipmitool sel list 输出中看到该错误已存储到服务器的系统事件日志中。
35aa | 04/12/2013 | 22:11:44 | Temperature #0x30 | Upper Critical going high


我们可以生成多种类型的人造硬件故障。ipmi event 命令将输出使用信息，如清单 11 所示。
usage: event <num>
   Send generic test events
   1 : Temperature - Upper Critical - Going High
   2 : Voltage Threshold - Lower Critical - Going Low
   3 : Memory - Correctable ECC

usage: event file <filename>
   Read and generate events from file
   Use the 'sel save' command to generate from SEL

usage: event <sensorid> <state> [event_dir]
   sensorid  : Sensor ID string to use for event data
   state     : Sensor state, use 'list' to see possible states for sensor
   event_dir : assert, deassert [default=assert]

清单 11

有关 ipmitool 的更多信息，请参见本文的“另请参见”部分。

使用 mcelog、mce-inject 和 mce-test 检测机器检查错误

可纠正和不可纠正的硬件错误统称为机器检查异常 (MCE)。CPU 自身能够纠正错误，并通知底层操作系统与 CPU 或缓存有关的问题。CPU 本身还能从某些错误中恢复。Oracle Linux 可将 mcelog 用作机器检查的日志子系统。首先，必须使用以下命令在服务器上安装软件包。
yum install mcelog.x86_64
service mcelogd start
chkconfig mcelogd on


mcelog 软件包有两种不同的工作方式，这取决于您所使用的 Oracle Linux 版本。在 Oracle Linux 6.0 及更高版本中，这由后台程序控制。在 Oracle Linux 早期版本中，/etc/cron.hourly/mcelog.cron 中的 cron 作业每小时检查 MCE 并将其保存到 /var/log/mcelog 中。由后台程序控制 mcelog 的方法更好一些，因为这样可以更快速地检测到硬件错误并立即记录下来，而不必等待 cron 作业运行。使用 mcelog 能检测到总线错误、内存错误和 CPU 缓存错误之类的错误，如果即将发生硬件故障，可以提前通知。

mcelog 能捕获两类错误：已纠正的 和未纠正的。已纠正的错误是由 CPU 处理的事件，可用来识别可能预测更大问题的趋势。

未纠正的错误是关键异常，如果 CPU 无法恢复，往往会导致系统上的内核错误。这会导致应用程序重置和中断。对于未纠正的错误，mcelog 捕获错误的能力取决于错误导致热重启还是硬重启。如果是热重启，信息会被 mcelog 捕获，恢复后可看到。硬重启会导致数据丢失，而且 mcelog 可能捕获不到该事件。

清单 12 中的示例显示的 mcelog 错误消息显示了 CPU 1 上一个已纠正的错误：
Hardware event. This is not a software error.
MCE 0
CPU 1 BANK 2
ADDR 1234
TIME 1364535025 Fri Mar 29 01:30:25 2013 MCG status:
MCi status:
Corrected error
Error enabled
MCi_ADDR register valid
MCA: No Error
STATUS 9400000000000000 MCGSTATUS 0
MCGCAP c07 APICID 1 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

清单 12

注意：以下信息适用于开发系统和测试系统，不适用于任何生产系统。

为了进行测试和故障排除，可以使用 mce-test 包生成假的硬件 MCE 事件并执行系统测试。本文的“另请参见”部分包含了 git 信息库和该软件包的项目页面的链接。

mce-test 软件包含丰富的默认测试，能模拟真实硬件故障，甚至会导致内核错误。需要执行几个配置步骤才能对系统进行此类测试。

首先，需要安装几个支持软件包才能在测试系统上配置 mce-test。使用以下命令：
yum install gcc.x86_64 gcc-c++.x86_64 flex.x86_64 dialog.x86_64 ras-utils.x86_64 git.x86_64

完成后，需要进行一些配置来加载 mce-test 在执行测试过程中会用到的内核模块。接下来介绍这些步骤。第一个命令加载 mce-inject 模块，第二个命令将该模块设置为在系统启动时自动加载。
modprobe mce-inject
echo "mce-inject" >> /etc/modules.conf 


要确保模块已加载，请使用以下命令。您将看到以下输出。
[root@test]# modprobe -l | grep mce-inject
kernel/arch/x86/kernel/cpu/mcheck/mce-inject.ko


加载了内核模块之后，应测试 mce-inject 以确保其正常工作。首先，创建一个文本文件，包含以下用于测试 mce-inject 的内容。
CPU 0 BANK 1
STATUS CORRECTED
ADDR 0xabcd
#
CPU 1 BANK 2
STATUS CORRECTED
ADDR 0x1234


创建了这个文本文件之后，您就可以通过向 mce-inject 提供文本文件路径来进行测试。
mce-inject <filename>


您应看到清单 13 中 /var/log/mcelog 所示的输出。
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 1
ADDR abcd
TIME 1371752847 Thu Jun 20 14:27:27 2013 MCG status:
MCi status:
Corrected error
Error enabled
MCi_ADDR register valid
MCA: No Error
STATUS 9400000000000000 MCGSTATUS 0
MCGCAP c07 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
Hardware event. This is not a software error.
MCE 0
CPU 1 BANK 2
ADDR 1234
TIME 1371752847 Thu Jun 20 14:27:27 2013 MCG status:
MCi status:
Corrected error
Error enabled
MCi_ADDR register valid
MCA: No Error
STATUS 9400000000000000 MCGSTATUS 0
MCGCAP c07 APICID 1 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

清单 13

可以通过文本文件提供输入的方式直接使用 mce-inject 可执行程序，但对于在系统上进行测试，功能更强的方法是使用 mce-test 程序。

您将需要通过 git 下载 mce-test 套件，如下例所示。
[root@test ~]# git clone https://github.com/andikleen/mce-test.git
Initialized empty Git repository in /root/mce-test/.git/
remote: Counting objects: 1768, done.
remote: Compressing objects: 100% (748/748), done.
remote: Total 1768 (delta 940), reused 1757 (delta 929) Receiving objects: 100% (1768/1768), 333.46 KiB, done.
Resolving deltas: 100% (940/940), done.


克隆 git 信息库之后，您就可以转到 mce-test 目录执行 mcemenu，这会转至 mce-test 工具主菜单（如图 1 所示）。
mce-test 实用程序的 Main Menu

图 1 — mce-test 实用程序的 Main Menu

我们要做的第一件事是编译测试套件，所以选择 Compile 选项编译该测试套件要用到的所有可执行文件。然后可以从 Execute 菜单中执行测试。测试运行后，可以使用 Results 菜单查看测试结果。mce-test/doc 目录下的文档包含了有关测试以及如何根据需要充分利用该套件的所有信息。

配置好软件包并了解哪些软件包提供您需要的结果后，您就可以生成一些有趣的 mcelog 异常，如清单 14 所示，其中有一些有趣的十六进制值。
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 2 TSC 4c060c5ce0
RIP 10:deadbabe
ADDR 1234
TIME 1364534147 Fri Mar 29 01:15:47 2013 MCG status:RIPV EIPV MCIP MCi status:
Error overflow
Uncorrected error
Error enabled
MCi_ADDR register valid
MCA: No Error
STATUS f400000000000000 MCGSTATUS 7
MCGCAP c07 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

清单 14

需要记住的是，测试除了将消息发送给系统控制台并且有可能发送给服务器的硬件系统事件日志外，还会影响 /var/log/mcelog 和 /var/log/messages。只能在开发系统上进行此类测试。有些 syslog 消息很有用，会表明 MCE 是假的。但其他消息让那些不知道测试的人看上去觉得很真实，他们可能认为有严重的硬件故障。以下是更明显的 syslog 条目示例。
Mar 29 01:15:48 test kernel: mce: [Hardware Error]: Fake kernel panic: Fatal Machine check

总结

本文简要介绍了 ipmitool、mcelog、mce-inject 和 mce-test 的基本特性。如本文前面所述，这些工具还有许多可供利用的特性和配置选项。本文旨在提供一个基本介绍和一些常见用例。在接下来的部分，您会发现更多资源以便更好地了解这些工具。本文提到的工具都能在 Oracle Linux 中使用，或者通过所提供的链接和参考轻松安装到 Oracle Linux 上。

另请参见

ipmitool 资源：
http://ipmitool.sourceforge.net/
http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html
http://docs.oracle.com/cd/E19469-01/820-6413-13/IPMI_Overview.html

mce-test 资源：
https://github.com/andikleen/mce-test
https://github.com/andikleen/mce-test.git

关于作者

Robert Chase 是 Oracle Linux 产品管理团队的一员。他从 1996 年开始涉足 Linux 和开源软件。他曾从事小型嵌入式设备和大型超级计算机级硬件的研究工作。