The Ryzen 5 2600X & Ryzen 7 2700X - Coming Soon To Linux Desktops

[Brisse]

All I care about is bugs. I'll buy when all the problems

* spectre
* meltdown
* so called "Linux performance marginality"

are solved. Sadly, I have no real reason to upgrade my AMD Llano from 2012 :-(



Lycky you. My last Intel processor (Core 2 Duo) had this funny bug, that with all modern tickless kernels, it would hang without constant user input. I stayed away from Intel ever since.

* spectre - Software fixes are being rolled out as we speak.
* meltdown - Never affected Ryzen to begin with
* so called "Linux performance marginality" - Was fixed in Ryzen's produced after week 25 2017.

Not sure what you're waiting for...

[Herem]

Here's hoping this goes more smoothly for me than using AMD hardware has in the past. I've had 3 Intel+Nvidia systems that've all kept working without issues until I replaced them, while on the AMD side I have an RX 480 that had to be RMA'd after it failed after only a week and then a Ryzen motherboard that failed after only a year. I want to support AMD and I think their recent CPUs are great, and I'm going to try getting a zen+ CPU to replace my current older Intel CPU(off to order one from Newegg, in fact), but if it has issues too then it's just not worth the extra effort. I'm sure the vast majority of other people have no problems with these things - I just wish I was in the same boat.

To be fair only one of your issues was directly down to AMD (depending on what exactly failed and assuming the RX 480 was a reference card). The other fault was more likely down to the motherboard manufacturer, who more likely than not manufacture Intel motherboards as well.

[wizard69]

Everybody gets unlucky at times with hardware guys, making buying decisions based on past experiences probably isnt sound in the world of electronics.

Stability is another issue which im hoping Micheal can shed some light on. These are not APUs so im hoping for clean sailing. Im especially interested in distros in beta at the moment as purchase is off into the future plus i want the latest kernel and apps tested.

So Micheal if you can stability testing is a big concern. Add to that parallel processing work loads such as Ray tracing or kernel compiles. I see these as low end work station processors so testing ought to reflect that.

It is a bit funny considering what old hardware did but how many out there now see 100 watt processors as a bit on the hot side? Ive converted most of my house to LED lighting and those watts do add up.

[kaczu]

I'm very much interested in the power measurements of the new x470 chipsets. Hope they are more efficient when idle. My Ryzen 3 2200G consumes 30 watt with a b350 chipset, for a media center I would like to get this down.
This idle bug should have gotten more attention by AMD, at least I hope as well that the new Ryzen's will run stable now by default right from the start.

Huh? 30W for a computer of that caliber is pretty good if that's total system power. The APU's aren't Atoms/Celerons.

[andreano]

so called "Linux performance marginality" - Was fixed in Ryzen's produced after week 25 2017.

Isn't that unofficial info? I'm still curious to see if it's fixed in this next iteration.

spectre - Software fixes are being rolled out as we speak.

If I got this one right, you can never completely fix spectre in software, as you would have to patch all the software in the world. All cloud computing has to migrate to ARM A53. Correct me if I'm wrong.

[rene]

All I care about is bugs. I'll buy when all the problems

* spectre
* meltdown
* so called "Linux performance marginality"

are solved. Sadly, I have no real reason to upgrade my AMD Llano from 2012 :-(



Lycky you. My last Intel processor (Core 2 Duo) had this funny bug, that with all modern tickless kernels, it would hang without constant user input. I stayed away from Intel ever since.

I have something similar with my Transmeta Crusoe Oqo01+ :-/ still need to bisect where this regression was introduced: http://t2sde.org/hardware/portable/OQO/01+/

[Pentarctagon]

Everybody gets unlucky at times with hardware guys, making buying decisions based on past experiences probably isnt sound in the world of electronics.

On the other hand though, if I keep having issues related to hardware from company X, then it also doesn't make sense to keep buying hardware from that company, regardless of whether the fault is directly X's fault or the fault of some other manufacturer in the middle.

[Mercyful Fate]

Michael said: "But with AMD sending out the CPUs this time around for Linux testing, you can probably assume the Linux support is in good shape and more on that next week."

Everybody gets unlucky at times with hardware guys, making buying decisions based on past experiences probably isnt sound in the world of electronics.

That's dumb. So, by that same logic, you'd have Theranos perform your medical tests, right?

After all the reported issues with Ryzen/Raven Ridge thus far let me say this ahead of time: You guys can be the beta-testing guinea pigs whilst I sit back and wait for the non-beta versions. :-P

Before you get your undies in a bundle, that statement does not imply I hate AMD.
Quite the contrary, I mostly buy AMD products. I still have a Phenom II 965BE in operation for crying out loud.
But personally I will no longer be the first in line to purchase a newly released product from ANY company.
In my younger days I lived on the bleeding edge of electronics, I've earned my "cuts", but now I'm now long past the point of beta-testing products.

[Adarion]

* spectre
* meltdown
* so called "Linux performance marginality"

As was already written, spectre affects all and everyone and everything that is not ancient / in-order. 99% of CPU designs today are out-of-order and thus are more or less susceptible for Spectre v1/v2.
AMD has a very limited vulnerability to v2, and the normal, universal one, to v1. They worked with the devs and fixed things via SW side, because you can't fix it in HW.
Afair. hardware side fixes were announced to come, but probably later.
For now use retpolines.

Meltdown is intel only (on the x86 side), the "marginality" was fixed after week 15 or 25 iirc. So every Ryzen after that date does not have that problem anymore. Iirc. Epyc/TR were not affected at all. So unless you sample one of the early Ryzen builds off ebay you won't have that issue.




More on topic: They have a Ryzen 7 2700 variant (8 x ~3.2 GHz base + threading, something like 4.1 GHz turbo) with 65 W TDP again. For roughly 290 Euros. That's one tempting offer.

PS: Due to a lack of money I'll be waiting also, but I had yet no real problems with any AMD/ATI product so far, though little bugs in chipsets. I also had a few nvidias in the past (was mostly okay) and in the days of old also some intel CPUs. I had HDDs of most manufacturers that survived past 386, and you can hear different stories about every single one of them. I had no issues with Seagate so far (esp. fond of their enterprise material), had my personal horror with WD, was okay with Samsung, meh with Maxtor and IBM (Death... Desk Star successor...); but other people will scream about Seagate.
And I could tell tales from the great war about floppies/diskettes or more modern ones about good and bad flash media experiences.
I guess it always depends and different people make different experiences.

[numacross]

If I got this one right, you can never completely fix spectre in software, as you would have to patch all the software in the world. All cloud computing has to migrate to ARM A53. Correct me if I'm wrong.

I'm pretty sure it's either recompile software or use an updated microcode on Zen, which AMD recently provided. Also recompling the kernel with retpolines seems to be required.

From RedHat's guidance (https://access.redhat.com/articles/3311301):

AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.

• pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode update is applied
• pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates