编译内核时出现 Signal 11 信号

本 FAQ 描述了最近困扰许多人的一个现象的可能原因。即，linux(*)-内核（或任何其他大型软件包）编译崩溃，并出现 “signal 11” 信号。原因可能是软件或（最有可能的）硬件。请继续阅读以了解更多信息。
(*) 当然，这并非 Linux 特有的问题。如果您的硬件不稳定，Linux、Windows 3.1、FreeBSD、Windows NT 和 NextStep 都会崩溃。
如果您不是在 http://www.BitWizard.nl/sig11/ 阅读此文档，那么您可以在那里找到最新版本。
对于那些喜欢阅读法语版本的人，法语翻译版本可以在 http://www.linux-france.org/article/sig11-fr/ 找到。
对于那些喜欢阅读日语版本的人，日语翻译版本可以在 http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ/ 找到。
如果您发现任何拼写错误、有价值的补充，或者有 “我也遇到了这种情况” 的故事，请发送电子邮件至 R.E.Wolff@BitWizard.nl。（请注意，我拒绝了一些我认为是技术上无稽之谈的建议）。如果您在主题中注明 “sig11” 或类似的字样，我将不胜感激。您也可以发送电子邮件给我关于其他主题。

Sig11 FAQ

问题

Signal 11，那是什么意思？

答案

Signal 11，或正式名称为 “段错误”（segmentation fault），意味着程序访问了未分配的内存位置。这通常是程序中的错误。因此，如果您正在编写自己的程序，这是最可能的原因。但是，本 FAQ 将重点关注除此之外的可能性。

问题

我的（内核）编译崩溃，并显示

      gcc: Internal compiler error: program cc1 got fatal signal 11

编译器有什么问题？我需要哪个版本的编译器？内核有问题吗？

答案

最有可能的是，您的安装、编译器或内核都没有问题。这很可能与您的硬件有关。可能存在各种子系统问题，并且有多种方法可以修复它。请继续阅读，您将了解更多信息。这个 “规则” 有两个例外。您可能正在耗尽虚拟内存，或者您可能正在安装 Red Hat 5.x、6.x 或 7.x。在结尾附近有更多关于这方面的内容。

问题

好的，可能不是软件问题，我如何才能确定？

答案

首先，让我们确保是硬件导致了您的麻烦。当 “make” 停止时，只需再次键入 “make”。如果它在停止之前又编译了一些文件，那一定是硬件在给您带来麻烦。如果它立即再次停止（即，在完全相同的地点崩溃之前，扫描一些目录并显示 “xxxx 无需执行任何操作”），请尝试

        dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS

将 HARD_DISK 更改为您的硬盘名称（例如 hda 或 sda。或使用 “df .”）。将 MEGS 更改为您拥有的主内存的兆字节数。这将导致从磁盘读取硬盘的前几个兆字节，从而迫使 C 源文件和 gcc 二进制文件在您下次运行时从磁盘重新读取。现在再次键入 make。如果它仍然在同一个地方停止，我开始怀疑您是否在阅读正确的 FAQ，因为它看起来毕竟像是一个软件问题...... 请看一下 “还有哪些其他可能性” 的问题...... 如果没有这个 “dd” 命令，编译器一直停留在同一个地方，但是在您使用 “dd” 之后移动到另一个地方，那么您肯定遇到了磁盘 -> 内存传输问题。

问题

这到底意味着什么？您确定这是硬件问题吗？

答案

嗯，编译器访问了其内存范围之外的内存。如果这发生在工作正常的硬件上，那就是编译器内部的编程错误。这就是为什么它显示 “internal compiler error”（内部编译器错误）。但是，当硬件偶尔翻转一位时，gcc 使用了如此多的指针，以至于很可能最终访问到其寻址范围之外的东西。（随机地址大多在您的寻址范围之外，因为没有多少人拥有 4G 的大部分作为主内存... :-) 似乎现在，所有遇到 “signal 11” 问题的人都被引导到此页面。如果您正在开发自己的软件或有尚未充分调试的软件，“signal 11”（或段错误）仍然强烈暗示程序存在问题。只有当像 “gcc” 这样的程序对于几乎所有人都能正常工作，却在一个数据集（例如 Linux 内核）上崩溃时，而该数据集也经过了充分测试，那么这才会暗示您的硬件存在问题。如果系统中的某些软件组件（例如硬件驱动程序）损坏，则可能导致非常接近硬件故障的症状。但是，当驱动程序出现故障时，更可能在内核内部引起严重问题，而不仅仅是导致编译器崩溃。

问题

好的。我可能遇到了硬件问题，那会是什么呢？

答案

如果是硬件问题，则可能是

主内存。您的主内存可能偶尔会出现一位错误。如果这发生在 “写入” 操作中，您将看不到任何奇偶校验错误。有几种方法可以解决它
- 内存速度可能太慢。在 BIOS 中增加等待状态的数量。
  这可能是由 AMIBIOS 的自动配置选项引起的：它可能只了解运行速度高达 80 MHz 的 486，而您目前购买的是 100 MHz 版本。-- Pat V.
