The assertion of there being a "safe date range" (ostensibly, date codes >= 1730, i.e. chips manufactured during/after Week 30 2017) was made by the Phoronix Forums webmaster on the basis that he hadn't seen any user posts reporting problems with chips that had been manufactured within the last 3 weeks. Obviously it takes a while for stock to move through packaging and distribution, so this was a pretty stupid proclamation to make. Since then, chips from the "safe date range" (eg 1733) have started showing up with the segfault problem, but his mis-information persists.
https://community.amd.com/thread/215773?start=1770&tstart=0
The only processors that are relatively certain to not have this issue are the ones that come from filing an RMA with AMD. Full stop. And even some of those still have the issue.
It's a broad-base issue that causes general application and OS instability under load, it is not restricted to either Linux nor compilation workloads. I definitely encourage everyone to test their processor and RMA if necessary.
Epyc is on a newer stepping (that has not been released to the consumer market yet), but the issue was only acknowledged a couple months ago. The B2 stepping may already have been taped out at that point. We don't really know because you pretty much can't get ahold of Epyc systems at the moment (at the moment, the only way is by ordering prebuilt servers from SuperMicro). There hasn't been the degree of testing that you have on Ryzen. But, if the B2 stepping does contain a fix, that would be the reason that Epyc is immune.
Threadripper is on the same stepping, but it's cherrypicked silicon (AMD claims they're the top 5% of silicon off the line). There is a wide range of severity reported with Ryzen processors, some people segfault in seconds, others it takes 24h+ of testing before it manifests. That strongly suggests that it's a litho problem, and the fact that Threadripper is on cherrypicked silicon may insulate it somewhat from this issue. But in general I don't see any guarantee there either. There isn't anywhere near as much testing as there is on Ryzen here either (although certainly more than Epyc).
From what I've read the finger points pretty strongly at a cache problem (likely the uop cache) and it's also possible that TR/Epyc's NUMA configuration somehow avoids the trigger conditions for this bug. I don't think this case is particularly likely but it's one possible explanation.
Frankly though I don't understand why AMD hasn't released the B2 stepping to the consumer market. They are using it for Epyc but they are still producing Ryzen and TR on the original B1 stepping and appear to be releasing Raven Ridge on the B1 stepping as well. I don't know whether the B2 stepping contains a fix for this issue, but I'm sure it has some general fixes that would be good to have.
