Linux中的mce问题

最新推荐文章于 2024-08-21 12:00:00 发布

legend050709ComeON

最新推荐文章于 2024-08-21 12:00:00 发布

阅读量5.8k

点赞数 2

分类专栏： Linux 命令/Shell脚本

原文链接：https://www.jianshu.com/p/7b3f89ee967c

版权

Linux 命令/Shell脚本专栏收录该内容

15 篇文章 2 订阅

订阅专栏

machine check 是什么？

machine check 是一种用来报告内部错误的一种硬件的方式。它包括 machine check exceptions 和 silent machine check。

其中，machine check exceptions(MCEs) 是在硬件不能纠正内部错误的时候发生，在这种情况下，通常会中断 CPU 当前正在运行的程序，并且调用一个特殊的异常处理程序。这种情况通常需要软件来进行处理，即 machine check exception handler。
当硬件能够纠正内部错误的时候，这种情况通常称作 silent machine check。当这种错误发生的时候，硬件会把相应的错误信息登记到特殊的寄存器中。之后，操作系统或者是固件（BIOS）就可以从这写寄存器中读取信息，登记和分析这些错误信息有助于提前预测机器硬件的故障。

Mce错误类型

MCE(Machine Check Exception)是由CPU侦测出来的错误，它错误包含两种主要类型：notice(提示)/warning(警告)，和fatal exception(致命性的错误)。Warning(警告)将会在你的系统log下输出一条类似于"Machine Check Event logged"的信息，我们可以通过一些linux的应用程序对这部分log进行详细的信息查看；而fatal MCE(致命的错误)会导致机器停止响应，MCE的详细信息也将会输出到系统的console中。

Mce错误原因

随着每一代芯片中晶体管数量的增加，以及芯片大小的减小，硬件发生错误的概率也在提高，因此能够处理这种错误变得越来越重要。

另外，现在将许多计算机集成在一起进行高性能的科学计算也越来越流行。这些集群的计算机中，发生硬件错误的概率将比普通的计算机发生错误的概率要高，因此，为了保证可靠性，处理这些硬件错误也是很重要的。

产生 machine checks 的原因很多，这些来源包括 CPU，缓存，内部总线，内存等等，当然也有可能是驱动中的软件错误。

常见原因有以下几种：

内存错误或ECC问题
冷却不足、CPU过热
系统总线错误
缓存处理器或硬件错误

为什么写一个 machine check 处理函数是困难的

因为当前的内核服务都不能被使用。我们知道内核代码可以运行在进程上下文和中断上下文，在中断上下文可以做的事情比进程上下文可以做的事情要少。在中断上下文调用的函数必须合适的保护了它的数据结构，防止来自多个中断的并发访问。这些函数被称为是“中断安全的”。

但是，我们知道 machine check exception 在任何时候都可能会发生，甚至在所有中断都被禁止的临界区中也有可能会发生。因此在这种情况下，如果在 machine check exception 处理函数中调用了这些中断安全的函数，就可能会死锁在自旋锁上。

由于为了让代码更加的简单， silent machine check 处理函数和 machine check exception 处理函数共享了同一条代码路径，因此上面所讨论的问题对于 silent machine check 处理函数同样适用。

同样，能够尽快的处理 machine check 也是非常重要的，因为在发生了一个硬件错误之后，机器的状态可能变得已经不太稳定了。当处理函数在等待机器进入一个更加容易被处理的状态的时候，这个事件可能会变得不能被处理。例如，在等待的时间内，在同一个 bank 上，又发生了另一个错误，这个错误就会覆盖之前的错误，并且变得不可处理。

对于一些复杂的 RAM 错误，处理函数除了等待就没有别的办法了，因为这要求和内核锁进行同步。不像其他的异常，machine check 是异步的。这就是说，CPU 报告的错误并不在发生错误的那条指令处，这可能已经过了几百个时钟周期，这就导致了处理的不可靠性。

登记 machine check

