如何检查 RAM 是否在 ECC 模式下运行？

Question

自从更换处理器后，我更新了这篇文章，但我的问题的核心（不幸的是结果也是如此）是相同的。

---

我构建了我的第一个 FreeNAS 盒子，并想使用 ECC RAM，因为我想存储关键数据。因为我的预算有限，所以我想寻找仍然支持 ECC RAM 的最实惠的解决方案。

经过一番研究，我发现我需要一个支持 ECC 的主板、内存和 CPU。我选择的主板是“Gigabyte X150M-Pro ECC”，它有 C232 芯片组、DDR4 和 LGA1151 插槽。

我还购买了由金士顿制造的两个 DIMM 套件，型号为“KVR21E15S8K2/8”（规格表）。技嘉发布了一份经过测试的内存模块列表，我的模块似乎支持工作 ECC（支持模块列表）。

由于我的预算有限，我需要一个支持 ECC 的经济实惠的 Skylake CPU。根据英特尔的说法，赛扬 G3900 确实支持 ECC，所以我选择了那个。

构建计算机后，我想验证我的系统是否确实使用 ECC 内存运行并进入了主板的 BIOS。从各种互联网站点，我发现有些主板有一个特殊部分，可以告诉 ECC 是否正常工作，但我的主板似乎没有。我检查了所有菜单，但找不到类似的部分。

在做了更多的研究之后，在 Unix&Linux stackexchange 上找到了一篇没有解决我的问题的帖子。我尝试了最新的memtest86+，据我所知，它甚至没有显示值“ECC”。我尝试了Puget 系统使用的较旧的 4.20 版本，该版本显示“ECC：关闭”。然而，在阅读了前面提到的帖子后，我怀疑它说的是实话（也许这就是该功能被删除的原因？）。两个版本也没有读出 DIMM 的正确速度和延迟，这增加了我对memtest86+.

另一种确定 ECC 是否正常工作的流行方法是发出dmidecode -t memory命令并读出Total Width和Data Width。我的结果分别是128 Bits和64 Bits。输出的一部分显示了有关具有键值对的内存数组的详细信息Error Correction Type: Single-bit ECC。

我期待72 bits的Total Width，所以我认为它可能与双通道有关，并将内存模块移动到两个相邻的插槽中，这应该可以防止双通道，但结果是一样的。下面是完整的输出的dmidecode -t memory。

我什至尝试了Puget 系统发布的有趣的C 程序，但结果是0，表明不支持 ECC。

现在我开始怀疑Intel自己网站上的数据是否正确，我的CPU实际上并不支持ECC。内存和主板都标有“ECC”，所以我可以排除这些。

BIOS 版本是否可能需要更新（目前没有）才能启用 ECC，或者 ECC 是否实际上已经在工作而我只是无法验证它？或者我选择的 CPU 是错误的，如果我想运行 ECC 内存而英特尔的网站是错误的/误导性的？

如果我的 CPU 被证明是错误的选择，那么“预算 ECC CPU”的下一个最佳选择是什么？

更新：我看到一些新的迹象表明我的系统实际上可能在启用 ECC 的情况下运行，并且该dmidecode工具只报告奇怪的数据。在 FreeNAS 论坛上，用户 Dusan 正在使用服务器级硬件（SuperMicro MB、Xeon CPU、Kingston DIMM）并且具有类似的输出128 Bits。但他写道，他不确定自己是否真的有效。

更新 2：正如 yagmoth555 在他对这个问题的回答中提到的，我的主板似乎只支持使用至强处理器的 ECC，尽管我认为该注释是从以前的手册中复制过来的。我想这意味着我需要研究 Xeon 处理器.. :-/

---

更新3：我现在买了一台至强E3-1220v5，当然支持ECC，应该符合手册要求。我再次运行所有测试以检查 ECC 功能，结果基本相同：

从 Puget Systems 的评论来看，该ecc_check.c程序似乎也不适用于至强和酷睿 i7 处理器..:-/

memtest86+这次我检查了更多，我相当确定它根本不支持 DDR4 或 C232 芯片组，因为它不仅报告错误的速度和时序，而且报告 DDR3 而不是已安装的 DDR4。但是，它检测到处理器很好，但我仍然得到了两个版本的相同最终结果memtest86+：

版本 4.20 甚至不能正确检测我的处理器..

非常感谢有关我如何测试 ECC 的任何想法。

Answer 1

编辑：主板手册中的坏消息......：

我看到你运行 BSD/linux，在操作系统中运行它；（适用于FreeNAS）

dmidecode -t 17

您应该有如下输出：

dmidecode 2.12 SMBIOS 2.5 present.

Handle 0x1100, DMI type 17, 28 bytes Memory Device Array Handle: 0x1000 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: 1 Locator: DIMM1 Bank Locator: Not Specified Type: DDR2 Type Detail: Synchronous Speed: 667 MHz Manufacturer: AD00000000000000 Serial Number: 00002062 Asset Tag: 010839 Part Number: HYMP125P72CP8-Y5 Rank: 2

总宽度：72 位是您正在寻找的部分。

在Windows系统上你可以运行

wmic MEMORYCHIP get DataWidth,TotalWidth

//ECC 内存数据宽度 TotalWidth 64 72

//非 ECC 内存数据宽度 TotalWidth 64 64

FreeBSD 和 Windows 的答案取自那里

Answer 2

今天，我发现有一个商业版本的memtest86（没有+从PassMark），提供了一个免费的版本太多值得庆幸的，其包括ECC-检查。

此外，它还支持 DDR4 和memtest86+.

我的结果似乎对 ECC 支持是积极的，所以我会称之为完成，即使我希望使用“传统”工具（如dmidecode.

如果有人在以后偶然发现这篇文章并需要进一步验证和测试，他们还会提供支持 ECC 错误注入的付费版本，用于实际测试 ECC 功能。

Answer 3

使用 Ryzen 7 处理器时，上述工具都不适合我。然而，对于足够新的 Linux 内核，edac-utils、edac-ctl 和 edac-util 中的工具可以读取 ECC 状态以及已纠正错误的数量等信息。内核日志还将包含 dmesg 中带有“EDAC”的行，它也应该提供一些信息。可以通过超频 RAM 并检查是否报告错误（如果足够高）来进一步测试此功能，这几乎可以证明它确实有效。然而，即使这些工具报告错误或不起作用，也仅仅意味着不支持读取 ECC 状态信息，似乎没有 100% 可靠的方法来证明 ECC 不起作用......