I'm planning on getting some ECC RAM to replace the non-ECC RAM I currently have installed on my Asus M5A97 Pro motherboard (AMD 970 chipset, FX-6100 CPU).

After I install the RAM, how do I tell whether the ECC feature of the RAM is working properly?

I thought about dmidecode --type memory which currently prints among else for each RAM stick:

Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits

(For one, I would expect with 1 bit of ECC per byte the data width to remain 64 bits but the total width to read 72 bits.)

Can that be used for determining whether ECC is operative? Or is dmidecode too low level for that? What else could I use (except waiting and seeing if an ECC error shows up in the logs, which would indicate it's working but not that it isn't working)?

Update: I later thought of edac-utils. Installing them, I get Not enabling Memory Error Detection and Correction since EDAC_DRIVER is not set. That gave me edac-util and edac-ctl executables. Can one of those be used for this purpose?


3 Answers 3


It appears that there is no surefire way to tell, however various approaches can get you some sort of answer. Apparently you pretty much have to try the different ones until you find one that tells you ECC is working.

In my case memtest86+ 4.20 couldn't be coaxed into realizing it was dealing with ECC RAM; even if I configured it for ECC On, it still reported ECC: Disabled on the IMC line. I haven't yet tried with a newer version. However (possibly after installing edac-utils, unfortunately I did both essentially at the same time), Linux reports in the boot logs (interspersed with some other entries):

[    4.867198] EDAC MC: Ver: 2.1.0
[    4.874374] MCE: In-kernel MCE decoding enabled.
[    4.875414] AMD64 EDAC driver v3.4.0
[    4.875438] EDAC amd64: DRAM ECC enabled.
[    4.875542] EDAC amd64: CS0: Unbuffered DDR3 RAM
[    4.875545] EDAC amd64: CS1: Unbuffered DDR3 RAM
[    4.875546] EDAC amd64: CS2: Unbuffered DDR3 RAM
[    4.875548] EDAC amd64: CS3: Unbuffered DDR3 RAM

which is a pretty good indication. Manually doing /etc/init.d/edac restart does not create similar log entries, and looking at an older log from a few reboots ago, I see:

[   13.886688] EDAC MC: Ver: 2.1.0
[   13.890389] MCE: In-kernel MCE decoding enabled.
[   13.891082] AMD64 EDAC driver v3.4.0
[   13.891107] EDAC amd64: DRAM ECC disabled.
[   13.891116] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.
[   13.891117]  Either enable ECC checking or force module loading by setting 'ecc_enable_override'.
[   13.891118]  (Note that use of the override may cause unknown side effects.)

dmidecode --type memory also gives two pretty strong indications: the physical memory array's "error correction type" property (which however for some reason showed the same on non-ECC RAM, so this may be related to the motherboard's support rather than the memory's capabilities),

Handle 0x0026, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: Multi-bit ECC

and each memory device's total width and data width, respectively (the additional bits being those used for the ECC):

Handle 0x0028, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x0026
    Error Information Handle: Not Provided
    Total Width: 72 bits
    Data Width: 64 bits

There is a very simple and effective way of doing this, provided that you have console access to your server/PC and can reboot it: memtest86+

This nifty tool will quickly show you if the memory is ECC enabled. I also believe it will perform ECC validation when doing the actual testing.

Here's a (slightly outdated) screenshot: enter image description here

  • Perfect! For now, I'm seeing IMC : AMD FX(tm)-6100 Six-Core Processor (ECC : Disabled) and ECC off. I suppose then that if it shows anything other than Disabled and off for ECC with the new DIMMs, I'm all set as far as the hardware goes at least?
    – user
    Commented Jun 26, 2014 at 12:07
  • 2
    @MichaelKjörling I only deal with ECC on industry standard servers with Xeon CPU's, so I have no idea. I can imagine that the CPU needs to support ECC, since the memory controller resides inside it.
    – pauska
    Commented Jun 26, 2014 at 12:20
  • en.wikipedia.org/wiki/… lists the FX-6100 as Zambezi (Bulldozer-based), of which "all models support ... ECC [RAM]"
    – user
    Commented Jun 26, 2014 at 13:44
  • Unfortunately memtest86+ 4.20 did not seem to want to recognize my RAM as ECC. However, there are some other pretty strong indications that ECC is working; see my answer. Still, thank you very much!
    – user
    Commented Jun 27, 2014 at 12:47
  • 1
    This looks sort of relevant - confluence.wartungsfenster.de/display/Adminspace/… Commented Jul 14, 2014 at 21:57

I will try to summarize my experience with actual hardware. I don't have M5A boards but have two M4A boards with AMD chipsets.


Some points:

  • M4A8xx motherboards officially support ECC.
  • AMD Phenom II and Athlon II support ECC. (others may work)
  • AMD Phenom chips support error reporting through module "edac_mce_amd". This module works without ECC and reports cache or other errors related to the CPU.
  • RAM ECC is supported through "amd64_edac".

At this point I've had the M4A board run with ECC RAM for 2+ years and saw no errors reported. Some boards seem to not report correctable errors (CE). I advise you to set unstable timings w/o ECC and enable it afterwards to check it's working. You can use Memtest86 but that software will not report ECC events, it will just show the RAM is now stable w/ ECC enabled. The kernel itself only shows messages with no detail, no matter what kernel parameters are passed to 'mce' boot parameter:

[Hardware error] Machine Check Exception

These also don't get accounted for in the 'edac' intries in /sys. From testing, these will be corrected errors but I don't know how it will handle uncorrectable errors.

These ASUS boards also don't seem to reported any kind of error related to CPU errors. I was first aware of this functionality when a damaged ASRock board started locking but due to UE reported to the OS. On compatible boards, these show up on the kernel messages in the following format:

[Hardware error] Machine Check Excpetion logged
[Hardware error] ERROR DETAILS, ETC, ETC

These do not get recorded on MCE Log but are specifically handled by the kernel. (The edac_mce_amd module) This is useful because uncorrected errors can be discarded if in a buffer or another option like killing a process that would have it's memory corrupted.

On these ASUS boards, CPU error reporting is not working. This is quite bad because you may get some data corruption if the PSU or motherboard VRM are damaged and start generating errors. I would not use this without regularly testing CPU stability.


On ASUS AM4 boards, previous versions would work as AM3 but memory error reporting was working correctly - you could read /sys and get error counts, or look at the kernel log. On current BIOS, you have to install RAS Daemon and use 'ras-mc-ctl' command to read error counts.

I haven't tested CPU error reporting and handling on these platforms.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .