AMD Zen: A properly functioning microarchitecture?

[CluelessOne]

OP, I am going to give you a layman answer since I am not in this industry.
1. A sufficiently complex hardware is going to have bugs in implementation. AMD Ryzen is not immune.
2. Most of the problems are caused by assumptions and lack of foresight from the software developer. Those can range such as these below and more.
a. x86 CPUs are made by a very few companies. Due to the huge disparity of market share between Intel and the others, some assume that Intel's implementation of x86 instructions is the one correct way. Which may not be true.
b. In a real time systems, has the proper timing abstractions been implemented so softwares running on a fast 5 GHz CPU gave the same slow response time as when it is running on a CPU running on a 4 MHz clock down to the nanoseconds?
c. Software developer continue to use deprecated hardware instructions or OS API. Granted when the company or developer has died you are in a big trouble, but choose your software wisely. When the developer doesn't want to update their products in line with the current API or instructions perhaps it might be time to look elsewhere.

 

[Abwx]

Their 2200G / 2400G won't even BOOT Windows 7. How the heck does that happen, for a CPU claiming x86 / x64 compatibility? Isn't Windows 7 64-bit the "Gold Standard" for "Legacy OSes"?

.

If you have noticed latest Intel CPUs dont support W7, a fix is currently released but without GPU driver, so you ll have to rely on a dGPU, at some point both brands stated that there wont be any W7 support starting with KBL/SKL at Intel and Bristol Ridge at AMD, it can work with some hacks but it s not guaranted.

 

[VirtualLarry]

If you have noticed latest Intel CPUs dont support W7, a fix is currently released but without GPU driver, so you ll have to rely on a dGPU, at some point both brands stated that there wont be any W7 support starting with KBL/SKL at Intel and Bristol Ridge at AMD, it can work with some hacks but it s not guaranted.

But... that was MS arbitrarily drawing a line at which hardware level they would continue to support Windows 7. The only downside is, no official drivers for that OS for those newer platforms, and no Windows Update, because it's nominally blocked.

The issue with Windows 7 64-bit and Ryzen Raven Ridge APUs is different, they literally won't even boot the OS. BSODs. Something is very incompatible. Not because software chose to make it incompatible, but really something lower-level.

I guess, what I mean is, with Kaby Lake and Coffee Lake and Ryzen CPUs, Windows 7 64-bit is "unsupported", but with Raven Ridge APUs, it's actually "incompatible".

 

[Abwx]

I guess, what I mean is, with Kaby Lake and Coffee Lake and Ryzen CPUs, Windows 7 64-bit is "unsupported", but with Raven Ridge APUs, it's actually "incompatible".

Dunno what happen, i would guess that Ryzen being a server CPU it is supported by Windows Server 2012 wich is close to W7, but nothing of the sort for RR wich is not supposed to use "ancient" and legacy OSs wich are still used in the server space.

 

[William Gaatjes]

With respect to VME and the INT instruction, it is a hoax anyway. Just try to find drivers for old (no longer supported unless payed for) windows like xp or NT for modern hardware and try to run new hardware on such old os. Let a properly written virtual machine that uses hardware virtualization techniques manage it and there is no issue at all. Who wants to run 16 bit x86 code natively anyway ?
Some outliner that gets a boner, the kind of person that persist that 16 bit code runs faster than 64 bit code...

And windows 10 does an amazing job to run almost everything. Although some software is just written that bad...

 

[Markfw]

With respect to VME and the INT instruction, it is a hoax anyway. Just try to find drivers for old (no longer supported unless payed for) windows like xp or NT for modern hardware and try to run new hardware on such old os. Let a properly written virtual machine that uses hardware virtualization techniques manage it and there is no issue at all. Who wants to run 16 bit x86 code natively anyway ?
Some outliner that gets a boner, the kind of person that persist that 16 bit code runs faster than 64 bit code...

And windows 10 does an amazing job to run almost everything. Although some software is just written that bad...

And you have to give linux credit. All my Ryzen/TR boxes are dual boot, but run linux most of the time with no trouble. A couple are on win 10. Both are just fine. This is just a troll thread, and everyone but the OP has said so.

 

[William Gaatjes]

And you have to give linux credit. All my Ryzen/TR boxes are dual boot, but run linux most of the time with no trouble. A couple are on win 10. Both are just fine. This is just a troll thread, and everyone but the OP has said so.

I agree.
Everything the OP talked about seemed solved and patched by microcode updates and software updates a year ago.

 

[darkswordsman17]