- 内存速度可能太慢。获取更快的 DRAM SIMM。例如，如果您的处理器为 100 或 133 MHz，则当前 ASUS 主板需要 60 ns DRAM（请查看您的主板手册）。我听说 70 ns 也可以工作，但像随机 sig11 这样的可靠性问题是有可能发生的......（我不会冒险）-- Andrew Eskilsson (mpt95aes@pt.hk-r.se)
- 您可能会认为您可以以 100MHz 运行您的 100MHz SDRAM。错了！阅读 http://www.bitwizard.nl/sig11/sdram.html，了解为什么我认为是这种情况。您至少需要比其额定速度快一个速度等级的内存。
- 其中一个 SIMM 上有一个坏芯片。如果您拥有超过 1 个内存库，您可能可以拔出 SIMM 并查看问题是否消失。小心静电！！！
- 上周我们处理了一个棘手的问题。事实证明，所有 4 个 16Mb SIMM 都是坏的，因为它们大约每小时会丢失一位。这足以在大约一天内使机器崩溃，或在大约一小时内使内核编译崩溃。一套新的 SIMM 工作完美。诊断出这个问题花了很长时间，因为所有 4 个 SIMM 都受到同样的影响，因此去掉一半内存并没有改变任何事情。
  Mark Kettner (kettner@cat.et.tudelft.nl) 报告说，他的系统能够毫无错误地运行我的内存测试 2300 次，但随后检测到大约 10 个错误。然后，它又连续数百次运行没有检测到错误...... 在他的案例中，运行内核编译是检测系统健康状况的更有效方法（在最稳定的配置中，系统可以在崩溃之前编译大约 14 个内核）。他的解决方案是 “换回” 旧内存，以获得所谓的 “内存升级”。店主然后在他们的内存测试仪中 “测试”，结果内存是 “OK” 的。然后他获得了新内存的良好折扣 :-)。
