I've just proofed my setup (1700 w/ asrock gaming board) using a 4 pass memtest and prime95 run w/o issue. OS : ubuntu 17.04.
I will now run the famed compile test found at :
http://funks.ddns.net:8080/tools/ryzen/testRyzenGCC.sh
and report back
TBH, i have a funny feeling people aren't proofing their setup via stress test/memtest and some instability therein is causing the issue in the compile test.
We'll see shortly if I get a clean pass.
[Edit5 17August2017: Long story short, after disabling ASLR I have been unable to reproduce the problem documented in the following paragraphs.]
I discovered the magnitude of this problem when I tried building kernel 4.12.4 yesterday. Using large thread counts, I had *mostly* failures compiling the 21,785,906 lines of code. This is 1000x as big as my main project -- which has never failed to compile.
I disabled ASLR this morning.
Today I've done successful runs at 12, 18, and 24 threads. I'm currently in the midst of 10 consecutive runs at 18 threads. Anyway, no failures in 7 runs after disabling ASLR. From my reading I don't think that's the cure, but clearly it greatly reduces the chance of hitting the bug, at least on my system.
Edit1: Added the following line to /etc/sysctl.conf to persistently disable ASLR:
kernel.randomize_va_space = 0
Followed by the command 'sysctl -p' to make it take effect immediately. This should work on most any Linux distro. replacing the '0' with a '1' will enable a conservative address space randomization and a '2' will more aggressively randomize address space locations. My distro (Mint 18) defaulted to '2' -- which can be viewed at /proc/sys/kernel/randomize_va_space
Edit2: My 10x run of 18t Linux 4.12.4 compiles completed successfully. That brings the consecutive successes to 14 since disabling ASLR.
Edit3: I ran an additional set of 12 compiles at 12 threads, also without errors. That brings the total to 26 consecutive compiles of Linux 4.12.4 and a grand total of 566,433,556 lines of code compiled at 12 threads or higher without problems. So, considering how slow I write code, I think my config is going to be OK.
Edit4 05August2017: I configured my test script for an additional 26 x Linux compiles in 12 threads. A couple of hours into the test I had a failure. So, confirming my suspicions -- and consistent with others' tests -- disabling ASLR only reduces the frequency of failures. I'm not going to bother with further tests. I'm of the opinion that there may be more than one problem going on. I've read (somewhere) about an SMT-specific failure, and tests with SMT disabled also fail, albeit with reduced frequency. Other testers have reported reduced failures with uOP caching disabled as well.
Of course, we have no way of knowing how rigorously any random system has been tested for hardware problems -- which means we can't really trust any specific report from around the internet. AMD must find these problems themselves, and probably already have.
Edit5 17August2017: I had a bug in my script and the 'make clean' step was removing one of my vmlinux images. That accounted for *all* of the failures with ASLR disabled. That is, it turns out I have had NO failures since disabling ASLR. And, of course, after fixing the flawed script, I've ran a few additional dozen compiles, also with no failures.
TL;DR: Initially I encountered failures in *most* 12+ thread Linux compiles but then disabled ASLR and I have since done 26 straight compiles without the error. [Edit5]: A second run of 26 compiles produced no failures -- bringing the total to 0 failures in 1,132,867,112 lines of code compiled. [this number doesn't include the uncounted successful compiles after edit4.]