确定Linux内核崩溃的原因

我正在运行Ubuntu 12.04衍生产品（amd64），最近遇到了一些非常奇怪的问题。突然，X会完全冻结一段时间（1-3分钟？），然后系统将重新启动。该系统已超频，但如Windows中所验证的那样非常稳定，这使我相信我遇到了内核恐慌或某个模块有问题。即使在Linux中，我也可以运行LINPACK，即使在CPU上放置了可笑的负载也不会崩溃。即使机器闲置时，崩溃似乎也是随机发生的。

如何调试崩溃的系统？

由于可能是专有的NVIDIA驱动程序，我一路退缩到驱动程序的稳定版本304，但仍然遇到崩溃。

谁能在崩溃后指导我完成一个好的调试过程？我很乐意引导到拇指驱动器并发布所有我的崩溃后配置文件，但我不确定它们是什么。我如何找出导致系统崩溃的原因？

这是一堆原木，通常是罪魁祸首。

.xsession-errors：http : //pastebin.com/EEDtVkVm

/var/log/Xorg.0.log：http://pastebin.com/ftsG5VAn

/var/log/kern.log：http://pastebin.com/Hsy7jcHZ

/ var / log / syslog：http : //pastebin.com/9Fkp3FMz

我什至似乎都找不到崩溃的记录。

触发崩溃并非如此简单，它似乎是在GPU试图一次绘制多个物体时发生的。如果我全屏播放YouTube视频，让它重复一会儿，或者滚动浏览大量的GIF，然后会弹出Skype通知，则有时会崩溃。完全挠了我的脑袋。

CPU已超频至4.8GHz，但它是完全稳定的，并且在昨天的大型LINPACK运行和9个小时的Prime95中幸免了一次崩溃。

更新资料

我已经安装了kdump，，crash和linux-crashdump，以及我的内核版本3.2.0-35的内核调试符号。当我apport-unpack在崩溃的内核文件上运行，然后crash在VmCore崩溃转储上运行时，这是我看到的内容：

      KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-35-generic
    DUMPFILE: Downloads/crash/VmCore
        CPUS: 8
        DATE: Thu Jan 10 16:05:55 2013
      UPTIME: 00:26:04
LOAD AVERAGE: 2.20, 0.84, 0.49
       TASKS: 614
    NODENAME: mightymoose
     RELEASE: 3.2.0-35-generic
     VERSION: #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012
     MACHINE: x86_64  (3499 Mhz)
      MEMORY: 8 GB
       PANIC: "[ 1561.519960] Kernel panic - not syncing: Fatal Machine check"
         PID: 0
     COMMAND: "swapper/5"
        TASK: ffff880211251700  (1 of 8)  [THREAD_INFO: ffff880211260000]
         CPU: 5
       STATE: TASK_RUNNING (PANIC)

log从crash实用程序运行时，我在日志底部看到了这一点：

[ 1561.519943] [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000800400
[ 1561.519946] [Hardware Error]: RIP !INEXACT! 33:<00007fe99ae93e54> 
[ 1561.519948] [Hardware Error]: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 
[ 1561.519950] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28
[ 1561.519951] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519953] [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 3: be00000000800400
[ 1561.519955] [Hardware Error]: TSC 539b174de9d ADDR 3fe98d264ebd MISC 1 
[ 1561.519957] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 0 microcode 28
[ 1561.519958] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519959] [Hardware Error]: Machine check: Processor context corrupt
[ 1561.519960] Kernel panic - not syncing: Fatal Machine check
[ 1561.519962] Pid: 0, comm: swapper/5 Tainted: P   M     C O 3.2.0-35-generic #55-Ubuntu
[ 1561.519963] Call Trace:
[ 1561.519964]  <#MC>  [<ffffffff81644340>] panic+0x91/0x1a4
[ 1561.519971]  [<ffffffff8102abeb>] mce_panic.part.14+0x18b/0x1c0
[ 1561.519973]  [<ffffffff8102ac80>] mce_panic+0x60/0xb0
[ 1561.519975]  [<ffffffff8102aec4>] mce_reign+0x1f4/0x200
[ 1561.519977]  [<ffffffff8102b175>] mce_end+0xf5/0x100
[ 1561.519979]  [<ffffffff8102b92c>] do_machine_check+0x3fc/0x600
[ 1561.519982]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519984]  [<ffffffff8165d78c>] machine_check+0x1c/0x30
[ 1561.519986]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519987]  <<EOE>>  [<ffffffff81509697>] ? menu_select+0xe7/0x2c0
[ 1561.519991]  [<ffffffff815082d1>] cpuidle_idle_call+0xc1/0x280
[ 1561.519994]  [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 1561.519996]  [<ffffffff8163aa9a>] start_secondary+0xd9/0xdb

