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

我更新了这个post,因为我更换了处理器,但是我的问题的核心(不幸的是结果也一样)。


我build立了我的第一个FreeNAS盒子,并且想要使用ECC RAM,因为我想存储关键数据。 因为我正处于预算之内,所以我希望能够买到仍然支持ECC RAM的最经济实惠的解决scheme。

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

我还购买了由Kingston制造的型号为“KVR21E15S8K2 / 8”( 规格表 )的两个DIMM套件。 Gigabyte发布了一系列经过testing的内存模块,而我的模块似乎也支持ECC( 支持的模块列表 )。

RAM标签

由于我在预算中,我需要一个支持ECC的经济实惠的Skylake CPU。 据英特尔赛扬G3900支持ECC,所以我去了那一个。

在构build计算机之后,我想确认我的系统是否正在运行ECC内存,然后进入主板的BIOS。 从各种互联网网站,我发现一些主板有一个特殊的部分 ,应该告诉ECC是否工作,但我的主板似乎没有。 我检查了所有的菜单,我找不到类似的部分。

在做了一些更多的研究之后 ,在Unix和Linux的stackexchange上发现了一个没有解决我的问题的post 。 我尝试了最新的memtest86+ ,从我可以告诉,甚至没有显示“ECC”的价值。 我尝试了Puget系统使用的显示“ECC:off”的较旧的4.20版本。 然而,在阅读之前提到的post之后,我怀疑它说的是实话(也许这就是为什么该function被删除?)。 这两个版本也没有读出DIMM的正确速度和延迟,这增加了我对memtest86+怀疑。

memtest86 +截图

如果ECC正在工作,另一个stream行的方法是发出dmidecode -t memory命令并读出Total WidthData Width 。 我的结果分别是128 Bits64 Bits 。 输出的一部分显示了具有Error Correction Type: Single-bit ECC的键 – 值对的存储器arrays的细节。

我预计Total Width72 bits ,所以我认为它可能与双通道有关,并将内存模块移到两个相邻的插槽中,以防止双通道,但结果是一样的。 这是dmidecode -t memory的完整输出 。

我甚至尝试过Puget系统发布的有趣的C程序 ,但结果是0 ,表示没有ECC支持。

现在我开始怀疑英特尔自己网站上的数据是否正确,而我的CPU实际上并不支持ECC。 内存和主板都是专门用“ECC”标记的,所以我可以排除这些。

是否有可能BIOS版本需要更新(目前没有)启用ECC或ECC实际上已经工作,我只是无法validation它? 或者是我的CPUselect错了,如果我想运行ECC内存和英特尔的网站是错误的/误导?

如果我的CPU结果是错误的select,那么“预算ECC CPU”的下一个最佳select是什么?

更新:我看到了一些新的迹象表明 ,我的系统实际上可能在启用ECC的情况下运行,而dmidecode工具只是报告奇怪的数据。 在FreeNAS论坛上,用户Dusan正在使用服务器级硬件(SuperMicro MB,Xeon CPU,金士顿DIMM),并具有128 Bits的类似输出。 但是他写道,如果真的有效,他不确定自己。

更新2:由于yagmoth555在回答这个问题时提到,我的主板似乎只支持至​​强处理器的ECC,但是我认为这个备忘录是以前手册的遗留问题。 我想这意味着我需要看看至强处理器..: – /


更新3:我买了至强E3 – 1220v5现在哪个支持ECC,并应符合手册的要求。 我再次运行所有testing来检查ECCfunction,结果基本相同:

ecc_check和dmidecode

从Puget Systems的评论看来,似乎ecc_check.c程序在Xeon和Core i7处理器上不起作用。: – /

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

memtest86 + v5.01

4.20版甚至没有正确检测到我的处理器。

memtest86 + v4.20

关于如何我可以testingECC的任何想法非常赞赏。

使用Ryzen 7处理器,上述工具都不适用于我。 然而,使用最新的Linux内核,edac-utils,edac-ctl和edac-util中的工具可以读取ECC状态,还可以读取更正的错误数量等。 内核日志还将在dmesg中包含带有“EDAC”的行,这也应该提供一些信息。 这个function可以通过超频内存进行进一步的testing,并检查错误是否被报告(如果足够高的话),这是certificate你真的可以工作的证据。 但是,即使这些工具报告错误或不工作,这只意味着读取ECC状态信息不被支持,似乎没有100%可靠的方法来certificateECC不工作…

编辑 :从您的主板手册新的坏…:

在这里输入图像说明


我看你运行BSD / Linux,在OS内运行; (适用于FreeNAS )

dmidecode -t 17

你应该有这样的输出:

dmidecode 2.12 SMBIOS 2.5 present.

处理0x1100,DMItypes17,28字节存储器设备arrays句柄:0x1000错误信息句柄:未提供总宽度:72位数据宽度:64位大小:2048 MB外形:DIMM设置:1定位器:DIMM1存储区定位器:未指定types:DDR2types详细信息:Synchronous速度:667 MHz制造商:AD00000000000000序列号:00002062资产标签:010839部件号:HYMP125P72CP8-Y5评估:2

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

在Windows系统上,你可以运行

wmic MEMORYCHIP get DataWidth,TotalWidth

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

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

FreeBSD&Windows的答案从那里拿走了

今天我发现有一个PassMark的memtest86 (没有+ )的商业版本 ,提供一个免费的版本,谢天谢地包括ECC检查。

另外它还支持DDR4和memtest86+所有其他function。

我的结果似乎对ECC的支持是积极的,所以我会称之为完成,即使我希望得到与“传统”工具,如dmidecode相同的结果。

memtest86结果


如果稍后有人在这篇文章中发现并需要进一步validation和testing,他们还提供支持ECC错误注入的付费版本,以便实际testingECCfunction。