- 似乎一些 30-72 针转换器可能会导致内存错误。（看看这个条目有多旧？谁还记得 30 针 SIMM？但是，所有这些都完全适用于 SIMM <-> DIMM 转换器，或 socket370 <-> slot 1 转换器）（尚未证实是转换器中的 4 个 SIMM 坏了，还是 SIMM 转换器有问题。SIMM 在移动到转换器之前已经完美运行了多年......）-- Naresh Sharma (n.sharma@is.twi.tudelft.nl)。Paul Gortmaker (paul.gortmaker@anu.edu.au) 补充说，SIMM 转换器应至少有 4 个旁路电容器，以保持 SIMM 的电源干净。
- 如果 DRAM 的刷新功能无法正常工作，DRAM 将缓慢丢失其信息。当您打开 “隐藏刷新” 时，一些 (486) 主板会停止正确刷新。似乎有一个名为 “dram” 的程序，也可能会弄乱您的刷新，从而导致 sig11 问题。-- Hank Barta (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
- 等待状态的数量可能太低。在 BIOS 中增加等待状态的数量以进行修复。英特尔 Endeavour 主板不允许您增加内存等待状态。据称可以通过将 MR BIOS 刷新到主板上来修复此问题。-- David Halls (david.halls@cl.cam.ac.uk)
缓存内存。您的缓存内存可能偶尔会出现一位错误。缓存通常未配备奇偶校验。您可以通过在 BIOS 中关闭缓存来诊断是否是这种情况。如果问题消失，则可能是缓存问题。有几种方法可以解决它
- 缓存内存速度可能太慢。在 BIOS 中增加等待状态的数量。
- 缓存内存速度可能太慢。获取更快的 SRAM 芯片。
- 您的缓存中有一个坏芯片。您不太可能像更换 SIMM 那样容易地更换芯片。小心静电！！！-- Joseph Barone (barone@mntr02.psf.ge.com)
- 缓存可能设置为 “回写”，而您的芯片组的回写实现中存在错误。发生这种情况的主板是 “MV020 486VL3H”（具有 20M 内存）-- Scott Brumbaugh (scottb@borris.beachnet.com)（邮件地址无效。Scott：请提供有效的回复地址）
- 主板可能需要跳线来在板载缓存和老式的 DIP 芯片缓存之间切换。（Rev 2.4 ASUS P/I-P55TP4XE 主板上的 JP16）
磁盘传输。来自磁盘的块可能偶尔会发生一位错误。
- 如果您遇到此问题，您最有可能需要执行 “dd” 命令来将问题从一个位置 “移动” 到另一个位置......
- 一些 IDE 硬盘无法处理 “irq_unmasking” 选项。这可能只在负载下显示出来。并且可能显示为 sig11。
- 您有 kalok 31xx 吗？把它扔进垃圾桶。（或卖给 DOS 用户。更新：多年来没有听说过 kalok 了。他们可能倒闭了。顺便说一句，这些驱动器也不适用于 W95。）
- SCSI？终端？短总线可能仍然可以使用（不可靠）。长总线可能无论如何都会出错。您可以在主机和磁盘上打开奇偶校验吗？
CPU 本身。某些批次的处理器中，恰好是 “坏的” 处理器的百分比要高得多。几年前：最初的 Intel-Pentium-120。几年前 AMD K6/2-300（1998 年，在第 34 周到第 39 周生产！）。最近是 AMD K6/2-450。有些人可能会认为 400MHz 对他们来说是可以接受的，但是如果这被证明是问题所在，您有权获得一个新的处理器。去您购买的地方更换它。（忘记那些 P120，不值得麻烦... ;-) -- Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr)。
CPU 本身。某些批次的 K6 处理器只是存在设计缺陷。阅读 http://www.multimania.com/poulot/k6bug.html，然后确保更换您的 K6。-- Rongen (rongen@istar.ca)。
超频。Cyrix P-166 处理器以 133MHz 运行，而不是 166MHz。这对于 Cyrix 的人来说一定是合乎逻辑的，但对于其他人来说则不然。如果您以 166Mhz 运行它们，您就是在超频它们......
超频。一些供应商（或个人）认为可以超频某些 CPU。其中一些可能有效，另一些则无效。您可能想尝试关闭 turbo（请注意，大多数奔腾主板不再支持非 turbo 模式），看看问题是否消失。检查您的 CPU 速度（印在上面，必要时小心地取下风扇）与主板跳线或 BIOS 设置所说的速度相比...... 似乎即使英特尔也可能在这个领域犯错误。我现在有几个可靠的报告说，官方奔腾会在其额定速度下出现 sig11，但在较低速度下则不会。至于某些速度，主板对于较慢的处理器速度只会承受更大的压力（120 MHz -> 主板以 60MHz 运行，100MHz -> 主板以 66MHz 运行），我认为这不太可能与主板有关。此外，一个新的 120MHz 处理器现在运行正常。-- Samuel Ramac (sramac@vnet.ibm.com)。这并非英特尔或其任何竞争对手所独有。
CPU 温度。如果没有正确的散热器，高速处理器可能会过热。这也可能是由风扇故障引起的。（我个人的 '486 有一个风扇，需要几分钟才能加速到全速。它可能永远不会真正坏掉，因为它现在已经退役了 :-)。如果通过编译内核 “推动” CPU，CPU 可能会变得不稳定。如果您在 LILO 命令行上禁用 “HALT”，则此问题会变得更糟。当系统空闲时，Linux 尝试通过执行 “halt” 指令来关闭 CPU 电源。这可以节省电力，因此当系统空闲时，CPU 温度会下降。因此，您可能在简单编辑时不会注意到此问题，并且它可能仅在环境温度较高时，在 CPU 密集型工作数小时后才会浮出水面。如果您有带有 Fdiv 错误的奔腾，建议您在英特尔处换货。他们会给您发送一个新的，预先配置了英特尔官方认可的风扇的 CPU。另请注意，大多数普通胶水是非常糟糕的导热体。有一种特殊的导热胶可用，当需要将风扇粘合到 CPU 时应使用它。-- Arno Griffioen (arno@ixe.net), -- W. Paul Mills (wpmills@midusa.net) -- Alan Wind (wind@imada.ou.dk)
英特尔表示，CPU 外部允许的温度范围是
0 至 +85 C：Intel486 SX、Intel486 DX、IntelDX2、IntelDX4 处理器
0 至 +95 C：IntelDX2、IntelDX4 OverDrive® 处理器
0 至 +80 C：60 MHz 奔腾® 处理器
0 至 +70 C：66 至 166 MHz 奔腾处理器
有关如何测量此温度以及对我在此处所说内容的一些确认，请参阅： http://pentium.intel.com/procs/support/faqs/iarcfaq.htm（尤其是问题 Q5、Q6 和 Q12。该文档正变得稍微过时，但仍然非常准确。似乎问题也时不时地会移动一下。）
CPU 电压。一些主板允许您选择 CPU 电压。一些主板对管理此电压的跳线设置记录不佳。似乎 5V 处理器在 3.3 伏电压下仍然可以在大多数时间工作...... -- Karl Heyes (krheyes@comp.brad.ac.uk)
RAM 电压。似乎供应商正在为 3.3V RAM 做准备。现在大多数内存都是 3.3V。（但如果您有一个能够设置 RAM 电压的主板，请小心：3.3v RAM 在 5V 下会损坏......）（听到关于这方面的消息很少，我认为开关一定是自动的。）
局部总线过载。在 25 MHz 时，您最多可以有 3 个 VesaLocalBus (VLB) 卡，在 33MHz 时最多只能有两个，在 40MHz 时只能有一个，猜猜在 50MHz 时什么都没有！ (即，您可以使用 50MHz 局部总线运行您的系统，但您不允许使用任何 VLB 卡）。当您使 VLB 过载时，某些系统开始表现不稳定。即使您的 VLB 没有过载（超出上述限制），系统也可能会因添加额外的 VLB 卡而损失几纳秒的裕量，因此在添加新的 VLB 卡后，您可能需要添加缓存等待状态或其他状态...... -- Richard Postgate (postgate@cafe.net)
电源管理。一些笔记本电脑（以及现在的 “绿色” PC）具有电源管理功能。这些功能可能会干扰 Linux。一项功能可能会将内存映像保存到硬盘，并在您按下某个键时恢复 RAM。这听起来很有趣，但 Linux 设备驱动程序不希望硬件在两次访问之间被关闭。有些可能会恢复，但有些则不会。尝试关闭它，或在您的内核中启用 “APM 支持”。-- Elizabeth Ayer (eca23@cam.ac.uk)
灰尘堆积。一些灰尘可能会导电并产生微弱的短路。它可能会增加某些地方的电容，并降低计时特性。它可能会阻碍热流，并导致组件过热。它甚至可能会使跳线连接短路！我建议每年左右，最好打开您的计算机，并吸尘内部。提示：那些棉签棒有助于将灰尘从难以接近的角落中戳出来... -- Craig Graham (c_graham@hinge.mistral.co.uk)
CPU 本身。几个人报告说，他们没有找到任何可以责怪的东西，除了 CPU。这也可能是 CPU 和主板之间的不兼容。关于英特尔 CPU 的一系列报告已经过去（1997 年 2 月）。新一波报告正在涌入，指责 Cyrix/IBM 6x86 CPU。虽然它确实可能是 CPU，但也可能是您的主板与您的 CPU 不兼容。至少我见过一份主板手册提到它与较旧的 6x86 不兼容。我自己的经验是，这些设备一点也不差，并且在内核编译中，我将 P166+ 基准测试为等同于 P155（比 P120 快 1.3 倍）。

内存空洞。许多现代主板允许您使用带有 1MB 或 2MB 线性帧缓冲区的旧 ISA 视频卡。为了实现这一点，他们必须映射出 16Mb 以下的内存。实际上没有人使用过此功能，但是如果您打开内存空洞（或某些 BIOS 中的 LFB 支持），您的机器肯定会不稳定...... -- Paul Connolly (pconnolly@macdux.com.au)

微代码。尤其是在 SMP 系统上，CPU 可能需要升级。自从奔腾部门灾难以来，英特尔的 CPU 已经可以现场升级了！CPU 可以通过 BIOS 的特殊指令提升几个版本。这些升级通常随您的 BIOS 一起提供，因此请确保您运行的是最新的 BIOS，尤其是在您拥有 SMP 系统的情况下。-- Jeffrey Friedl (电子邮件已隐藏)。

问题

RAM 时序问题？我一个多月前摆弄过 bios 设置。在那段时间里，我已经编译了无数个内核，没有任何问题。不可能是 RAM 时序，对吧？

答案

错了。您是否认为 RAM 制造商有一台制造 60ns RAM 的机器和另一台制造 70ns RAM 的机器？当然不是！他们制造一批，然后测试它们。有些符合 60 ns 的规格，有些则不符合。如果制造商必须给出一个数字，那些可能是 61 ns。在这种情况下，当例如温度低于 40 摄氏度时（芯片在温度升高时会变慢。这就是为什么一些超级计算机需要如此多的冷却），它很可能在您的计算机中工作。

然而，“夏季的到来” 或长时间的编译作业可能会将计算机内部的温度推高到 “极限” 以上。-- Philippe Troin (ptroin@compass-da.com)

问题

我被忽悠了，没有购买 ECC 内存，因为它稍微便宜一些。我觉得自己像个傻瓜。我应该购买更昂贵的 ECC 内存。对吗？

答案

购买更昂贵的 ECC 内存和主板可以保护您免受某种类型的错误的影响：那些由通过阿尔法粒子随机发生的错误。
因为大多数人可以在半小时内使用 “gcc” 重现 “signal 11” 问题，但不能通过连续数小时的内存测试来重现它们，这向我证明它不仅仅是随机的阿尔法粒子翻转一位。内存测试也会注意到这一点。这意味着还有其他原因。我的印象是，大多数 sig11 问题是由 CPU <-> 缓存 <-> 内存路径上的时序错误引起的。在这种情况下，主内存上的 ECC 对您没有帮助。您应该何时购买 ECC？ a) 当您觉得您需要它时。 b) 当您有大量 RAM 时。（为什么没有截止数字？因为截止数字随时间变化，就像 “大量” 一样。）有些人强烈认为每个人都应该使用 ECC 内存。我将他们指向理由 “a)”。

