5 ms·

I’ve bought a Ryzen 5 for a home server, but sadly is awfully unstable. Apparently there is a bug in the Ryzen family. I’m using it with Freenas 11 (FreeBSD) an

I’ve bought a Ryzen 5 for a home server, but sadly is awfully unstable. Apparently there is a bug in the Ryzen family. I’m using it with Freenas 11 (FreeBSD) and the system is having horrible random freezes with black screen. There are some threads talking about same issues, this make me lose faith in AMD, and going back to Intel.

terminalcommand 9y ago
Have you tried disabling SMT? And have you tried installing the latest microcode update? AMD has been having problems for a while, but I think they ought to have been fixed by now. I, myself was thinking to acquire a Ryzen 5 1600 for a high performance programming desktop. I was thinking of running FreeBSD, it's sad to hear that it's glitchy.
- loeg 9y ago
  FreeBSD works great on Ryzen. I'm running it on a 1950x, no issues at all.
- ahartmetz 9y ago
  Disabling SMT only reduces the frequency of the segfault bug occurring. AFAIK it does nothing for random whole machine freezes, for which there is a reliable workaround (other post of mine).
quickben 9y ago
Would it be possible it's a motherboard issue? I went through two mbs until I got a stable one. 1700x here.
loeg 9y ago
Is it the known segfault defect affecting CPUs made before June? If so, return or RMA your chip.
jagger27 9y ago
"Never buy first gen" is always and always has been sage advice. I'm planning to upgrade my 3570K build at the next revision.
ahartmetz 9y ago
Disable "Global C-State Control" in UEFI to work around the bug. It seems to be a perfectly reliable workaround.
mixedCase 9y ago
This is an acknowledged and solved fab issue. Get it RMA'd.
- paulmd 9y ago
  It is not a solved issue at all. Chips are still coming off the line with the issue, the only solid fix is getting an RMA'd processor (AMD are hand-checking these units for the issue). 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 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.
  - mrchicity 9y ago
    Didn't know that. Since they know how to fix it on TR/Epyc, why would they release a brand new line with the same issue?
    - paulmd 9y ago
      Well, we don't actually know if they did fix it on TR/Epyc. 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.
mrchicity 9y ago
Check whether your chip is affected by the segfault bug. It affects Ryzen CPUs, but not Threadrippers or Epycs. It's a free RMA: https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/ https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilati... If your system is totally new, try checking your RAM with memtest too. My Threadripper build had similar issues in Linux and Windows. Ended up being my PSU. I tried to save $30 buying a refurb one from Corsair. My system would lock up occasionally at totally stock settings and even shutdown on its own. Works perfectly now after I swapped it out. FWIW, I'm really happy with the Threadripper/X399. Most of the early Ryzen bugs are worked out. It's a great value for the performance. Compiling large C or C++ code bases is insanely fast. Still, I'd be wary of buying AMD's first gen mobile offering. When you buy a laptop you're buying a whole system and battery life, no glitches after sleep/wake, heat, noise, etc. trump raw performance. Intel has way more experience there. This Radeon iGPU also sits in a weird market segment. People who don't game/render/3D model on the go do just fine with the weak Intel iGPU. People who really care about that stuff can get a big laptop with faster dGPU or just do 3D on their desktop. So I guess their target is people who casually game but want a thin-ish laptop? NB: I don't doubt AMD's ability to make a decent mobile platform. Just Intel has shipped hundreds of millions more units, so they've seen every "system crashes after sleep when re-pairing with $OBSCURE_BLUETOOTH_DEVICE" issue on earth. On a desktop you can always swap hardware, but on a laptop you're stuck with what you get.
- paulmd 9y ago
  > On a desktop you can always swap hardware, but on a laptop you're stuck with what you get. Raven Ridge is the same stepping as Ryzen, i.e. potentially subject to the segfault bug. I'm really curious whether it will manifest there too or not. It's a pretty generic errata that manifests under load. Compiling happens to be one way that flushes it out pretty reliably (as with many errata), and nerds do a lot of compiling in Linux, but it can and does manifest as general OS and application crashiness even in other operating systems (including in Windows). It's a ticking time-bomb, sooner or later some OS or application update could hit the trigger conditions more regularly. There's nothing quite like being "the brand that randomly crashes all the time" to build a brand image with your customers. And I'm sure OEMs are going to love handling RMAs for AMD's defective processors.