bt 输出回溯：

PID: 0      TASK: ffff880211251700  CPU: 5   COMMAND: "swapper/5"
 #0 [ffff88021ed4aba0] machine_kexec at ffffffff8103947a
 #1 [ffff88021ed4ac10] crash_kexec at ffffffff810b52c8
 #2 [ffff88021ed4ace0] panic at ffffffff81644347
 #3 [ffff88021ed4ad60] mce_panic.part.14 at ffffffff8102abeb
 #4 [ffff88021ed4adb0] mce_panic at ffffffff8102ac80
 #5 [ffff88021ed4ade0] mce_reign at ffffffff8102aec4
 #6 [ffff88021ed4ae40] mce_end at ffffffff8102b175
 #7 [ffff88021ed4ae70] do_machine_check at ffffffff8102b92c
 #8 [ffff88021ed4af50] machine_check at ffffffff8165d78c
    [exception RIP: intel_idle+191]
    RIP: ffffffff8136d48f  RSP: ffff880211261e38  RFLAGS: 00000046
    RAX: 0000000000000020  RBX: 0000000000000008  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: ffff880211261fd8  RDI: ffffffff81c12f00
    RBP: ffff880211261e98   R8: 00000000fffffffc   R9: 0000000000000f9f
    R10: 0000000000001e95  R11: 0000000000000000  R12: 0000000000000003
    R13: ffff88021ed5ac70  R14: 0000000000000020  R15: 12d818fb42cfe42b
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <MCE exception stack> ---
 #9 [ffff880211261e38] intel_idle at ffffffff8136d48f
#10 [ffff880211261ea0] cpuidle_idle_call at ffffffff815082d1
#11 [ffff880211261f00] cpu_idle at ffffffff8101322a

有任何想法吗？

我有两个建议要开始。

首先，您不会喜欢。无论您认为超频系统多么稳定，这都是我的第一个怀疑。与您报告问题的任何开发人员都会说同样的话。稳定的测试工作量不一定要使用相同的指令，无论如何，都会给内存子系统造成很大的压力。停止超频。如果您想让人们相信问题不是超频，请在不进行超频时使之发生，这样您就可以获得干净的错误报告。这将在其他人将花费多少精力来解决这个问题上产生巨大的影响。拥有无错误的软件是值得骄傲的一点，但是硬件设置特别令人质疑的人的报告令人沮丧，因为这些时间可能根本不涉及真正的错误。

第二个是获取oops数据，正如您所注意到的那样，它并没有到达您提到的任何地方。如果崩溃仅在运行X11时发生，我认为本地控制台已经用完了（无论如何，这很痛苦），因此您需要通过串行控制台，网络或保存到本地磁盘来完成此操作（比这听起来可能是因为您不希望不可信的内核破坏文件系统）。这里有一些方法可以做到这一点：

