解决内核恐慌的疑难解答--分析“`crash`”转储之后的下一步

Question

我正在运行一个带有英特尔i7 CPU的Ubuntu12.04机器。有时，它会完全冻结--机器和显示会持续一分钟左右，播放的音频(如果有播放的话)开始循环，然后重新启动。虽然这种情况通常发生在中等到高的负载下，但有时也会在没有运行的情况下发生。无论在BIOS中是否打开被提升为1600 MHz的Intel 1333 MHz设置，都会发生崩溃。我也没有碰过任何其他超频设置。以下是我迄今所做的一些显而易见的事情：

观测CPU温度

按照指南这里，我在机器上设置了温度仪表，然后运行watch sensors，这样我就可以连续读取CPU的温度。尽管所有的核在合理的温度下运行(~60-65度)，机器还是会结冰.

观察内存使用情况

这台机器有16 GB的RAM。尽管只有3GB的使用，它还是会结冰。

观测CPU利用率

如前所述，冻结更多地发生在负载下，但也发生在“空闲”。

所有这些明显的事情都没有指出问题所在，所以我按照指南这里来使用crash命令来帮助我诊断问题。

以下是在崩溃转储上运行crash的输出：

crash /usr/lib/debug/boot/vmlinux-3.2.0-58-generic ~/temp/crash2/VmCore

crash 6.1.6
Copyright (C) 2002-2013  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-58-generic
    DUMPFILE: /home/bryce/temp/crash2/VmCore
        CPUS: 8
        DATE: Mon Jan 20 19:29:26 2014
      UPTIME: 02:33:18
LOAD AVERAGE: 1.40, 0.93, 0.50
       TASKS: 579
    NODENAME: <node_name>
     RELEASE: 3.2.0-58-generic
     VERSION: #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013
     MACHINE: x86_64  (3499 Mhz)
      MEMORY: 16 GB
       PANIC: "[ 9180.518213] Kernel panic - not syncing: Fatal Machine check"
         PID: 0
     COMMAND: "swapper/1"
        TASK: ffff8804045e9700  (1 of 8)  [THREAD_INFO: ffff8804045e4000]
         CPU: 1
       STATE: TASK_RUNNING (PANIC)

以及在bt提示符下运行crash的结果：

crash> bt
PID: 0      TASK: ffff8804045e9700  CPU: 1   COMMAND: "swapper/1"
 #0 [ffff88041ec4aba0] machine_kexec at ffffffff8103943a
 #1 [ffff88041ec4ac10] crash_kexec at ffffffff810b58d8
 #2 [ffff88041ec4ace0] panic at ffffffff8164928c
 #3 [ffff88041ec4ad60] mce_panic at ffffffff8102ab0b
 #4 [ffff88041ec4adb0] mce_panic at ffffffff8102aba0
 #5 [ffff88041ec4ade0] mce_reign at ffffffff8102ade4
 #6 [ffff88041ec4ae40] mce_end at ffffffff8102b095
 #7 [ffff88041ec4ae70] do_machine_check at ffffffff8102b84c
 #8 [ffff88041ec4af50] machine_check at ffffffff8166254c
    [exception RIP: mwait_idle_with_hints+93]
    RIP: ffffffff8103109d  RSP: ffff8804045e5e38  RFLAGS: 00000046
    RAX: 0000000000000033  RBX: ffff88040009ba60  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: 0000000000000001  RDI: 0000000000000033
    RBP: ffff8804045e5e38   R8: ffff8804045e5fd8   R9: 0000000000000f85
    R10: 000000000000198f  R11: 0000000000000000  R12: 0000000000000002
    R13: ffff88040009b800  R14: ffff88040009b820  R15: 134b04c7ed0ea230
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <MCE exception stack> ---
 #9 [ffff8804045e5e38] mwait_idle_with_hints at ffffffff8103109d
#10 [ffff8804045e5e40] acpi_processor_ffh_cstate_enter at ffffffff810310e2
#11 [ffff8804045e5e50] acpi_idle_do_entry at ffffffff81399182
#12 [ffff8804045e5e60] acpi_idle_enter_simple at ffffffff813992d8
#13 [ffff8804045e5ea0] cpuidle_idle_call at ffffffff8150bd61
#14 [ffff8804045e5f00] cpu_idle at ffffffff8101322a

以及在log提示符下运行crash的结果(我只显示了文件的尾部，第一个显示的行在时间为4232.799，前面的上下文-错误详细信息开始于以下行)：

