确定 Linux 内核恐慌的原因

Question 1

我有两个建议可以开始。

第一个你不会喜欢的。无论你认为你的超频系统有多稳定，它都是我的第一个怀疑对象。您向其报告问题的任何开发人员都会说同样的话。您的稳定测试工作负载不一定使用相同的指令，从而对内存子系统造成同样大的压力，无论如何。停止超频。如果你想让人们相信问题不是超频造成的，那就在不超频的时候让它发生，这样你就可以获得一份干净的错误报告。这将对其他人为解决这个问题投入多少努力产生巨大的影响。拥有无错误的软件是值得骄傲的一点，但是来自硬件设置特别有问题的人的报告会令人沮丧，浪费时间，而且可能根本不涉及真正的错误。

第二个是获取 oops 数据，正如您所注意到的，它不会到达您提到的任何地方。如果崩溃仅在运行 X11 时发生，我认为本地控制台几乎无法使用（无论如何这都很痛苦），因此您需要通过串行控制台、网络或保存到本地磁盘来执行此操作（这比较棘手）比听起来更好，因为您不希望不可信的内核损坏您的文件系统）。以下是一些方法：

使用网络转储通过网络保存到服务器。我已经很多年没有这样做了，所以我不确定这个软件是否仍然存在并且可以与现代内核一起使用，但它很简单，值得一试。
使用串行控制台启动（存档版本,当前版本）；您需要两台机器上都有一个可用的串行端口（无论是老式机器还是 USB 串行适配器）和一根零调制解调器电缆；您可以配置另一台机器来保存输出。
转储文件似乎是现在很酷的孩子使用的，并且看起来相当灵活，尽管这不是我的偏好，因为它看起来设置起来很复杂。简而言之，它涉及启动一个可以执行任何操作并检查前一个内核的内存内容的不同内核，但您必须基本上构建整个过程，而且我没有看到很多固定选项。 更新：实际上，有一些不错的发行版东西；在 Ubuntu 上，linux-crashdump (存档版本,当前版本）。

一旦获得调试信息，就会有一个名为 ksymoops 的工具（存档版本,当前版本^{（有广告）}），您可以使用它将地址转换为符号名称，并开始了解内核是如何崩溃的。如果符号化转储对您没有任何意义，至少在此处报告或在您的 Linux 发行版的邮件列表/错误跟踪器上报告是有帮助的。

从crash崩溃转储中，您可以尝试输入log并bt获取更多信息（在恐慌期间记录的内容和堆栈回溯）。你的Fatal Machine check似乎来自这里，尽管。通过浏览代码，您的处理器报告了机器检查异常– 硬件问题。同样，我的第一个赌注是由于超频。输出中似乎可能有更具体的消息log可以告诉您更多信息。

另外从该代码来看，如果您使用mce=3内核参数启动，它将停止崩溃......但我不会真正推荐这样做，除非作为诊断步骤。如果 Linux 内核认为这个错误值得崩溃，那么它可能是对的。

Answer

我有两个建议可以开始。

第一个你不会喜欢的。无论你认为你的超频系统有多稳定，它都是我的第一个怀疑对象。您向其报告问题的任何开发人员都会说同样的话。您的稳定测试工作负载不一定使用相同的指令，从而对内存子系统造成同样大的压力，无论如何。停止超频。如果你想让人们相信问题不是超频造成的，那就在不超频的时候让它发生，这样你就可以获得一份干净的错误报告。这将对其他人为解决这个问题投入多少努力产生巨大的影响。拥有无错误的软件是值得骄傲的一点，但是来自硬件设置特别有问题的人的报告会令人沮丧，浪费时间，而且可能根本不涉及真正的错误。

第二个是获取 oops 数据，正如您所注意到的，它不会到达您提到的任何地方。如果崩溃仅在运行 X11 时发生，我认为本地控制台几乎无法使用（无论如何这都很痛苦），因此您需要通过串行控制台、网络或保存到本地磁盘来执行此操作（这比较棘手）比听起来更好，因为您不希望不可信的内核损坏您的文件系统）。以下是一些方法：

使用网络转储通过网络保存到服务器。我已经很多年没有这样做了，所以我不确定这个软件是否仍然存在并且可以与现代内核一起使用，但它很简单，值得一试。
使用串行控制台启动（存档版本,当前版本）；您需要两台机器上都有一个可用的串行端口（无论是老式机器还是 USB 串行适配器）和一根零调制解调器电缆；您可以配置另一台机器来保存输出。
转储文件似乎是现在很酷的孩子使用的，并且看起来相当灵活，尽管这不是我的偏好，因为它看起来设置起来很复杂。简而言之，它涉及启动一个可以执行任何操作并检查前一个内核的内存内容的不同内核，但您必须基本上构建整个过程，而且我没有看到很多固定选项。 更新：实际上，有一些不错的发行版东西；在 Ubuntu 上，linux-crashdump (存档版本,当前版本）。

一旦获得调试信息，就会有一个名为 ksymoops 的工具（存档版本,当前版本^{（有广告）}），您可以使用它将地址转换为符号名称，并开始了解内核是如何崩溃的。如果符号化转储对您没有任何意义，至少在此处报告或在您的 Linux 发行版的邮件列表/错误跟踪器上报告是有帮助的。

从crash崩溃转储中，您可以尝试输入log并bt获取更多信息（在恐慌期间记录的内容和堆栈回溯）。你的Fatal Machine check似乎来自这里，尽管。通过浏览代码，您的处理器报告了机器检查异常– 硬件问题。同样，我的第一个赌注是由于超频。输出中似乎可能有更具体的消息log可以告诉您更多信息。

另外从该代码来看，如果您使用mce=3内核参数启动，它将停止崩溃......但我不会真正推荐这样做，除非作为诊断步骤。如果 Linux 内核认为这个错误值得崩溃，那么它可能是对的。

Question 2

a) 检查 rsyslog 守护进程是否将内核消息记录到文件中

vi /etc/rsyslog.conf

并添加以下内容

kern.*                 /var/log/kernel.log

重新启动rsyslog服务。

/etc/initd.d/rsyslog restart

b) 记下加载的模块

`lsmod >/your/home/dir`

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

d) 一旦发生紧急情况，使用 Live 或紧急 CD 启动系统

e) 挂载受影响系统的文件系统（如果 /var 和 /home 不是单独的文件系统，通常 / 就足够了）（如果您在受影响的系统上使用 LVM 来启动 LV，则需要运行 pvs命令vgs）lvsmount -t ext4 /dev/sdXN /mnt

f) 转到/mnt/var/log/目录并检查kernel.log文件。这应该为您提供足够的信息来确定特定模块或其他模块是否发生了紧急情况。

Answer