I was checking the 2700/X on Newegg and noticed a negative review posted on Oct 1st was the highest rated. It claimed a micro-code patch on the 2700X caused multi-threaded performance to drop 15%. Which, its possible, and its possible it was an error (there was a big Windows patch that came out and then got pulled because of some error, and I seem to recall there having been one of the spectre/meltdown patches that was only for Intel but was like it defaulted to being on for everyone so AMD users saw a hit until a later update or something). I googled it, and found the person had made a thread on Tom's Hardware with the same info. The interesting thing is that in that thread the person recommended people start shorting AMD stock.

Found the thread: http://www.tomshardware.com/answers/id-3795146/amd-ryzen-2700x-verified-performance-decrease.html

That coupled with this, and then the antics pulled earlier this year makes me wonder. I have a friend that bought AMD stock and on the 2nd or 3rd he said he had been up 20%, but it was down to just 2% recently. I don't own stock in them or pay attention to their stock, so no idea if there was some reason that made sense for the drop. But it makes for some interesting coincidences.

Which, I'd guess if people are trying to hurt the stock now, they're probably people that want to buy it cheap in anticipation of next year. So get it cheap and buy more shares then reap the benefits. But who knows.

 

[DaveSimmons]

AMD stock manipulation has already happened this year, with that "security company" that was a sockpuppet for short sellers, that discovered and promoted (not really) "serious security threats" that turned out to be much less than serious. They even had fancy names and branding for the (not really) "dangerous exploits."

Perhaps we're seeing round two using viral rumor-mongering. OP might be an innocent dupe passing along the FUD from unreliable forum posts or youtube videos.

 

[Rancor]

I currently roll AMD and am fascinated by this topic. Please don't let fanboyism shut down an interesting thread. I had allot of heartache over the following Ryzen kernel bug. I personally think its has more to do with power management on the CPU, than the Linux kernel. In this case AMD released a BIOS update to address power supply idle control.

Of course all CPUs have errata, here is an interesting page listing some CPU bugs

 

[Insert_Nickname]

Who wants to run 16 bit x86 code natively anyway ?

Trust me. They're out there.

Some haven't even heard of this whole "virtualisation thingy"...

 

[os2wiz]

I find this article or whatever you want to call it rather pathetic. Could some in bound money from Intel triggered it??? The segfault errors he mentioned were limited to original Ryzen cous manufactured before 9/01/2017. The Ryzen 2000 series chips have not reported this issue at all. I have a Ryzen 2700X, I had a Ryzen 1800X that had been replaced in August , 2017 because of related issues. It sounds like a rather pathetic smear attack even though the author is clever enough to cover his butt by saying it has happened to Intel in the distant past. Does he not know of the recent security errata issues with Intel chips that are affecting hundreds of millions users and whose "solution" had adverse performance impacts on many systems? I guess I am living on a different planet. Intel is in trouble their monopolistic dominance in the retail market is starting to crack and the same is coming true in the corporate server farm market. Their inability to introduce 10nm nearly 2 years ago has hurt them badly with product introductions that are neither exciting or cost efficient. AMD has stolen the initiative from Intel and all they have to fall back on are those duplicitous souls in the tech media whose ability to spin is for rent. I will gladly apologize if I am wrong on this issue, but that is my suspicion.

I'm sure many of us here have vague memories of chips that had real-world, unfixable bugs and problems. Problems that would not go away with a better motherboard, BIOS updates, OS reinstalls - without rewritten software. Problems that others might even blame on a bad overclock until the OP reverted to stock settings and would persist.

Pentiums with incorrect FDIV lookup tables and buslocks from F00F... opcodes, Cyrixes that had weird issues with anything assuming Pentum-level instructions, K6s that had stability issues with too much RAM, Athlons that would go up in smoke for lack of a heatspreader or a fast thermal diode.

But most of those examples are in the distant past, likely buried in landfill. PCs, their components and their marketing have changed over the years - expansion slot, form factor and firmware standards have changed over the years to be easier to work with and harder to mess up. You can't just plug in the motherboard power backwards and see it go up in smoke anymore unless you're pushing down with the force of a steamroller. Can't insert your CPU backwards and fry it these days like you could your Socket 3 486!

Mid-end motherboards today come in glossy, made-to-fit boxes, have sleek plastic shrouds, a jet-black silkscreen and fancy lettering; they are often fashionable, 'refined' products, are they not, far cries from the crude green and brown boards of the 80s and 90s or the more fisher-price boards around the new millennium (even modern ones sans UEFI, IMO). Surely the janky past of glitchiness is behind us, with our modern equipment offering a smooth, trouble-free computing experience?

Now (well, really around a year ago), I hear that a large amount of early Ryzens have a manufacturing defect - ringing, out-of-spec inductance somewhere, grounding issue, insufficient capacitance in power layers/ripple smoothing, design features being packed too close, mask defect blowing open part of a line? - that causes segfaults compiling GCC, and not every time either. Even after microcode and UEFI updates. RMA required. Huge numbers of chips affected. Virtual 8086 mode semi-broken (apparently fixed with AGESA 1006?), causing issues with some VMs or running 16-bit software on 32-bit Windows. Reports of unusual crashes in Maya? Handbrake? Broken C6 sleep mode causing lockups when idle in Linux and BSD?

And if these obvious symptoms are cropping up, how many silent issues might be occurring in the background that don't trigger a full-blown segfault on Ryzen? (Not to say that errata on Intel are never an issue)

To me, this feels a bit (a bit) like the ominous days of Super Socket 7 and its standard melange. What kinds of little issues could come up at the worst time to bite you in the back? As if termites infested some of the towers and towers of software written for PCs, but you don't know exactly which ones until you walk in and try to run them. Like a piece of the digital landscape has broken off, but you're blind and can only hope you don't fall down the hole it created.

(The things that really come to mind on the recent Intel side are issues with atomicity on Skylake HT (test program was tight assembly loops?), Meltdown/Spectre of course and x87 having questionable precision? Also curious about chipset/USB stability on the last 10 years worth of the AMD lines? Have heard of some issues regarding USB latency with SB7/9xx on the AMD side... Serato appears to be an example of software affected.)

Perhaps it's just paranoia on my part, but I think I make somewhat of a point that these issues should have been ironed out. These are not all just hypothetical issues listed on a datasheet. Sometimes I wonder if deterministic faults on 2 different PCs with similar architecture could cause real issues for DC projects like BOINC that depend on cross-system validation? Computers that don't compute the way we expect them to...

Zen uarch family erratum sheet

Anecdotes from people here with Ryzen systems would be interesting to hear.

I'm sure many of us here have vague memories of chips that had real-world, unfixable bugs and problems. Problems that would not go away with a better motherboard, BIOS updates, OS reinstalls - without rewritten software. Problems that others might even blame on a bad overclock until the OP reverted to stock settings and would persist.

Pentiums with incorrect FDIV lookup tables and buslocks from F00F... opcodes, Cyrixes that had weird issues with anything assuming Pentum-level instructions, K6s that had stability issues with too much RAM, Athlons that would go up in smoke for lack of a heatspreader or a fast thermal diode.

But most of those examples are in the distant past, likely buried in landfill. PCs, their components and their marketing have changed over the years - expansion slot, form factor and firmware standards have changed over the years to be easier to work with and harder to mess up. You can't just plug in the motherboard power backwards and see it go up in smoke anymore unless you're pushing down with the force of a steamroller. Can't insert your CPU backwards and fry it these days like you could your Socket 3 486!

Mid-end motherboards today come in glossy, made-to-fit boxes, have sleek plastic shrouds, a jet-black silkscreen and fancy lettering; they are often fashionable, 'refined' products, are they not, far cries from the crude green and brown boards of the 80s and 90s or the more fisher-price boards around the new millennium (even modern ones sans UEFI, IMO). Surely the janky past of glitchiness is behind us, with our modern equipment offering a smooth, trouble-free computing experience?

Now (well, really around a year ago), I hear that a large amount of early Ryzens have a manufacturing defect - ringing, out-of-spec inductance somewhere, grounding issue, insufficient capacitance in power layers/ripple smoothing, design features being packed too close, mask defect blowing open part of a line? - that causes segfaults compiling GCC, and not every time either. Even after microcode and UEFI updates. RMA required. Huge numbers of chips affected. Virtual 8086 mode semi-broken (apparently fixed with AGESA 1006?), causing issues with some VMs or running 16-bit software on 32-bit Windows. Reports of unusual crashes in Maya? Handbrake? Broken C6 sleep mode causing lockups when idle in Linux and BSD?

And if these obvious symptoms are cropping up, how many silent issues might be occurring in the background that don't trigger a full-blown segfault on Ryzen? (Not to say that errata on Intel are never an issue)

To me, this feels a bit (a bit) like the ominous days of Super Socket 7 and its standard melange. What kinds of little issues could come up at the worst time to bite you in the back? As if termites infested some of the towers and towers of software written for PCs, but you don't know exactly which ones until you walk in and try to run them. Like a piece of the digital landscape has broken off, but you're blind and can only hope you don't fall down the hole it created.