crash>log
[ 4232.799853] ath: Could not kill baseband RX
[ 9180.518188] [Hardware Error]: CPU 5: Machine Check Exception: 5 Bank 1: bf80000000000124
[ 9180.518191] [Hardware Error]: RIP !INEXACT! 10:<ffffffff8111fc4f> {__rmqueue+0x1f/0x4b0}
[ 9180.518196] [Hardware Error]: TSC 1d5211c92f0e ADDR 419801540 MISC 86 
[ 9180.518199] [Hardware Error]: PROCESSOR 0:306c3 TIME 1390210166 SOCKET 0 APIC 3 microcode 9
[ 9180.518200] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 9180.518202] [Hardware Error]: CPU 1: Machine Check Exception: 5 Bank 1: bf80000000000124
[ 9180.518204] [Hardware Error]: RIP !INEXACT! 10:<ffffffff8103109d> {mwait_idle_with_hints+0x5d/0x70}
[ 9180.518207] [Hardware Error]: TSC 1d5211c92ee8 ADDR 419801540 MISC 86 
[ 9180.518209] [Hardware Error]: PROCESSOR 0:306c3 TIME 1390210166 SOCKET 0 APIC 2 microcode 9
[ 9180.518210] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 9180.518211] [Hardware Error]: Machine check: Processor context corrupt
[ 9180.518213] Kernel panic - not syncing: Fatal Machine check
[ 9180.518215] Pid: 0, comm: swapper/1 Tainted: P   M       O 3.2.0-58-generic #88-Ubuntu
[ 9180.518216] Call Trace:
[ 9180.518217]  <#MC>  [<ffffffff81649285>] panic+0x91/0x1a4
[ 9180.518224]  [<ffffffff8102ab0b>] mce_panic.part.14+0x18b/0x1c0
[ 9180.518226]  [<ffffffff8102aba0>] mce_panic+0x60/0xb0
[ 9180.518228]  [<ffffffff8102ade4>] mce_reign+0x1f4/0x200
[ 9180.518230]  [<ffffffff8102b095>] mce_end+0xf5/0x100
[ 9180.518232]  [<ffffffff8102b84c>] do_machine_check+0x3fc/0x600
[ 9180.518234]  [<ffffffff8103109d>] ? mwait_idle_with_hints+0x5d/0x70
[ 9180.518237]  [<ffffffff8166254c>] machine_check+0x1c/0x30
[ 9180.518239]  [<ffffffff8103109d>] ? mwait_idle_with_hints+0x5d/0x70
[ 9180.518240]  <<EOE>>  [<ffffffff810310e2>] acpi_processor_ffh_cstate_enter+0x32/0x40
[ 9180.518244]  [<ffffffff81399182>] acpi_idle_do_entry+0x10/0x2b
[ 9180.518246]  [<ffffffff813992d8>] acpi_idle_enter_simple+0xaa/0x115
[ 9180.518249]  [<ffffffff8150bd61>] cpuidle_idle_call+0xc1/0x290
[ 9180.518252]  [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 9180.518255]  [<ffffffff8163fa12>] start_secondary+0xd9/0xdb

因此，考虑到这些信息，诊断这个问题的下一步是什么？

Answer 1

彼得首先带着一条评论来到这里，我不重复了，所以请看一下那个维基百科文章。

下面是mcelog对我说的话：

> mcelog --ascii

这是史丁写的。然后我切糊：

TSC 1d5211c92ee8 ADDR 419801540 MISC 86
PROCESSOR 0:306c3 TIME 1390210166 SOCKET 0 APIC 2 microcode 9

从你的日志里。这句话的意思是：

Hardware event. This is not a software error.
CPU 0 BANK 0 TSC 1d5211c92ee8 
TIME 1390210166 Mon Jan 20 04:29:26 2014
MCG status:
MCi status:
Machine check not valid
Corrected error
MCA: No Error
STATUS 0 MCGSTATUS 0
CPUID Vendor Intel Family 6 Model 60
SOCKET 0 APIC 2 microcode 9

但是，它需要对/dev/mem的许可，所以如果它需要从那里获取信息，它就不能进入我的系统，这可能不是全部事实。

一个容易诊断和修复的MCE将是坏的公羊。要正确检查这一点，可以使用记忆测试。Memtest是一个必须启动的裸金属程序(即，在没有操作系统的情况下自行运行)。我相信大多数的真人CD都开着--至少，我带着的那只软呢帽。这是grub菜单中的一个选项(?)当磁盘第一次加载时。一些BIOS也将其作为一种选择。

Answer 2

现在看来，将BIOS升级到最新版本已经解决了这个问题--这台机器在24小时的负载下还没有崩溃，这比平时要好得多。尽管如此，如果我的答案很快又崩溃了，我会收回我的答案。

对于后人来说，这是一个ASUS Z87专业主板.我不记得我更新过的BIOS版本号，但我相信它是2013年12月发布的(最迟在撰写本文时)。另外，为了记录在案，在更新BIOS之前，我从GRUB菜单中运行了memtest，这是@goldilocks在更新BIOS之前建议的，没有发现任何问题(不过，我只运行了一次)。

“peterph”和“goldilocks”的评论/回答都有助于从一开始就发现这可能是一个非软件问题。

不管怎样，问题似乎已经解决了，希望如此。