Ryzen does support ECC, but, mainboards need to enable it, and...

[inf64]

So does Ryzen also support all the virtualization extensions and stuff?

Edit: Ah well. Rereading this thread makes it seem hit or miss. Probably a wait.

Ryzen has full support for AMD's Virtualization instructions.

 

[MartijnU]

So does Ryzen also support all the virtualization extensions and stuff?

Edit: Ah well. Rereading this thread makes it seem hit or miss. Probably a wait.

 

[MartijnU]

In the ASRock AB350 Pro4 BIOS, SVM and IOMMU can be enabled. When done so, lscpu under kernel 4.10 shows:

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 1
Model name: AMD Ryzen 7 1700 Eight-Core Processor
Stepping: 1
CPU MHz: 1550.000
CPU max MHz: 3000.0000
CPU min MHz: 1550.0000
BogoMIPS: 5988.91
Virtualization: AMD-V
L1d cache: 32K
L1i cache: 64K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 0-15
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca

Reading the Wikipedia article and checking flags, I come to the conclusion that all modern virtualization support has been present in all AMD CPUs, and is also present in Ryzen.

https://en.wikipedia.org/wiki/X86_virtualization

 

[Soulkeeper]

I purchased memtest86 pro because it had the ecc error injection test.
Unfortunately it's listing ecc as N/A right now on my ryzen setup.
I'll be testing further in linux, I noticed the kernel has an error injection setting for testing.
gigabyte gaming 7, ryzen 1800, and 4x16 kingston 2400 hynix ecc here.
This bios is very limited right now, hopefully it gets updated.
The "Manual" and the "Advanced Manual" have just the 4 timings and no other settings yet.

 

[Soulkeeper]

Ok, i'm getting the same results as the hardwarecanucks guys.

dmesg |grep -i edac
[    0.656168] EDAC MC: Ver: 3.0.0
[    0.853089] EDAC amd64: DRAM ECC enabled.
[    0.853226] EDAC amd64: F17h detected (node 0).
[    0.853392] EDAC MC: UMC0 chip selects:
[    0.853393] EDAC amd64: MC: 0: 32767MB 1: 32767MB
[    0.853534] EDAC amd64: MC: 2: 32767MB 3: 32767MB
[    0.853673] EDAC amd64: MC: 4:     0MB 5:     0MB
[    0.853808] EDAC amd64: MC: 6:     0MB 7:     0MB
[    0.853945] EDAC MC: UMC1 chip selects:
[    0.853945] EDAC amd64: MC: 0: 32767MB 1: 32767MB
[    0.854081] EDAC amd64: MC: 2: 32767MB 3: 32767MB
[    0.854216] EDAC amd64: MC: 4:     0MB 5:     0MB
[    0.854351] EDAC amd64: MC: 6:     0MB 7:     0MB
[    0.854489] EDAC amd64: using x8 syndromes.
[    0.854620] EDAC amd64: MCT channel count: 2
[    0.854830] EDAC MC0: Giving out device to module amd64_edac controller F17h: DEV 0000:00:18.3 (INTERRUPT)
[    0.855068] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[    0.855300] AMD64 EDAC driver v3.4.0

edac-util --v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc0: csrow0: 0 Uncorrected Errors
mc0: csrow0: mc#0csrow#0channel#0: 0 Corrected Errors
mc0: csrow0: mc#0csrow#0channel#1: 0 Corrected Errors
mc0: csrow1: 0 Uncorrected Errors
mc0: csrow1: mc#0csrow#1channel#0: 0 Corrected Errors
mc0: csrow1: mc#0csrow#1channel#1: 0 Corrected Errors
mc0: csrow2: 0 Uncorrected Errors
mc0: csrow2: mc#0csrow#2channel#0: 0 Corrected Errors
mc0: csrow2: mc#0csrow#2channel#1: 0 Corrected Errors
mc0: csrow3: 0 Uncorrected Errors
mc0: csrow3: mc#0csrow#3channel#0: 0 Corrected Errors
mc0: csrow3: mc#0csrow#3channel#1: 0 Corrected Errors
edac-util: No errors to report.

 

[MartijnU]

My ASRock AB350 Pro4 board with 2x4GB Crucial CT2K4G4WFS8266 has output:

dmesg | grep -i edac
[ 8.007406] EDAC MC: Ver: 3.0.0
[ 8.009559] EDAC amd64: DRAM ECC enabled.
[ 8.009560] EDAC amd64: F17h detected (node 0).
[ 8.009595] EDAC MC: UMC0 chip selects:
[ 8.009596] EDAC amd64: MC: 0: 0MB 1: 0MB
[ 8.009597] EDAC amd64: MC: 2: 0MB 3: 0MB
[ 8.009597] EDAC amd64: MC: 4: 0MB 5: 0MB
[ 8.009597] EDAC amd64: MC: 6: 0MB 7: 0MB
[ 8.009599] EDAC MC: UMC1 chip selects:
[ 8.009600] EDAC amd64: MC: 0: 0MB 1: 0MB
[ 8.009600] EDAC amd64: MC: 2: 0MB 3: 0MB
[ 8.009601] EDAC amd64: MC: 4: 0MB 5: 0MB
[ 8.009601] EDAC amd64: MC: 6: 0MB 7: 0MB
[ 8.009601] EDAC amd64: using x8 syndromes.
[ 8.009602] EDAC amd64: MCT channel count: 2
[ 8.009656] EDAC MC0: Giving out device to module amd64_edac controller F17h: DEV 0000:00:18.3 (INTERRUPT)
[ 8.009665] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
[ 8.009665] AMD64 EDAC driver v3.4.0