terminalcommand 9y ago

Have you tried disabling SMT? And have you tried installing the latest microcode update? AMD has been having problems for a while, but I think they ought to have been fixed by now. I, myself was thinking to acquire a Ryzen 5 1600 for a high performance programming desktop. I was thinking of running FreeBSD, it's sad to hear that it's glitchy.

loeg 9y ago
FreeBSD works great on Ryzen. I'm running it on a 1950x, no issues at all.
ahartmetz 9y ago
Disabling SMT only reduces the frequency of the segfault bug occurring. AFAIK it does nothing for random whole machine freezes, for which there is a reliable workaround (other post of mine).

quickben 9y ago

Would it be possible it's a motherboard issue? I went through two mbs until I got a stable one. 1700x here.

loeg 9y ago

Is it the known segfault defect affecting CPUs made before June? If so, return or RMA your chip.

jagger27 9y ago

"Never buy first gen" is always and always has been sage advice. I'm planning to upgrade my 3570K build at the next revision.

ahartmetz 9y ago

Disable "Global C-State Control" in UEFI to work around the bug. It seems to be a perfectly reliable workaround.

mixedCase 9y ago

This is an acknowledged and solved fab issue. Get it RMA'd.

paulmd 9y ago
It is not a solved issue at all. Chips are still coming off the line with the issue, the only solid fix is getting an RMA'd processor (AMD are hand-checking these units for the issue). 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 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.
- mrchicity 9y ago
  Didn't know that. Since they know how to fix it on TR/Epyc, why would they release a brand new line with the same issue?
  - paulmd 9y ago
    Well, we don't actually know if they did fix it on TR/Epyc. 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.

mrchicity 9y ago

Check whether your chip is affected by the segfault bug. It affects Ryzen CPUs, but not Threadrippers or Epycs. It's a free RMA: https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilation_segfaults_positive_rma/ https://www.reddit.com/r/Amd/comments/6ubmd1/ryzen_compilati... If your system is totally new, try checking your RAM with memtest too. My Threadripper build had similar issues in Linux and Windows. Ended up being my PSU. I tried to save $30 buying a refurb one from Corsair. My system would lock up occasionally at totally stock settings and even shutdown on its own. Works perfectly now after I swapped it out. FWIW, I'm really happy with the Threadripper/X399. Most of the early Ryzen bugs are worked out. It's a great value for the performance. Compiling large C or C++ code bases is insanely fast. Still, I'd be wary of buying AMD's first gen mobile offering. When you buy a laptop you're buying a whole system and battery life, no glitches after sleep/wake, heat, noise, etc. trump raw performance. Intel has way more experience there. This Radeon iGPU also sits in a weird market segment. People who don't game/render/3D model on the go do just fine with the weak Intel iGPU. People who really care about that stuff can get a big laptop with faster dGPU or just do 3D on their desktop. So I guess their target is people who casually game but want a thin-ish laptop? NB: I don't doubt AMD's ability to make a decent mobile platform. Just Intel has shipped hundreds of millions more units, so they've seen every "system crashes after sleep when re-pairing with $OBSCURE_BLUETOOTH_DEVICE" issue on earth. On a desktop you can always swap hardware, but on a laptop you're stuck with what you get.

paulmd 9y ago
> On a desktop you can always swap hardware, but on a laptop you're stuck with what you get. Raven Ridge is the same stepping as Ryzen, i.e. potentially subject to the segfault bug. I'm really curious whether it will manifest there too or not. It's a pretty generic errata that manifests under load. Compiling happens to be one way that flushes it out pretty reliably (as with many errata), and nerds do a lot of compiling in Linux, but it can and does manifest as general OS and application crashiness even in other operating systems (including in Windows). It's a ticking time-bomb, sooner or later some OS or application update could hit the trigger conditions more regularly. There's nothing quite like being "the brand that randomly crashes all the time" to build a brand image with your customers. And I'm sure OEMs are going to love handling RMAs for AMD's defective processors.