(The things that really come to mind on the recent Intel side are issues with atomicity on Skylake HT (test program was tight assembly loops?), Meltdown/Spectre of course and x87 having questionable precision? Also curious about chipset/USB stability on the last 10 years worth of the AMD lines? Have heard of some issues regarding USB latency with SB7/9xx on the AMD side... Serato appears to be an example of software affected.)

Perhaps it's just paranoia on my part, but I think I make somewhat of a point that these issues should have been ironed out. These are not all just hypothetical issues listed on a datasheet. Sometimes I wonder if deterministic faults on 2 different PCs with similar architecture could cause real issues for DC projects like BOINC that depend on cross-system validation? Computers that don't compute the way we expect them to...

Zen uarch family erratum sheet

Anecdotes from people here with Ryzen systems would be interesting to hear.

 

[Ottonomous]

Remarkable OP managed to identify multiple catastrophic problems within Zen, days before the 9700/9900K launch, god must smile upon intel

 

[Ottonomous]

I'm sure many of us here have vague memories of chips that had real-world, unfixable bugs and problems. Problems that would not go away with a better motherboard, BIOS updates, OS reinstalls - without rewritten software. Problems that others might even blame on a bad overclock until the OP reverted to stock settings and would persist.

Pentiums with incorrect FDIV lookup tables and buslocks from F00F... opcodes, Cyrixes that had weird issues with anything assuming Pentum-level instructions, K6s that had stability issues with too much RAM, Athlons that would go up in smoke for lack of a heatspreader or a fast thermal diode.

But most of those examples are in the distant past, likely buried in landfill. PCs, their components and their marketing have changed over the years - expansion slot, form factor and firmware standards have changed over the years to be easier to work with and harder to mess up. You can't just plug in the motherboard power backwards and see it go up in smoke anymore unless you're pushing down with the force of a steamroller. Can't insert your CPU backwards and fry it these days like you could your Socket 3 486!

Mid-end motherboards today come in glossy, made-to-fit boxes, have sleek plastic shrouds, a jet-black silkscreen and fancy lettering; they are often fashionable, 'refined' products, are they not, far cries from the crude green and brown boards of the 80s and 90s or the more fisher-price boards around the new millennium (even modern ones sans UEFI, IMO). Surely the janky past of glitchiness is behind us, with our modern equipment offering a smooth, trouble-free computing experience?

Now (well, really around a year ago), I hear that a large amount of early Ryzens have a manufacturing defect - ringing, out-of-spec inductance somewhere, grounding issue, insufficient capacitance in power layers/ripple smoothing, design features being packed too close, mask defect blowing open part of a line? - that causes segfaults compiling GCC, and not every time either. Even after microcode and UEFI updates. RMA required. Huge numbers of chips affected. Virtual 8086 mode semi-broken (apparently fixed with AGESA 1006?), causing issues with some VMs or running 16-bit software on 32-bit Windows. Reports of unusual crashes in Maya? Handbrake? Broken C6 sleep mode causing lockups when idle in Linux and BSD?

And if these obvious symptoms are cropping up, how many silent issues might be occurring in the background that don't trigger a full-blown segfault on Ryzen? (Not to say that errata on Intel are never an issue)

To me, this feels a bit (a bit) like the ominous days of Super Socket 7 and its standard melange. What kinds of little issues could come up at the worst time to bite you in the back? As if termites infested some of the towers and towers of software written for PCs, but you don't know exactly which ones until you walk in and try to run them. Like a piece of the digital landscape has broken off, but you're blind and can only hope you don't fall down the hole it created.

(The things that really come to mind on the recent Intel side are issues with atomicity on Skylake HT (test program was tight assembly loops?), Meltdown/Spectre of course and x87 having questionable precision? Also curious about chipset/USB stability on the last 10 years worth of the AMD lines? Have heard of some issues regarding USB latency with SB7/9xx on the AMD side... Serato appears to be an example of software affected.)

Perhaps it's just paranoia on my part, but I think I make somewhat of a point that these issues should have been ironed out. These are not all just hypothetical issues listed on a datasheet. Sometimes I wonder if deterministic faults on 2 different PCs with similar architecture could cause real issues for DC projects like BOINC that depend on cross-system validation? Computers that don't compute the way we expect them to...

Zen uarch family erratum sheet

Anecdotes from people here with Ryzen systems would be interesting to hear.

Very suspicious choice of language, no hard inferences but one piece of damaging speculation after another

Here's a solution to your conundrum OP. post evidence of the systematic prevalence of these issues, burden of proof upon the claimant and all that

 