问题

内存问题？我的 BIOS 测试我的内存并告诉我它没问题。我有一个花哨的 DOS 程序告诉我我的内存没问题。不可能是内存问题，对吧？

答案

错了。BIOS 中的内存测试完全没用。它甚至可能偶尔确认比实际可用的内存更多的内存是 “OK” 的，更不用说测试它是否良好了。
我的一个朋友曾经有一台 640k PC（是的，那是很久以前的事了），它在第二个 256k 库中有一个 64kbit 芯片而不是 256kbit 芯片。这意味着他实际上有 320k 工作内存。有时 BIOS 会将 384k 测试为 “OK”。无论如何，只有某些应用程序会失败。很难诊断出实际问题......
大多数内存问题仅在特殊情况下发生。这些情况几乎不为人知。gcc 似乎会触发它们。一些内存测试，尤其是 BIOS 内存测试，则不会。我不再致力于创建一张软盘，其中包含 Linux 内核和一个好的内存测试程序。别再烦我了......
原因是内存测试会导致 CPU 只执行一些指令，并且内存访问模式往往非常规则。在这些情况下，只有非常小一部分内存会崩溃。如果您正在学习电气工程并且对内存测试感兴趣，硕士论文可能是弄清楚发生了什么。有些计算机制造商希望赞助这样一个项目，并提供一些客户声称不可靠，但未通过生产测试的硬件......

问题

它只会在我编译内核时发生吗？

答案

不是。您的硬件不可能知道您正在编译内核。只是内核编译对您的硬件要求非常高，因此当您编译内核时，这种情况发生得很多。编译其他大型软件包（如 gcc 或 glibc）也经常会触发 sig11。