• 使用netdump通过网络保存到服务器。我已经好几年没有这样做了，所以我不确定该软件是否还在使用现代内核，但是很简单，值得一试。
• 使用串行控制台引导; 两台机器上都需要一个免费的串行端口（无论是老式的还是USB串行适配器），并且调制解调器电缆为空；您将配置另一台计算机以保存输出。
• kdump似乎是当今很酷的孩子所使用的东西，并且似乎非常灵活，尽管我不喜欢它，因为它看起来很复杂。简而言之，它涉及引导一个可以执行任何操作并检查前一个内核的内存内容的内核，但是您必须从根本上构建整个过程，而且我看不到很多固定的选项。更新：实际上有一些不错的发行版内容；在Ubuntu上，linux-crashdump

获得调试信息后，将有一个名为ksymoops的工具，您可以使用该工具将地址转换为符号名称，并开始了解内核如何崩溃。而且，如果符号转储对您没有任何意义，至少这对在此处或在Linux发行版的邮件列表/错误跟踪器中进行报告很有帮助。

从crash你的崩溃转储，你可以尝试打字log，并bt得到多一点信息（恐慌和在堆栈中的东西记录）。不过，您Fatal Machine check似乎来自这里。通过略读代码，您的处理器报告了计算机检查异常 -硬件问题。同样，我的第一个选择是超频。似乎log输出中可能有更具体的消息，可以告诉您更多信息。

同样从该代码看来，如果您使用mce=3内核参数启动，它将停止崩溃...但是除了诊断步骤之外，我不建议您这样做。如果Linux内核认为此错误值得崩溃，那可能是正确的。

a）检查rsyslog守护程序是否正在将内核消息记录到文件中

vi /etc/rsyslog.conf

并添加以下内容

kern.*                 /var/log/kernel.log

重新启动rsyslog服务。

/etc/initd.d/rsyslog restart

b）记下已加载的模块

`lsmod >/your/home/dir`

c）由于恐慌无法重现，请等待它发生

d）发生紧急情况后，请使用实时或紧急CD引导系统

E）挂载文件系统（通常为/，就足够了的/ var和/ home都没有独立的文件系统），受影响的系统（pvs，vgs，lvs命令需要，如果你正在使用受影响的系统上LVM运行，弹出LV） mount -t ext4 /dev/sdXN /mnt

f）转到/mnt/var/log/目录并检查kernel.log文件。这应该为您提供足够的信息，以弄清楚某个模块或其他问题是否正在发生紧急情况。

您的处理器超频了吗？今天，当我在BIOS的超频菜单中使用乘法器时，我遇到了同样的问题。大约20倍的各种乘数会导致这种情况发生。我将其降低到18.5倍（3.7 GHz），问题消失了。我认为这是主板/电源问题。

最肯定是处理器问题，请注意以下几行：TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [硬件错误]：处理器0：206a7时间1357862746 SOCKET 0 APIC 1微码28。处理器0是用于处理崩溃的内核（在多CPU系统中很重要），套接字0是有问题的处理器（尽管我假设您只有1）。是不是很糟糕，或者您注意到超频导致了故障。我知道您说过它是通过prime95进行的，但是由于我没有更多有关系统有多旧的信息，因此我要用几根吸管抓紧它，导热膏的外观如何，并检查一下以确保LGA（在CPU）看起来还好吗？我在考虑在LGA下方弯曲的针脚或某些糊剂。再次只是根源在这里。

如果那不能解决问题，您可以使用一些技巧来使用SMBIOS查找恐慌的确切发生地点，另一行（TSC 539b174de9d ADDR 3fe98d264ebd MISC 1）基本上是SMBIOS数据，可以显示崩溃发生的位置。当计算机启动后，在命令行运行中，回显“ TSC 539b174de9d ADDR 3fe98d264ebd MISC 1” | sudo mcelog --ascii --dmi来获取输出，这将告诉您这是硬件错误，甚至是它正在处理的DIMM，如果DIMM故障随每个故障跳来跳去，这也可能指向错误的DIMM或总线路径。崩溃，但这指向CPU。

我们在旧设备上安装了mikrotik路由器。风扇停止旋转，导致处理器变热。然后，路由器会不时地开始进入内核应急状态。更换CPU风扇后，一切正常。

由于您的计算机超频，这可能是一个原因。