Comparing to output above I cannot make sense of MC memory amounts. It cannot be zero in mine, cannot be 32768 MB per MC (Memory Channel?) either as this would exceed total amount supported by the processor.

Memtest86 also lists ECC Enabled: N/A at my setup. Scanned release notes, no word on it for AMD Ryzen support, only recently fixed issues for Xeon E3-12xxv5, while meanwhile v6 has also been launched. It seems they are behind.

Note that ASRock officially supports ECC, and Crucial officially supports these memory modules for this specific mainboard. That's all certainty we can get for now, it seems.

 

[fleshconsumed]

FYI got ASRock X370 Fatal1ty Professional working with Kingston KVR24E17D8/16MA 16GB/module RAM. Didn't have time to install OS, but the combo works. Gave me a scare for a few hours because motherboard would get stuck at code 48 and would not post, but clearing CMOS solved that issue.

I just hope that windows will improve Ryzen ECC support so that we won't have to guess whether it's really working or not.

 

[cbn]

it is all up to the mainboard if they wish to issue a BIOS that enables it.

This was answered on the AMA,

https://www.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_creators_of_athlon_radeon_and_other/def7z72/

So I am assuming there would eventually be some processors (Opterons and maybe FirePro APUs?) coming with official (ie, validated) ECC Support.

And with these new processors would there also be a new chipset? Or would this validated ECC Support (via Opteron) work on Any AM4 board that supports Opteron?

 

[richaron]

So I am assuming there would eventually be some processors (Opterons and maybe FirePro APUs?) coming with official (ie, validated) ECC Support.

And with these new processors would there also be a new chipset? Or would this validated ECC Support (via Opteron) work on Any AM4 board that supports Opteron?

Of course there will be official chips with ECC, they would be a non-starter in the the enterprise sector otherwise. And this is where the Ryzen's modular approach means all products in the stack have the same basic features in hardware.

AMD could have acted like the competition and artificially crippled their lower end products in an attempt at market segmentation, but they have made a name in the past with less hostile and more open practices (core unlocking, unlocked multipliers, ECC on AM3+, etc). So I guess the compromise was simply not to waste time officially supporting Ryzen ECC, whilst they also didn't forcefully disable the feature.

Lastly, yes a bigger CPU with more memory channels will usually require a different socket and probably a different chipset. Sometimes not (see TR & Opteron sockets), but this is all really a moot point because the memory controller (which supports ECC) is inside the CPU, not the chipset. So there will never be an AM4 Opteron, and the chipset has nothing to do with ECC support. Since some motherboards do "support" ECC memory this means the motherboard makers have deliberately enabled and tested ECC enough to be confident in advertising the feature (AKA "validated").

 

[cbn]

[

Lastly, yes a bigger CPU with more memory channels will usually require a different socket and probably a different chipset. Sometimes not (see TR & Opteron sockets), but this is all really a moot point because the memory controller (which supports ECC) is inside the CPU, not the chipset. So there will never be an AM4 Opteron, and the chipset has nothing to do with ECC support.

1.) In the past, there have been four to eight core Piledriver Opterons (based on one die, of course) and these used socket G32:

https://en.wikipedia.org/wiki/List_...s#Opteron_4300-series_.22Seoul.22_.2832_nm.29

So you don't think there would be Opterons based on a single Zeppelin die?

2.) Agree about the chipset. Example: My Dell Precision T3500 uses a Xeon and is validated (of course) to work with ECC UDIMMs despite the chipset being a consumer one (X58).

P.S. Would be very interesting to also see a FirePro APU (in addition to single die Opteron) considering the 1/2 rate Double Precision Floating point found in Bristol Ridge APU (and hopefully in Raven Ridge APU as well). (SIDE NOTE: In the past, I have thought APUs for desktop were not desirable for reasons I posted here....but if some of the APU dies were used for FirePro desktop APUs (rather than regular consumer desktop APUs)......)

 

[cbn]

Here is more ECC testing: http://www.hardwarecanucks.com/foru...ws/75030-ecc-memory-amds-ryzen-deep-dive.html

In conclusion, what is currently available on the AM4 platform is an incomplete implementation of ECC. This is very likely why motherboard manufacturers have been relatively hesitant about claiming that their products support ECC memory in ECC mode. Based on our findings, there is clearly some level of ECC functionality that is working right now, but it does not cover the full spectrum of memory error detection and correction. Having said that, the status quo is arguably better than nothing, especially since single-bit errors are much more likely than multi-bit errors (which are often caused by a failing memory module), so I suspect that many people will still want the extra protection that is available right now.

While actual ECC validation will likely never occur on this consumer platform, if public interest in this feature keeps growing we fully expect motherboard manufacturers to step up to the plate and improve their ECC support. However, we strongly suspect that AMD will first have to release an update to their CPU microcode to fully unlock all of the necessary settings. Furthermore, there definitely needs to be some work done at the operating system level to let users know when ECC is enabled and what it is doing, more so on the Windows side than the Linux one.

 

[cbn]

Deleted.