例如，人们在使用 slackware 安装脚本进行安装时，看到了 “随机” 崩溃...... -- dhn@pluto.njcc.com
其他人从内核获得 “general protection errors”（一般保护错误）（带有崩溃转储）。这些通常在 /var/adm/messages 中。-- fox@graphics.cs.nyu.edu
有些人看到 bzip2 崩溃，并显示 “signal 11” 或 “internal assertion failure (#1007)”。Bzip2 经过了相当好的测试，因此如果它崩溃，则很可能不是 bzip2 中的错误。-- Julian Seward (jseward@acm.org)

问题

NT、Windows 95、OS/2 或 DOS 上没有任何崩溃。一定是 Linux 特有的问题。

答案

首先，Linux 比上述所有系统都更强调您的硬件。某些操作系统（如上面命名的 Microsoft 操作系统）无论如何都会以不可预测的方式崩溃。没有人会打电话给微软说 “嘿，我的 Windows 电脑今天崩溃了”。如果您真的这样做了，他们会告诉您，是您（用户）犯了一个错误（请参阅德国杂志对 Bill Gates 的采访....），并且由于它现在可以工作了，您应该闭嘴。
这些操作系统也比 Linux 在某种程度上更 “可预测”。这意味着 Excel 可能始终加载在完全相同的内存区域中。因此，当位错误发生时，总是 Excel 会受到影响。Excel 将崩溃。或者 Excel 将使另一个应用程序崩溃。无论如何，它似乎是一个应用程序失败，并且与内存无关。
我可以肯定的是，干净安装的 Linux 系统应该能够编译内核而没有任何错误。当然没有 sig-11 错误。（** 例外：带有 Cyrix 处理器的 Red Hat 5.0。请参阅其他地方。**）
实际上，Linux 和 gcc 比其他操作系统更强调您的硬件。如果您需要一个非 Linux 的东西来强调您的硬件到崩溃的地步，您可以尝试 winstone。-- Jonathan Bright (bright@informix.com)

问题

总是 signal 11 吗？

答案

不是。其他信号（如 4、6 和 7）也偶尔会发生。但是，Signal 11 最常见。

只要内存被破坏，任何事情都可能发生。我本以为坏的二进制文件会比实际发生的频率高得多。无论如何，似乎赔率严重偏向于 gcc 获得 signal 11。也见过

free_one_pmd: bad directory entry 00000008
EXT2-fs warning (device 08:14): ext_2_free_blocks bit already cleared for block 127916
Internal error: bad swap device
Trying to free nonexistent swap-page
kfree of non-kmalloced memory ...
scsi0: REQ before WAIT DISCONNECT IID
Unable to handle kernel NULL pointer dereference at virtual address c0000004
put_page: page already exists 00000046
invalid operand: 0000
Whee.. inode changed from under us. Tell Linus
crc error -- System halted (在解压缩 Linux 内核期间)
Segmentation fault
“unable to resolve symbol”
make [1]: *** [sub_dirs] Error 139
make: *** [linuxsubdirs] Error 1
X Window 系统可能会以 “caught signal xx” 终止

前几个是内核 “怀疑” 内核编程错误的情况，而实际上是由坏内存引起的。后几个指向最终遇到麻烦的应用程序。

-- S.G.de Marinis (trance@interseg.it)
-- Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)

问题

我该怎么办？

答案

以下是一些在您想找出问题所在时可以尝试的事项... 注意：其中一些会显着降低您的计算机速度。这些事情旨在使您的计算机正常运行，并使您能够缩小问题范围。有了这些信息，例如，您可以尝试让您的供应商更换有故障的组件。

跳线主板以降低 CPU 和总线速度。
进入 BIOS 并告诉它 “加载 BIOS 默认值”。确保您事先写下磁盘驱动器设置。
禁用缓存 (BIOS)（或将其拔出，如果它在 “条状物” 上）。
使用 “linux mem=4M” 引导内核（禁用 4Mb 以上的内存）。
尝试取出一半内存。依次尝试两半。
摆弄刷新的设置 (BIOS)
尝试从其他人那里借用内存。最好是可以在另一台机器中完美运行 Linux 的内存...（Silicon graphics Indy 机器也是借用内存的好目标）
如果您想验证解决方案是否真的有效，请尝试以下脚本
```
   #!/bin/sh
   #set -x
   t=1
   while [ -f log.$t ] 
     do
     t=`expr $t + 1`
   done

   while true
     do
     make clean
     make -k bzImage > log.$t
     t=`expr $t + 1`
   done
```
所有生成的日志文件都应该相同（即，相同的大小和相同的内容）。在配备 512Mb 内存的 1GHz Athlon 上，每次内核构建大约需要 4 分钟。（在配备 4Mb 内存的 386 上大约需要 3 个月 :-)。
另一种测试当前设置是否稳定的方法可能是对不同大小的文件运行 “md5sum”（dd if=/dev/random of=testfile bs=1024k count=）。如果您使用的文件大小是 RAM 的两倍，您将锻炼您的磁盘。如果您使用的文件比您的 RAM 小 4 到 10 Mb，您将锻炼您的 RAM/CPU。
但是，此方法是否能捕获所有可能的问题尚不确定。Gcc 以不同的顺序执行许多不同的指令，而 md5sum 可能根本无法命中 gcc 执行的正确指令序列。但是，如果 md5sum 导致错误，则它可能会比内核编译更快地做到这一点。-- Rob Ludwick (rob@no-spam)

最困难的部分是，大多数人将能够完成上述所有操作，除了从其他人那里借用内存，但这并没有什么区别。这使得它很可能是 RAM。目前，RAM 是 PC 中最昂贵的部分，因此您宁愿不做出这个结论，但很抱歉，我收到了很多最终证明是 RAM 的反应。但是，不要立即绝望：您的 RAM 可能并非完全浪费：您可以随时尝试将其换成不同的或更多的 RAM。

问题

我已经让 RAM 测试设备测试了我的 RAM，它们是 OK 的。不可能是 RAM，对吧？

