AMD must be getting thousands of RMAs. I'm sure they are just overwhelmed. I'm tempted to pick up a 1300 or 1600 in the meantime, then RMA that one in hopes of overclocking a new spare media server.
I can only write to the Asus Crosshair VI Hero board. One can adopt an XMP DRAM profile, or construct a set of settings of myriad timing parameters for oneself. (My settings are for operating at 3333 MT/s on 2 x 16 dual rank G.Skill DRAM.) CPU speeds, however, are set w.r.t. the Advanced page. One can turn off the pre-programmed speeds and set all cores to a specific speed. Or one can enable P-state control, in which case the CPUs' frequencies can vary with their loads between P(0), P(1), and P(2) frequencies. This is run by, I think, the Linux kernel.
In any case, I can see via the tool bar widgets available in Mint 18.1 MATE that upon setting them to "on-demand" the P-state frequencies I am using -- 3.8 GHz, 3.2 GHz (I think) and 2.2 GHz -- are the states the CPUs operate at. I have hibernation disabled so I am uncertain whether C-states are ever relevant.
I don't see any connection between XMP profiles and CPU speeds, other than that the highest stable frequency of the CPU cores and the highest stable transfer rate one might obtain for a particular set of DRAM, may not be achieved simultaneously in some cases (measured by stress tests), requiring some backing off.
I've bought a Ryzen 3 1200 while I'm waiting for my R7 1700X replacement (it's 3rd week already and no news from AMD) as I need that computer for daily work. While it's mostly fine, I'm having strange cold boot issues with it. Various processes segfault in a seemingly random manner and eventually a hard lock happens without any errors in the system log at that moment. These issues stop on reboot but then reappear again on the next cold boot.
There was no such trouble with R7. Maybe it's just somehow caused by swapping the CPU but it shouldn't really matter and only happening on cold boot hints at something being misconfigured and then properly reset on reboot. Wondering if it's faulty hardware again or maybe BIOS needs to be reinstalled.
Also I couldn't trigger the compilation segfault in 24h on it but then it doesn't have SMT so should be much harder to trigger.
What is your RAM clock, and have you tried downclocking?
I had a similar problem because the RMA replacement couldn't go quite as high as the old CPU.
In my case, prime95 / mprime (prime95 for Linux) "blend" test was much more effective than memtest at reproducing memory related instability.
RAM is running at 2400. It's a 2666 rated kit of 32GB and it won't go higher than 2400 on both Ryzen CPUs. I haven't tried running it at 2133 yet though.
Less than a day after I posted about how great my replacement CPU was, my computer froze. Twice. I disabled "C States" in BIOS again, so I'll see if that help. The compile issue is still good, though.
ASRock X370 Gaming K4, latest 3.30 BIOS (AGESA 22.214.171.124b). My faulty R7 1700X (that's currently stuck in RMA somewhere) had no such problems on the same board and BIOS.
A little follow up on my computer. As I said, my RMAed CPU does not present segfaults when compiling, but it still freezes under low load. It seems that I found a workaround (at least my computer did not freeze this weekend). I compiled my kernel with CONFIG_RCU_NOCB_CPU. After doing that and installing the new kernel the freezes went away. To compile the kernel in Ubunt you may try to follow:
It worked for me. Good luck!