传统的，登记 machine check 是由固件来进行的（即BIOS），当操作系统没有 machine check 处理函数时，那些 MC 寄存器将不会被清零。在下一次热启动之后，BIOS将从最后一次 machine check 中找到信息，并登记到日志文件中。这种方式显然存在很多缺点，例如，必须在每次机器重新启动时才能够登记日志文件，不能够记录在同一个 bank 上发生的多个错误，在网络中收集信息和将日志写到磁盘是很困难的。

因此，最好的方法是将登记日志的任务交给操作系统，就可以解决这些问题。但是，当前大多数的 linux 用户使用的都是 X 界面，因此控制口是不可见的。当操作系统登记一个致命的 machine check 后，X 界面看起来就像是冻住了一样，不会响应用户。为了解决这个问题，这种致命的 machine check 都在机器重启时再登记。这也能够将日文件写道磁盘里，使后来的支持人员分析称为可能。

将 machine check 日志文件和软件错误日志文件分开是有必要的，因为用户可能分不清出这两种错误。经验表明，最好将这两种日志文件完全分开。

如何找出MCE错误对应的含义？

Linux系统下，如果在Console或者系统log中看到MCE的错误，可以运行mcelog命令从系统内核中读取详细的信息。需要注意的是，一旦运行了mcelog，我们将无法再通过这条命令去查询已经出现的错误，所以最好运行mcelog的时候讲文本输出到文件中以做进一步的分析，参考命令如下：#/usr/sbin/mcelog> mcelog.ou

有些系统会定期执行这个操作，并将文件输出到/var/log/mcelog中，因此，如果系统log中发现了MCE信息，但是使用mcelog查询不到任何数据时，可以试着查看/var/log/mcelog文件。

mcelog介绍

mcelog 是Linux 系统上用来检查硬件错误，特别是内存和CPU错误的工具。

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

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

mcelog相关文件

/dev/mcelog 设备文件
 /var/log/mcelog messages日志文件
 /etc/mcelog/mcelog.conf配置文件
 /var/run/mcelog.pid
 默认故障日志只记录在/var/log/mcelog，并不记录到系统日志中。
 如果需要在系统日志中也体现，需修改/etc/mcelog/mcelog.conf文件，将前面#去掉，并保存。

查看系统是否异常

（1）手动运行mcelog的方式：
[root@RedHat_test ~]# mcelog --daemon


（2）查看mcelog日志
[root@RedHat_test ~]# tail /var/log/mcelog
 # 什么也没有输出，表明正常

（3）查看mcelog守护进程是否检测到错误信息
[root@RedHat_test ~]# mcelog --client
 # 什么也没有输出，表明正常

（4）解析系统异常时的mcelog输出
[root@RedHat_test ~]# mcelog --ascii < file.log
 # or或者
 [root@RedHat_test ~]# mcelog --ascii --file file.log

致命的MCE错误导致机器停止响应后我们需要怎么办？

致命的MCE错误通常都是由硬件错误所引起的，我们通过重启设备重新进入系统后，首先需要查看系统log，一个典型的MCE相关的错误log如下：

CPU 1: Machine Check Exception: 4 Bank 4: f600200137080813

TSC b0ce27165dd3 ADDR 180ee1b40

这时我们可以通过mcelog去将这条error log的详细信息dump出来，命令如下：

root@localhost:/root> /usr/sbin/mcelog --ascii < myerror

得到的详细错误信息如下：

       HARDWARE ERROR. This is *NOT* a software problem!

       Please contact your hardware vendor

       CPU 1 4 northbridge TSC b0ce27165dd3

       Northbridge Chipkill ECC error

       Chipkill ECC syndrome = 3700

       bit32 = err cpu0

       bit45 = uncorrected ecc error

       bit57 = processor context corrupt

       bit61 = error uncorrected

       bit62 = error overflow (multiple errors)

       bus error 'local node origin, request didn't time out

       generic read mem transaction

       memory access, level generic'

       STATUS f600200137080813 MCGSTATUS 4

 这表示发生了Uncorrected ECC error，意味着其中一根内存模块出现了问题。