答案

错了。似乎当前 RAM 中发生的错误无法被 RAM 测试仪检测到。可能是您的主板正在以可疑的方式访问 RAM，或者以其他方式在您的计算机中弄乱 RAM。好处是您可以将 RAM 卖给仍然对他的 RAM 测试仪有信心的人......

问题

还有哪些其他硬件可能是问题所在？

答案

嗯，您计算机内部的任何硬件问题。但是，应该首先检查容易检查的东西。因此，例如，您的所有卡都应正确插入主板。

问题

为什么 Red Hat 安装在我的机器上崩溃？

答案

Red Hat 5.x、6.x 和 7.x 安装在某些机器上存在问题。尝试仅使用 32M 运行安装。通常可以使用 mem=32m 作为引导参数来完成此操作。

可能是 CD 上存在读取错误。安装程序对此处理得不太完美...... 确保您的 CD 完美无瑕！似乎安装程序会在质量不佳的 CD 上崩溃！

人们报告说，并且我亲眼所见，Red Hat 安装可能会在完全正常的机器上出错（崩溃并显示 signal 7 或 signal 11）。我的机器过去并且现在仍然 100% 可靠（实际上，我测试它的机器现在已经可靠地坏了）。人们通过擦除旧的 “工作正常” 的发行版而陷入困境，然后想要安装更新的 Red Hat 发行版。然后返回不再是一种选择，因为返回到 5.x 也会导致相同的 “安装时崩溃”。

Patrick Haley (haleyp@austin.rr.com) 报告说，他尝试了高达 96Mb (32 & 64) 的所有内存配置，并且发现只有当他安装了 96Mb 时，安装才会工作。这也与我自己的经验（Red Hat 安装失败）一致：我在一台 32M 机器上尝试了安装。

新消息：似乎这可能是由于内核问题造成的。内核可能（暂时）内存不足并杀死当前进程。Hubert Mantel (mantel@suse.de) 的修复程序位于： http://juanjox.linuxhq.com/patch/20-p0459.html。

如果实际情况如此，请尝试切换到第二个虚拟控制台 (ctrl-alt-F2) 并在那里每隔几秒钟键入 “sync”。这减少了硬盘缓冲区占用的内存量... 如果您看到 Red Hat 安装连续崩溃两次或更多次，然后能够使用此技巧完成安装，我将非常感谢您的反馈！！！

您如何解决这个问题？...

使用 SuSE。它更好：它在安装过程中不会崩溃。（而且，它实际上确实更好。;-)
也许您遇到了 CD 上的坏块。这可能是驱动器相关的。如果是这种情况，请尝试在另一个驱动器中复制 CD。尝试借用别人的 Red Hat 副本。
尝试配置千兆字节的交换空间。我有两个独立的报告说，他们通过千兆字节的交换空间完成了安装。如果它有帮助，请向我报告！
修改硬盘的 “设置”。在 BIOS 中将设置从 “LBA” 更改为 “NORMAL” 对至少一个人有所帮助。如果您尝试这样做，如果您发送电子邮件给我，我将非常感谢：我想听听它是否有帮助（以及您确切更改了什么使其工作）。
我的机器通过安装最小的基本系统，然后将软件包添加到已安装的系统来完成安装。
有人建议，当这种情况发生时，机器可能内存不足。尝试准备一个交换分区。此外，安装程序可能 “准备” 好处理低内存情况，但误判了情况。例如，它可能会加载 RAMDISK，仅留下 1M 的可用 RAM，然后尝试加载 2M 的应用程序。因此，如果您有 16M 的 RAM，使用 mem=14M 引导实际上可能会有所帮助，因为 “加载 RAMDISK” 阶段会失败，然后安装程序就会知道从 CD 而不是从 RAMDISK 运行。（安装程序过去适用于 >8M 机器。现在仍然如此吗？）
尝试在一个会话中清除磁盘上所有将要被 Linux 使用的分区。重启。然后尝试安装。可以通过手动分区，也可以让安装程序来确定。（我认为 Red Hat 也具有这种可能性，SuSE 也有...）如果这对您有效，如果您告诉我，我将不胜感激。
损坏的下载也可能导致这种情况。哎。
有人报告说，在 8Mb 机器上的安装不再有效，并且安装程序会不优雅地退出，并显示 sig7。-- Chris Rocco (crocco@earthlink.net)
有人报告说，禁用“BIOS 阴影”（系统 & 视频）对他有帮助。由于 Linux 不使用 BIOS，因此对其进行阴影处理没有帮助。如果禁用阴影，某些计算机甚至可能会为您提供 384k 的额外 RAM。只需禁用它，看看会发生什么。-- Philippe d'Offay (pdoffay@pmdsoft.com)。

问题

还有哪些其他可能性？

答案

其他人注意到以下可能性

