Of all youtubers, unexpectedly Hardware Unboxed tested ECC support on some X870E boards…
The result is somewhat surprising. Gigabyte and Asrock have ECC working, Asus posts but without working ECC, MSI does not post at all…
They tested memory speeds too, with all boards except Asrock reaching 8000+ speeds, with Asrock stuck at 7400MT. Interesting, since Wendell had 8000MT working… Bios updates might improve compatibility I guess?
Don’t wanna sound like a dick but do they know that sometimes ECC has to be manually enabled in the UEFI? “Auto” doesn’t automatically mean enabled.
The tested ASUS motherboard supports ECC according to its specs website so maybe its a bug if the UEFI setting is without any effect.
Wouldn’t be the first time, but ASRock is one of the worst offenders here and no matter which manufacturer you choose if you want to use ECC be sure to always verify it to be working with software like PassMark Memtest that can test for actual memory corrections not only if the platform reports to the operating system that ECC is present.
That said, MSi is the worst manufacturer not implementing ECC memory on the consumer AMD platforms in general, was the only one with AM4.
PS: I myself am an ECC fetishist so no complaints here making ECC more popular in general consumers’ minds.
Fair enough. They are mostly a gaming channel (at least those are the benchmarks they do almost exclusively). So given Asus had good ECC support on X670/B650 it’s definitely possible they forgot a BIOS setting. Or a UEFI bug.
I thought it was noteworthy though as it’s the first data I saw on ECC with X870.
Seems like it. At least they are clear about it, their specs show non-ECC memory support only.
Agreed. I sadly caved waiting for ECC 48GB modules, and got non-ECC ones since I didn’t want to wait any longer.
I have ASUS ProArt B550, X570 and the X670E motherboards in use (with ECC working) and noticed that AMD or ASUS rearranged ECC settings on the AM5 model, I’d suspect it looks the same on the ASUS X870E motherboards, maybe that confused them.
My first post here, so hello all 
I’ve just had a look at the specs, and it seems that in case of Gigabyte, “Master” model (~550eur in retail) is the ONLY ONE that supports ECC, while in case of ASRock every model, even the cheapest ~220eur “Pro RS”, has ECC support. If this is correct, then ASRock has just put every other mobo manufacturer to BIG shame with its cheapest model…
So is any owner of ASRock Pro RS able to confirm that it indeed supports ECC? Thanks!
The AsRock Rack department is certainly beneficial to general BIOS changes and proper ECC support.
I was surprised when I updated my BIOS on the X670E Steel Legend. I sadly never had the RAM to test with as there were no DDR5 ECC UDIMMs for sale when I bought it. But BIOS 3 months after (Zen5) launch got all the BIOS entries I see on my server BIOS as well.
Sounds familiar. But it’s on my daily driver and ECC isn’t that important…certainly not 500€ important for 2x48GB modules. Server gets the expensive stuff, Desktop is dirt cheap stuff that works (cheap 64GB 5200MT Kingston).
Hopefully not because you couldnt find any as I actually just got a Asus ProArt X870E-Creator WiFi w/ 9950X with 96GB 5600 setup using 2 Kingston KSM56E46BD8KM-48HM ECC UDIMMS setup maybe a month ago.
They’ve actually been available for a while and I got them mid august. I will admit they werent easy to find however and I definitely had to find a retailer I was not familiar with and who sold relatively nice items.
I got mine before the Kingston ones became available. About a year ago.
Yup if you need ECC Asrock is currently where it´s at.
Pretty much all Asrock X870 en X870E boards support ¨functioning¨ ecc.
Msi does not care about supporting ecc they never really did as far as i´m aware.
Which is kinda a bummer because the X870E Carbon is actually a pretty nice board.
One of the reasons i personally really leaning towards the Asrock X870E Nova or the Taichi Lite.
There is €70,- difference between those two boards.
I’m considering this exact hardware.
In the latest Hardware Unboxed video they report ECC not working with the ProArt X870E-Creator WiFi and 2 x MTC10C1084S1EC56BD1R, so if you could share some more details, I’d really appreciate it.
The linked video just says that ECC is not supported on the board and no memory SKU given. And they also don’t say how or if they have tested this.
I’m pretty sure if they ran anything, it wasn’t more than wmic memphysical get memoryerrorcorrection in a windows terminal.
Hardly evidence as we’ve seen Windows reporting ECC and returning 6 when it isn’t working. Proper test with memtest86 and edac-util/mcelog would solve that.
But they’re a simple gaming channel…so they should be good at overclocking RAM to let edac-util and mcelog spill out errors. I wouldn’t trust their judgement on more advanced stuff tbh. They’re good at using Cinebench though.
…also auto option doesn’t enable ECC, you need set it to enabled
It makes no sense at all to overclock if you’re buying ECC memory to begin with, just sayin’
The video at the top of the thread shows the memory SKU and the 21 boards roundup is a continuation of the same testing, so it’s reasonable to assume they used the same memory, Micron MTC10C1084S1EC56BD1R.
You’re right, they didn’t specify ECC testing procedure, which is less than ideal. They did say the ASUS ROG Crosshair X870E Hero “ran with ECC memory, in the sense that it passed the POST and could overclock the memory to 6400, but ECC wasn’t actually enabled” in the video at the top of the thread, reporting it as not supported as with the other ASUS boards in the 21 boards roundup. This is enough to give me pause on spending that much on a board & ECC memory without confirmation. I’ve watched a fair bit of Steve’s content over the years and he’s competent, so I’m not willing to assume he missed explicitly setting ECC to enabled in UEFI and didn’t reach out to ASUS or they didn’t tell him to do that.
Reports that ECC worked on the X670 version and some other ASUS X670 boards + it being listed in ASUS X870 board spec’s isn’t nothing, but I’d really like to hear from someone who’s tested ECC working on the ProArt X870E-Creator WiFi preferably or other ASUS X870 boards at least.
Yeah it’s quite puzzling. Asus does list official ECC support exactly like for their x670 boards, and it works for those.
Either it’s a bios bug or operator error IMO.
Also for DDR5, there are 2 versions of ECC, 72bit and 80bit.
Only for buffered DIMMs though (RDIMMs). ECC UDIMMs are all 72-bit.
What makes my gut feel suspicious is that in the videos when mentioning ECC not working on various ASUS boards they don’t qualify that statement with “According to the specs model xyz should support ECC memory and me messaged ASUS about clarification of this potential bug” (I personally only have had ECC experience with ASUS motherboards that’s why I’m specifically mentioning these).
On the ASUS Proart X870E Creator Wifi memory support QVL page there are various ECC modules supported up to 64GB total but only at 4800. My modules infact cant run at full speed (5600) and I’ve had to leave them at 5400 along with setting memory context restore so that there isnt long memory training on boot.
5400 was as high as I could go, and I needed to be on the latest bios version as without it I couldnt even boot to the bios, but now that I have 5400 set, there are no issues with booting or boot times (basically instant).
dmidecode -t memory returns
Memory Device
Array Handle: 0x0013
Error Information Handle: 0x0017
Total Width: 72 bits
Data Width: 64 bits
Size: 48 GB
Form Factor: DIMM
...
Where the 72-bit section is the one of note as the extra width is for ECC.
There is also dmesg | grep -i EDAC
Which outputs
Oct 26 20:51:13 localhost kernel: EDAC MC: Ver: 3.0.0
Oct 26 20:51:18 localhost kernel: EDAC MC0: Giving out device to module amd64_edac controller F1Ah_M40h: DEV 0000:00:18.3 (INTERRUPT)
Oct 26 20:51:18 localhost kernel: EDAC amd64: F1Ah_M40h detected (node 0).
Oct 26 20:51:18 localhost kernel: EDAC MC: UMC0 chip selects:
Oct 26 20:51:18 localhost kernel: EDAC amd64: MC: 0: 0MB 1: 0MB
Oct 26 20:51:18 localhost kernel: EDAC amd64: MC: 2: 16384MB 3: 8192MB
Oct 26 20:51:18 localhost kernel: EDAC MC: UMC1 chip selects:
Oct 26 20:51:18 localhost kernel: EDAC amd64: MC: 0: 0MB 1: 0MB
Oct 26 20:51:18 localhost kernel: EDAC amd64: MC: 2: 16384MB 3: 8192MB
There is also sudo lshw -class memory
*-memory
description: System Memory
physical id: 13
slot: System board or motherboard
size: 96GiB
capabilities: ecc
configuration: errordetection=multi-bit-ecc
Lastly, Passmark Memtest86 indicates that ECC is working.
That being said
I could not find a way thus far to inject ecc errors to actually test the functionality.
I attempted to use Passmark Memtest86’s error injection feature, but unfortunately it does not work, so it was a waste of 75 dollars (not that I’m implying it is Passmark’s fault, as in the forums they state that this is not enabled on most cpus except some engineering samples so I have no idea why its a mass market feature of the software but…)
I also experimented with a bevy of bios settings such as:
There is more I think I might do at some point such as reading through the error injection methods talked about by some Linux kernel developers, but Im pretty burned out at looking into this for now. A combination of so much information being buried in footnotes, and that a major selling point of hardware is this difficult to actually check the validity of.
I’ve seen suggestions about hardware testing techniques but the only ones that look safe are for DDR4 or earlier, I imagine as DDR5 with UDIMMS and even CUDIMMS is hitting signal integrity limits already.
Sorry or you’re welcome for the long response; whichever is applicable.
Hopefully this helps some other poor soul avoid going down this rabbit hole in the future.
Hmm, that’s a bit disappointing. Since those modules have hynix chips I would have expected they could run much faster. Non-ECC 2x48GB with hynix should be able to run 6000-6400 depending on your CPU’s silicon lottery.
But it’s good to see ECC seems to be working. It would be hard to validate, but with the kernel reporting ECC I’d think more likely than not it’s working.