TR Forums

ASRock seems to be the only AM4 motherboard vendor (so far) that doesn't have the "operates in non-ECC mode" disclaimer in their specs regarding use of ECC DIMMs. Has anyone actually tried it, and verified that the ECC capability of the DIMMs is recognized by the system? I downloaded the manuals for a couple of their AM4 boards and there's no mention of ECC settings in the UEFI, which makes me a little suspicious. Yes, it could be just automatically detecting (and enabling) ECC, but most BIOSes/UEFIs on ECC-capable boards have an explicit enable/disable setting for it.

So basically there are affirmative statements that it doesn't work from everybody except AsRock? And AsRock is saying nothing?

I'd take a wait & see approach until I see a motherboard where the manufacturer flat out says ECC *is* supported. It's pretty clear that there have been firmware headaches with the RyZen launch and hopefully by this summer the boards & firmware will be sorted to the point where you know ECC is going to work without problems.

My jaded guess would be that it's more likely they forgot to put the disclaimer in the marketing materials than the doc writers forgot to put the option in the manual (or the engineers forgot to put the option in the BIOS). That said, it may be that the capability is there but hasn't yet been enabled, and will require a future BIOS revision. I do wonder if the vendors see an opportunity to pull an Intel with their mobos, and only offer ECC on their more expensive "workstation-class" offerings -- which will be available eventually, once the high-markup early-adopter wave has passed -- even if AMD itself is performing no such market segmentation. (Or at least, isn't yet.)

just brew it! wrote:

ASRock seems to be the only AM4 motherboard vendor (so far) that doesn't have the "operates in non-ECC mode" disclaimer in their specs regarding use of ECC DIMMs. Has anyone actually tried it, and verified that the ECC capability of the DIMMs is recognized by the system? I downloaded the manuals for a couple of their AM4 boards and there's no mention of ECC settings in the UEFI, which makes me a little suspicious. Yes, it could be just automatically detecting (and enabling) ECC, but most BIOSes/UEFIs on ECC-capable boards have an explicit enable/disable setting for it.

There was this guy in a German site that actually tested ECC on an Asus Prime and got an ECC error in Linux when OCing the memory. This is far from official support, but gives some hope. Can't find the link right now, but I posted it in a comment in this site a few days ago.

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

whm1974 wrote:

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

In this case, apparently so.

AMD added to the confusion by not clearly stating ahead of time whether the initial round of Ryzen CPUs would support it, then (when questioned about it specifically) stating that the feature is present on the Ryzen die but "not validated".

just brew it! wrote:

whm1974 wrote:

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

In this case, apparently so.

AMD added to the confusion by not clearly stating ahead of time whether the initial round of Ryzen CPUs would support it, then (when questioned about it specifically) stating that the feature is present on the Ryzen die but "not validated".

Just another beef with hardware manufacturers I have. Yes I know fully well that no one is perfect and AMD has very big hill to climb, but shouldn't a very important feature be supported at launch?

Although I will give credit where it is due. The woman who is now running AMD has turned the company around and hopefully AMD will be strong rival to Intel like they were.

whm1974 wrote:

Just another beef with hardware manufacturers I have. Yes I know fully well that no one is perfect and AMD has very big hill to climb, but shouldn't a very important feature be supported at launch?

It is only "very important" to people who want to use AM4/Ryzen as a way to build high-reliability server/NAS boxes without shelling out for an Intel server platform. These people represent a small segment of the market, and are therefore not "very important" to the makers of enthusiast/gamer-oriented motherboards. For AMD, it is arguably counter-productive to officially support ECC on the "enthusiast" parts, since that could potentially cut into the sales of the (presumably higher-margin) upcoming Naples variant for servers.

At the end of the day, the motherboard vendors and AMD are in this to make money, not to make everyone happy by including every feature anyone might want. They're going to focus on where they think they can make the most profit.

just brew it! wrote:

whm1974 wrote:

Just another beef with hardware manufacturers I have. Yes I know fully well that no one is perfect and AMD has very big hill to climb, but shouldn't a very important feature be supported at launch?

It is only "very important" to people who want to use AM4/Ryzen as a way to build high-reliability server/NAS boxes without shelling out for an Intel server platform. These people represent a small segment of the market, and are therefore not "very important" to the makers of enthusiast/gamer-oriented motherboards. For AMD, it is arguably counter-productive to officially support ECC on the "enthusiast" parts, since that could potentially cut into the sales of the (presumably higher-margin) upcoming Naples variant for servers.

At the end of the day, the motherboard vendors and AMD are in this to make money, not to make everyone happy by including every feature anyone might want. They're going to focus on where they think they can make the most profit.

Well that is a good point. I suppose that I don't really have a need for ECC. Now I know that every new platform is going to have teething issues, but so far AMD has seems to have released a solid product with Ryzen. However if I was in the market to do another build, I would wait a few months for the teething issues to be resolved and for better Linux support to roll out. But that is me.

just brew it! wrote:

whm1974 wrote:

Just another beef with hardware manufacturers I have. Yes I know fully well that no one is perfect and AMD has very big hill to climb, but shouldn't a very important feature be supported at launch?

It is only "very important" to people who want to use AM4/Ryzen as a way to build high-reliability server/NAS boxes without shelling out for an Intel server platform. These people represent a small segment of the market, and are therefore not "very important" to the makers of enthusiast/gamer-oriented motherboards. For AMD, it is arguably counter-productive to officially support ECC on the "enthusiast" parts, since that could potentially cut into the sales of the (presumably higher-margin) upcoming Naples variant for servers.

At the end of the day, the motherboard vendors and AMD are in this to make money, not to make everyone happy by including every feature anyone might want. They're going to focus on where they think they can make the most profit.

Previous generations of AMD CPU's and motherboards supported ECC and gamers sneered because Intel's use of non ECC DDR in the consumer market made their memory faster. I'll be surprised if any board can support ECC at the highest DDR speeds.

I forgot which, some other vendor was beginning to mention limited ECC support. AMD has confirmed Ryzen supports it, that's not the issue. I'm pretty sure it will get enabled at some point, but right now it looks like AM4 boards have too many other higher priority UEFI issues to resolve before they work on getting ECC support functional and validated.

Looks like it has been confirmed that the ASRock X370 Taichi supports it: http://www.hardwarecanucks.com/forum/ha ... -dive.html

whm1974 wrote:

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

The part I don't understand is how it's even possible for ECC not to work in the first place; The controller is on the CPU!

just brew it! wrote:

Looks like it has been confirmed that the ASRock X370 Taichi supports it: http://www.hardwarecanucks.com/forum/ha ... -dive.html

Interesting. So the good news was that with the right tweaking they were able to ensure that the ECC memory was actually running in ECC mode.
But it's still not quite there because with an uncorrectable error the system kept on chugging instead of halting. Hopefully they can fix that in the firmware.

Vhalidictes wrote:

whm1974 wrote:

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

The part I don't understand is how it's even possible for ECC not to work in the first place; The controller is on the CPU!

The memory buses need to be 72 bits wide instead of 64, to support the ECC bits. If the motherboard designer doesn't provide the extra PCB traces between the CPU socket and DIMM slots, ECC won't work even if the memory controller and DIMMs support it.

chuckula wrote:

just brew it! wrote:

Looks like it has been confirmed that the ASRock X370 Taichi supports it: http://www.hardwarecanucks.com/forum/ha ... -dive.html

Interesting. So the good news was that with the right tweaking they were able to ensure that the ECC memory was actually running in ECC mode.
But it's still not quite there because with an uncorrectable error the system kept on chugging instead of halting. Hopefully they can fix that in the firmware.

Seems like that should be the OS's responsibility. The OS knew the UCE occurred, since it logged it. OS should trigger a kernel panic / BSOD when it detects an uncorrectable error.

just brew it! wrote:

chuckula wrote:

just brew it! wrote:

Looks like it has been confirmed that the ASRock X370 Taichi supports it: http://www.hardwarecanucks.com/forum/ha ... -dive.html

Interesting. So the good news was that with the right tweaking they were able to ensure that the ECC memory was actually running in ECC mode.
But it's still not quite there because with an uncorrectable error the system kept on chugging instead of halting. Hopefully they can fix that in the firmware.

Seems like that should be the OS's responsibility. The OS knew the UCE occurred, since it logged it. OS should trigger a kernel panic / BSOD when it detects an uncorrectable error.

Apparently it's a configurable option: https://groups.google.com/forum/#!topic ... Vgso6u2GP0

If the system was running the default (and maybe it wasn't) then it's a somewhat vague "always panic OR SIGBUS". That means maybe if the memory error occurred in a normal user-level program that some program on their test machine bailed out with a SIGBUS error but the overall system kept running. If the same memory error had occurred during a kernel-space operation then (presumably) the system would have crashed with a panic.

chuckula wrote:

just brew it! wrote:

chuckula wrote:

Interesting. So the good news was that with the right tweaking they were able to ensure that the ECC memory was actually running in ECC mode.
But it's still not quite there because with an uncorrectable error the system kept on chugging instead of halting. Hopefully they can fix that in the firmware.

Seems like that should be the OS's responsibility. The OS knew the UCE occurred, since it logged it. OS should trigger a kernel panic / BSOD when it detects an uncorrectable error.

Apparently it's a configurable option: https://groups.google.com/forum/#!topic ... Vgso6u2GP0

If the system was running the default (and maybe it wasn't) then it's a somewhat vague "always panic OR SIGBUS". That means maybe if the memory error occurred in a normal user-level program that some program on their test machine bailed out with a SIGBUS error but the overall system kept running. If the same memory error had occurred during a kernel-space operation then (presumably) the system would have crashed with a panic.

Hmm... OK. I think that actually clears things up. In the article I linked, Linux was using the EDAC method of detecting/reporting memory errors, which uses a different mechanism for deciding what to do in the case of an uncorrectable error. For systems using EDAC, the edac_mc_panic_on_ue option must be enabled to cause a panic on error, and this option apparently defaults to off.

I have no idea why the default actions are inconsistent for MCE vs. EDAC detection methods, but there you have it.

So really the only remaining question seems to be whether machine check exceptions are supported, or if only EDAC is supported.

just brew it! wrote:

Vhalidictes wrote:

whm1974 wrote:

It really that hard for motherboard manufacturers to clearly state what features are support by their products? And how to enable them?

The part I don't understand is how it's even possible for ECC not to work in the first place; The controller is on the CPU!

The memory buses need to be 72 bits wide instead of 64, to support the ECC bits. If the motherboard designer doesn't provide the extra PCB traces between the CPU socket and DIMM slots, ECC won't work even if the memory controller and DIMMs support it.

Thank you jbi, I forgotten about the memory buses needing to be 72 bits wide to be able to use ECC memory. Thanks for reminding me.