[prtskg]

All completely new architectures have some problems. Zen 1st gen was no exception. I've not heard of any problems with the 2nd gen of Ryzen though.

 

[whm1974]

Very suspicious choice of language, no hard inferences but one piece of damaging speculation after another

Here's a solution to your conundrum OP. post evidence of the systematic prevalence of these issues, burden of proof upon the claimant and all that

I have been watching Ryzen since AMD first released it especially with Linux running on the CPUs. My conclusion is that Ryzen is quite suitable for Linux and I 'm looking at AMD for my next build. And I agree with the rest of posters here that the OP is trolling or misinformed.

 

[chrisjames61]

Just the title alone points to it being FUD and a troll rolled into one.

 

[Thunder 57]

OP has no problem spreading FUD about Intel as well. He's working on a next gen x86 CPU after all

http://www.portvapes.co.uk/?id=Latest-exam-1Z0-876-Dumps&exid=threads/optical-cordic-and-vliw-for-next-gen-x86.2535623/#post-39352875

 

[Rancor]

I concur, the Ryzen 2000 series and the latest BIOS updates are now quite stable on Linux. It is interesting a lesser known operating system DragonflyBSD also turned up a Ryzen related bug.

I for one am excited about Ryzen and cant understand the hostility in this thread. I think it is healthy to discuss user experiences and catalog any bumps along the way. Especially as the platform continues to mature.

 

[Hitman928]

I concur, the Ryzen 2000 series and the latest BIOS updates are now quite stable on Linux. It is interesting a lesser known operating system DragonflyBSD also turned up a Ryzen related bug.

I for one am excited about Ryzen and cant understand the hostility in this thread. I think it is healthy to discuss user experiences and catalog any bumps along the way. Especially as the platform continues to mature.

There's a huge difference between discussing hardware bugs (errata) that pop up and essentially declaring under guise of inquisition that the microarchitecture itself is broken.

 

[catonkatonk]

I believe FreeBSD still has stability issues on Zen.
From the OP's perspective, it might be a reasonable question to ask, given how long Ryzen has been on the market.
On the other hand, last I checked there was a patch to be merged that would fix the issues, so maybe FreeBSD's developers were just late in implementing errata workarounds.

 

[chrisjames61]

I think it is healthy to discuss user experiences and catalog any bumps along the way. Especially as the platform continues to mature.

Except he isn't stating that he has experienced any of this first hand.

 

[chrisjames61]

And I can't seem to keep my 2200G stable on Linux Mint 19 64-bit for more than a few days, even updating to the 4.19-RC4 kernel.

Edit: Not trying to FUD here in my post, just that it's well-known that the Ryzen CPUs will work with Windows 7, but the APUs will not, and my personal experiences trying to get Linux Mint 19 to work with my 2200G, on I think an Asus B350M-E Prime mobo.

Sometimes those beta Kernels are unstable imho. My R5 2400G and X370 Gaming Titanium has no issues with Mint 19 with kernel 4.15.0-33-generic.

 

[DrMrLordX]

I don't know about Ryzen CPUs, other than the earliest batch, which I probably have, having erratas that are user-visible, but what is going on with their APUs?

Their 2200G / 2400G won't even BOOT Windows 7. How the heck does that happen, for a CPU claiming x86 / x64 compatibility? Isn't Windows 7 64-bit the "Gold Standard" for "Legacy OSes"?

And I can't seem to keep my 2200G stable on Linux Mint 19 64-bit for more than a few days, even updating to the 4.19-RC4 kernel.

Edit: Not trying to FUD here in my post, just that it's well-known that the Ryzen CPUs will work with Windows 7, but the APUs will not, and my personal experiences trying to get Linux Mint 19 to work with my 2200G, on I think an Asus B350M-E Prime mobo.

Weird, and a bit surprising on the Linux angle. Have your tried using a mainline Debian distro instead of a repack like Mint?

I'm not all that surprised that Win7 is unworkable, even though the boot failure is a bit odd. Regardless, do not expect MS to do anything to fix the problem except for paying corporate clients. And they probably aren't using Raven Ridge anyway.

It is interesting a lesser known operating system DragonflyBSD also turned up a Ryzen related bug.

I believe FreeBSD still has stability issues on Zen.

*BSD has and will have problems with new hardware. The more radical the design changes, the more likely it is that you won't get the results you want. Honestly, if I wanted to use anything BSD, I do not think I would use anything newer than 2015-2016, and that might be optimistic. I would also generally assume that (for now) *BSD distros will work better on Intel hardware.