|
|
|
|
|
by paulmd
3216 days ago
|
|
AMD has never stated that there is a fix for this. If you look at the link you posted, this is Larabel making this claim on the basis that he hasn't seen any forum posts noting this problem on samples manufactured after week 25. Quote: > AMD has not provided an official public explanation of the fundamental problem, but from those in our forums and elsewhere, it appears to affect Ryzen CPUs manufactured prior to week 25. This problem only affects a minority of chips in the first place (likely a litho flaw in the cache section), it's probable that Larabel's second CPU just didn't happen to be one of the ones with problems. And Week 25 ends June 25, i.e. stock for these date ranges has hardly even made it through packaging/distribution to end users let alone been extensively tested yet. Larabel is jumping the gun on insufficient evidence and people are racing to make the claim that AMD has fixed this, when that's far from the case. AMD certainly hasn't made any statements to this effect. AMD is RMA'ing afflicted units, which is really all that can be done until they get a new stepping out. But I've seen no evidence that this is actually fixed. |
|
What are you basing this on? I've seen no good reporting on this* but the AMD Community segfault thread (https://community.amd.com/message/2796982) seems to suggest that almost all Ryzen CPUs manufactured before the end of June (which I assume is most of the current stock) are affected. Very few people load their Ryzens sufficiently to hit this bug, but a large number of those who attempt it seem to get the segfault.
* I would like to know the percentage of processors with the bug, percentage of review units with the bug (I would be very interested in this), and maybe some long-term testing of "bug free" processors etc.