The 4.12.5 kernel still crashes for me on Slackware. One machine was on BIOS defaults running the mesa test, it finished with 8/10 successful builds. Second machine was running libdrm test on 2 cores and first build crashed after 34 minutes. The numbers look typical.
After reading all 49 pages of this thread, I figured I should add my own experience. I have a Ryzen 7 1700 running at stock frequency that has been exhibiting erratic behavior. I have been getting MCE errors and random reboots while using Windows 10. Additionally, when I installed Debian 9.1, I was able to produce segfaults using the Phoronix Test Suite with the same settings as Michael Larabel used over at Phoronix to confirm the segfault issue. I have also noticed that my particular processor is very sensitive to memory speed and timings as I am unable to run memory at speeds specified by my motherboard's memory qvl. I was able to find a stable memory configuration that consistently passes MemTest86 overnight and Stressful App Test with no errors, but the memory runs below what I expected based on the qvl. At this point, I am reasonably certain that my remaining issues are simply due to a particularly flakey piece of silicon as adjusting the CPU and SoC voltages in accordance with some of the previous posts had no effect. I have not checked which production week my processor is as of yet, but I will document that at some point.
Ryzen 7 1700 @ stock frequency
Cooler Master Hyper 212 EVO
ASUS PRIME X370-PRO with BIOS 0805 AGESA 184.108.40.206a
G.SKILL TridentZ F4-3000C15D-32GTZ @ 2800MHz
I got the second RMA'd processor. As mcl00 already reported in #642, it has stepping 1 and UA 1725SUS printed on the processor while my original one has UA 1707PGT and the first RMA'd one has UA 1716PGT.
I tested more than 13 hours last night with stock BIOS settings and no workarounds (it means SMT enabled, uOP cache enabled, ASLR enabled), and got no segfaults.
17 is supposed to be the YEAR (2017)
25 is supposed to be the WEEK (so this means end of June).
SUS is supposed to be where it was packaged
Please post the UA numbers that the rest of you guys get. Hopefully, we can find out what the cutover date is when this was fixed in the fabs.
@fuji: That's great news. Congrats on getting a working CPU! If this is indeed a Silicon issue, then there's no need to randomly keep poking around!
How long does AMD normally get round to replying to service requests? It's been 2 days for me (got the confirmation email to say that I had raised an issue) but nothing since (is there a site I can login to to track the status ?)
Also my current R7 1700 is UA 1707SUT and surfers from the segfaults and the kernel logged MCEs
Ahh cheers. At least that gives AMD time to sort a generic solution fo everyone who is having these issues.
I'd imagine that it will just be a replacement chip (as long as they know the newer chips are not affected)