Red Hat 5.0 中包含的编译器和 libc 与 Cyrix 处理器存在奇怪的交互。它会使编译器崩溃。这非常奇怪。我认为唯一可能的情况是 Cyrix 存在一个一直未被发现的错误，并且在 THAT gcc 编译 Linux 内核时可靠地触发了该错误。无论如何，如果您只想编译内核，您应该从 Red Hat 网站获取新的编译器和/或 libc。（从主页开始，然后单击勘误表）。
使用 2.8.x gcc 或任何 egcs 编译 2.0.x 内核不起作用。内核中存在一些错误，这些错误没有显示出来，因为 gcc 2.7.x 在优化方面做得不好。gcc 2.8.x 和 egcs 只是转储了一些代码，因为我们没有告诉它不要这样做。无论如何，您通常会得到一个看起来可以工作但有奇怪错误的内核。例如，X 可能会因信号 11 而崩溃。哦，在您问之前，不，它不会被修复。不要为此打扰 Alan 或 Linus，好吗？-- Hans Peter Verne (h.p.verne@kjemi.uio.no)
pentium-optimizing-gcc（版本号以“p”结尾的那个）在某些源文件（如内核中的 floppy.c）上使用默认选项会失败。“触发器”在内核、libc 和 gcc 本身中。这很容易被诊断为“不是硬件问题”，因为它总是发生在相同的位置。您可以禁用某些优化（首先尝试 -fno-unroll-loops）或使用另一个 gcc。-- Evan Cheng (evan@top.cis.syr.edu)（换句话说：gcc 2.7.2p 在 floppy.c 上因 sig11 崩溃。解决方法 1：使用普通 gcc。解决方法 2：手动使用“-O”而不是“-O2”编译 floppy.c。）
磁盘与系统之间的连接不良。例如，IDE 电缆的长度只能为 40 厘米（16 英寸）。许多系统都配备了更长的电缆。此外，可移动的 IDE 机架可能会增加足够的麻烦，导致系统崩溃。
gcc 配置错误 - 某些部分来自一个版本，某些部分来自另一个版本。几周后，我最终从头开始重新安装以使一切正常。-- Richard H. Derr III (rhd@Mars.mcs.com)。
当程序链接到 SCO 库（iBCS 附带的库）时，Gcc 或生成的应用程序可能会因 sig11 终止。这发生在某些 LDFLAGS 中带有 -L/lib 的应用程序上......
当使用 ELF 编译器编译内核，但配置为 a.out 时（或者反过来，我忘记了），您将在第一次调用“ld”时收到信号 11。这很容易被识别为软件问题，因为它总是发生在构建期间第一次调用“ld”时。-- REW
以太网卡以及配置错误的 PCI BIOS。如果您的 (ISA) 以太网卡在 ISA 总线上有一个孔径，您可能需要在 BIOS 设置屏幕中的某个位置配置它。否则，硬件将在 PCI 总线上查找共享内存区域。由于 ISA 卡无法响应 PCI 总线上的请求，因此您正在读取空的“空气”。这可能导致段错误和内核崩溃。-- REW
交换分区损坏。Tony Nugent (T.Nugent@sct.gu.edu.au) 报告说他过去遇到过这个问题，并通过在他的交换分区上执行 mkswap 解决了这个问题。（在执行 mkswap 后，别忘了先键入“sync”再执行任何其他操作。-- Louis J. LaBash Jr. (lou@minuet.siue.edu)）
NE2000 卡。一些廉价的 Ne2000 卡可能会搞乱系统。-- Danny ter Haar (dth@cistron.nl) 我个人可能也遇到过类似的问题，因为我的邮件服务器时不时地（每天一次）硬崩溃。现在看来 1.2.13 和许多 1.3.x 内核都有这个错误。我在 1.3.48 中没有看到它。可能在一段时间内修复了...... -- REW
电源？不，我不这么认为。现代重型系统配备两个或三个硬盘，SCSI 和 IDE 都不会超过 120 瓦左右。如果您有很多旧硬盘和旧扩展卡，功耗会更高，但仍然很难达到电源的极限。当然，有些人设法找到大量旧的全尺寸硬盘并将它们安装到他们的大型塔式机箱中。您确实可以通过这种方式使电源过载。-- Greg Nicholson (greg@job.cba.ua.edu) 故障电源当然可以提供边际功率，这会导致您在本文件中读到的所有故障...... -- Thorsten Kuehnemann (thorsten@actis.de)
不一致的 ext2fs。某些情况可能会导致 ext2 文件系统的内核代码导致 Gcc 的信号 11。-- Morten Welinder (terra@diku.dk)
CMOS 电池。即使您按照您想要的方式设置了 BIOS，如果 CMOS 电池坏了，它也可能会在您眼皮底下改回“错误”设置。-- Heonmin Lim (coco@me.umn.edu)
没有或太少的交换空间。Gcc 无法优雅地处理“内存不足”的情况。-- Paul Brannan (brannanp@musc.edu)
不兼容的库。当您从“libc.so.5”到“libc.so.6”有一个符号链接时，某些应用程序会因 sig11 而崩溃。-- Piete Brooks (piete.brooks@cl.cam.ac.uk)。
坏鼠标。不知何故，鼠标似乎会以某种方式损坏，导致某些（鼠标相关的）程序因 Sig11 而崩溃。我见过这种情况发生在 X 服务器上，如果您快速移动鼠标，X 服务器就会崩溃。Matthew 甚至可能没有移动他的鼠标。-- REW & Matthew Duggan (stauff@guarana.org)。

问题

我发现运行 ..... 检测错误的速度比仅仅编译内核快得多。请在您的网站上提及这一点。

答案

许多人给我发电子邮件，内容类似这样。但是，许多人没有意识到的是，他们遇到了一个有问题的硬件案例。推荐“unzip -t”的人碰巧有一个特定的损坏的 DRAM 内存条。而 unzip 碰巧比内核编译“发现”得更快。

