2024年5月27日发(作者：)

Machine check support in OS

1. 简介

Machine Check是硬件检查并解决一些内部错误的方式。传统的，当硬件发生错误时系

统将崩溃（crash）；当使用了Machine Check，则可以避免一些硬件错误导致的崩溃。

Machine Check有两类：

machine check exceptions (MCEs)和silent machine check.

1) 当发生硬件无法修正的错误时产生machine check exceptions (MCEs), 此时将使CPU中

断当前程序转而运行中断处理(exception handler)，由操作系统进行修复来解决;

2) Silent machine check则是CPU可以修正的硬件错误，正在运行的应用程序还可以继续执

行，但此时CPU将错误事件记录在专用的内部寄存器中。该事件在稍后可以被操作系统

或者firmware读取。Silent machine check并不要求立即停止当前运行的应用程序，但是

通过记录并分析Silent machine check事件，可能会推测出将会出现的后续硬件错误。

当操作系统没有machine check 处理程序时，machine check寄存器中的信息就永远不

会被清除。在下次热启动时，BIOS读取上次machine check信息，将它存到事件日志中。这

种方法有明显的缺点，那就是只有在机器重启后才进行记录，这样的话就不能记录多个同种

的错误，并且将错误信息传至网络和硬盘都是非常困难的。

将错误记录传至操作系统可以避免所有这些问题，即使这样也比较困难。大多数的Linu

x用户使用X window, 而控制台并不可见。这就意味着有可能handler记录了一个关键错误，

但是用户看不到，用户看到的只是一个不动X window。现在解决这个问题的办法是仅仅在

重启后才记录错误。

将machine check信息与其它软件错误区分开是非常重要的。因为如果不区分的话，用

户将无法判断是硬件错误还是软件错误。

2. Machine Check的作用(以集群系统为例)

芯片的发展方向是外形尺寸不断缩小、晶体管数量持续增加。这样就大大增加了错误产

生的概率。应用Linux的集群系统在科学计算领域越来越受欢迎。在集群系统中，将错误信

息集中起来呈现给系统管理员是很重要的。大量的处理单元使得产生错误的平均时间显著减

小，因此错误处理变得更加重要。

当一个节点发生硬件错误时，在该节点上运行的任务应当已经受到影响。解决这个问题

的一种方法是软件内部进行自检（比如缓存的校验和、内部检查算法）。但是这并不总是奏

效，并且需要程序员花费很大的精力。另外一种方法就是利用硬件检查发现。当内核记录了

一个未修复的硬件错误(uncorrected hardware error)时，集群软件可以采取必要的措施，如

将计算任务移至其他节点，并将错误信息返回给管理员。

记录硬件错误(logging hardware errors)使得预报故障称为了可能。这样就可以做一些处

理，从而减少进一步产生错误的可能。

Machine Check的来源可能有CPU,PCI IO,内存,caches,内部总线。这些错误可能是已修正

的错误(corrected error, 只有在寄存器中记录，不产生异常)，也有可能是未能修复的错误(u

ncorrected error, 产生异常，软件必须做出处理)。

当是PCI IO产生的machine check时，该错误也有可能是由于驱动程序中的软件错误引起

的。目前，在Linux环境下修复PCI硬件错误比较困难，因此一般只能选择重启计算机。

3. Machine Check处理的难点

不能使用任何的内核服务。Machine Check异常可能随时产生，即使在所有中断都关闭

的情况下。这样就使中断变得的不安全，从而可能产生死锁。

快速的处理machine check非常重要，因为产生一个硬件错误的机器可能已经不稳定。

如果没有及时将内核改为错误处理状态，则有可能永远无法处理。

不像其他的异常(exception)，machine check是异步的。也就是说CPU核并不是在产生错

误的当前指令运行时就报告错误，而是有可能在数百个时钟周期后才报告错误。这使得异常

处理不那么可靠。

4. 操作系统的责任

操作系统依靠与SAL

1

和PAL

2

进行交互得到machine check errors的信息从而进行进一步

的处理。

1) 产生CMC(Corrected Machine Check)时操作系统的责任

当接收到CMC中断时，操作系统应该在产生中断的处理器上用CMC的参数调用

SAL_GET_STATE_INFO 和SAL_CLEAR_STATE_INFO程序来读取和处理发生的错

误。错误被读取后，由SAL标记已经被处理过(consumed)的错误记录，而后清空存储资

源(由SAL_CLEAR_STATE_INFO完成)，可以进行下一次的错误记录。应当反复的调用

SAL_GET_STATE_INFO直到SAL向操作系统返回“No Information Available”。

2) 产生CPE(Corrected Platform Error)时操作系统的责任

当接收到CPE中断时，操作系统应该在产生中断的处理器上用CPE的参数调用

SAL_GET_STATE_INFO 和SAL_CLEAR_STATE_INFO程序来读取和处理发生的错误。

错误被读取后，由SAL标记已经被处理过(consumed)的错误记录，而后清空存储资源，

可以进行下一次的错误记录。应当反复的调用SAL_GET_STATE_INFO直到SAL向操作

系统返回“No Information Available”。

1

2

SAL：System Abstraction Layer

PAL：Processor Abstraction Layer