但是，我确信对于许多其他问题，内核编译会发现它，而其他测试则不会。我认为内核编译很好，因为它强调了计算机的许多不同部分。许多其他测试只练习一个区域。如果该区域在您的情况下恰好损坏，它会比“内核编译”更快地显示问题。但是，如果您的计算机在该区域正常，而在另一个区域损坏，“更快”的测试可能只会告诉您您的计算机正常，而内核编译测试会告诉您有问题。

在任何情况下，我最好还是列出人们认为好的测试，它们确实很好，但不如“尝试编译内核”测试那么通用......

在编译内核时运行 unzip。使用与 RAM 大小相当的 zip 文件。
使用“memetest86”。
在编译内核时执行 dd if=/dev/hda of=/dev/null。
对大型树运行 md5sum。

请注意，无论您找到什么快速方法来告诉您您的计算机已损坏，如果这样的测试突然不再失败，它都不能保证您的计算机是好的。我始终建议，在摆弄东西使其工作后，您应该运行 24 小时的内核编译测试。

问题

我不相信这个。这发生在谁身上？

答案

嗯，首先它发生在我个人身上。但你不必相信我。它也发生在

Johnny Stephens (icjps@asuvm.inre.asu.edu)
Dejan Ilic (d92dejil@und.ida.liu.se)
Rick Tessner (rick@myra.com)
David Fox (fox@graphics.cs.nyu.edu)
Darren White (dwhite@baker.cnw.com) (L2 缓存)
Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu)
Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (温度问题)
Michael Blandford (mikey@azalea.lanl.gov) (温度问题：CPU 风扇故障)
Alex Butcher (Alex.Butcher@bristol.ac.uk) (内存等待状态)
Richard Postgate (postgate@cafe.net) (VLB 负载)
Bert Meijs (L.Meijs@et.tudelft.nl) (坏 SIMM)
J. Van Stonecypher (scypher@cs.fsu.edu)
Mark Kettner (kettner@cat.et.tudelft.nl) (坏 SIMM)
Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 转换器)
Rick Lim (ricklim@freenet.vancouver.bc.ca) (坏缓存)
Scott Brumbaugh (scottb@borris.beachnet.com)
Paul Gortmaker (paul.gortmaker@anu.edu.au)
Mike Tayter (tayter@ncats.newaygo.mi.us) (与缓存有关的东西)
Benni ??? (benni@informatik.uni-frankfurt.de) (VLB 过载)
Oliver Schoett (os@sdm.de) (缓存跳线)
Morten Welinder (terra@diku.dk)
Warwick Harvey (warwick@cs.mu.oz.au) (缓存中的位错误)
Hank Barta (hank@pswin.chi.il.us)
Jeffrey J. Radice (jjr@zilker.net) (内存电压)
Samuel Ramac (sramac@vnet.ibm.com) (CPU 达到最高温度)
Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM 速度)
W. Paul Mills (wpmills@midusa.net) (CPU 风扇与 CPU 断开连接)
Joseph Barone (barone@mntr02.psf.ge.com) (坏缓存)
Philippe Troin (ptroin@compass-da.com) (延迟 RAM 时序问题)
Koen D'Hondt (koen@dutlhs1.lr.tudelft.nl) (更多内核错误消息)
Bill Faust (faust@pobox.com) (缓存问题)
Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU 温度：风扇已安装)
Andrew R. Cook (andy@anchtk.chm.anl.gov) (坏缓存)
Allan Wind (wind@imada.ou.dk) (P66 过热)
Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p 受害者)
R.C.H. Li (chli@en.polyu.edu.hk) (超频：几个月没问题...)
Florin (florin@monet.telebyte.nl) (供应商超频 CPU)
Dale J March (dmarch@pcocd2.intel.com) (笔记本电脑上的 CPU 过热)
Markus Schulte (markus@dom.de) (坏 RAM)
Mark Davis (mark_d_davis@usa.pipeline.com) (坏 P120？)
Josep Lladonosa i Capell (jllado@arrakis.es) (PCI 选项过度优化)
Emilio Federici (mc9995@mclink.it) (P120 过热)
Conor McCarthy (conormc@cclana.ucd.ie) (坏 SIMM)
Matthias Petofalvi (mpetofal@ulb.ac.be) ("Simmverter" 问题)
Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p 受害者)
Greg Nicholson (greg@job.cba.ua.edu) (许多旧磁盘)
Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking)
Daniel Pancamo (pancamo@infocom.net) (70ns 而不是 60 ns RAM)
David Halls (david.halls@cl.cam.ac.uk)
Mark Zusman (marklz@pointer.israel.net) (坏主板)
Elizabeth Ayer (eca23@cam.ac.uk) (电源管理功能)
Thorsten Kuehnemann (thorsten@actis.de)
（通过电子邮件向我讲述您的故事，您可能会被提及在这里... :-) ---- 更新：我想听听您发生了什么。这将使我能够猜测最常发生的情况，并使该文件尽可能准确。但是我现在有大约 500 个遇到过 sig-11 问题的人的电子邮件地址。我不认为继续在此列表中添加“随机”人员的姓名是有用的。您怎么看？

我对新的故事很感兴趣。如果您遇到问题并且不确定问题是什么，通过发送电子邮件至 R.E.Wolff@BitWizard.nl 联系我可能会有所帮助。我的好奇心通常会驱使我回答您的问题，直到您找到问题所在.....（另一方面，当您的问题在上面清楚地描述时，我会很生气 :-)）

此页面由 www.BitWizard.nl 托管