• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

AMD Ryzen Machine Crashes to a Sequence of FMA3 Instructions

What's your point? What are you trying to say? TPU is simply reporting the news. Is this serious if left unfixed? Yes. Should TPU just stop reporting stuffs? No.

I guess if news is synonymous with tabloid material, b/c that's how these posts appear. While the story is real, it's like CNN's breaking news, "Trump didn't tell press he went to dinner!"
 
So prime, realbench for days, and then games all that use SMT didn't crash once. This program crashed that they admit does not currently support Zen. So what is so deeeeeply wrong with zen? Sound like you are more interested in exaggerating the problem. Your comment was fine until the last sentence where you made it a major flaw. This will likely be fixed with micro code update if anything.

As I've said: it seems people don't understand the issue.

It's not about compatibility or how rare the problematic instruction is used in software.
It's about the fact that this architecture can be crashed with a single line of code, which should not happen, ever. If a CPU can't execute some code, it should handle this exception in a safe way. Ryzen simply dies.
This is a big stability risk and - as far as enterprise segment - a threat that would make Ryzen unacceptable in commercial applications.

Moreover, while it is rumored that AMD knows how to fix this and the microcode update is being developed, AMD gave no official statement nor deadline. It's already been few days since the issue was revealed..
 
As I've said: it seems people don't understand the issue.

It's not about compatibility or how rare the problematic instruction is used in software.
It's about the fact that this architecture can be crashed with a single line of code, which should not happen, ever. If a CPU can't execute some code, it should handle this exception in a safe way. Ryzen simply dies.
This is a big stability risk and - as far as enterprise segment - a threat that would make Ryzen unacceptable in commercial applications.

Moreover, while it is rumored that AMD knows how to fix this and the microcode update is being developed, AMD gave no official statement nor deadline. It's already been few days since the issue was revealed..

This isn't the first CPU to exhibit this sort of behavior. As mentioned: flawed humans, with flawed understanding, making flawed products, in their flawed universe.

I do understand why it is news and I do understand why it is important. But, 3 pages later, it is getting stretched pretty thin.

Future you says: Oh, I guess they fixed it. It wasn't such a big deal after all. Time to move on.
 
This isn't the first CPU to exhibit this sort of behavior.

But this is a first CPU to do this in a very long time.
Sorry, but an argument that something happened years ago (Coppermine in 2001?) is by no means helping AMD.
Seriously, we became so spoiled by CPUs that just work - having close to none compatibility conflicts, setting themselves up, overclocking automatically etc.
AMD gave us a CPU which once makes you spend weeks on reading about issues, finding a rare RAM that works etc. We're once again waiting for some patches to fix crucial issues...

I totally understand they were committed to maximize performance and this CPU is really squeezed to the limits, but haven't they gone too far?
Quite a few people have reported that this FMA3 issue can be fixed (or greatly limited) by upping voltage. Oh come on... do we deserve being treated like that? :/

Future you says: Oh, I guess they fixed it. It wasn't such a big deal after all. Time to move on.

It's a huge deal and will not be forgotten by reviewers and enthusiasts. I would compare it to the latest Samsung's battery fail. What saves AMD is that - apart from some gamers and geeks, no one really cares (generally speaking not that many know what AMD is).
 
It's about the fact that this architecture can be crashed with a single line of code

Please post the line of code. You don't really have any clue what you are babbling about. So why are you interesting in making a big stink (this isn't your first rodeo either, we all know that). One would assume enterprise chips will fix whatever was found on the first round of PC parts.
 
Last edited:
Please post the line of code. You don't really have any clue what you are babbling about.

Said "line of code" would compile differently depending on your choice of compiler and it's settings. BTW how the hell are people NOT GETTING THIS? The problem (now fixed as expected) was that a certain instruction or stream of instructions could hang the CPU. The program that did this, obscure or not, didn't matter. Even if Ryzen didn't know how to process the FMA3 instructions it should have just issued an exception and the OS would have handled it (haha no pun intended!).

This problem wasn't like a game crashing to the desktop, it wasn't even like a BSOD and you had to reboot. Depending on your system, you may or may not have even been able to turn off your computer by holding the on/off button! This happened to me once, guess how.

As I said earlier, this is similar to the Cyrix coma bug or the Pentium F00F bug.
 
Last edited:
Please post the line of code. You don't really have any clue what you are babbling about. So why are you interesting in making a big stink (this isn't your first rodeo either, we all know that). One would assume enterprise chips will fix whatever was found on the first round of PC parts.

Honestly, I'm not sure, but I guess it would look something like this:
VFMADD132PDx %a, %b, %c

The great thing is that the benchmark used to reveal this bug is open source. Everyone willing to hang their (or - for that matter - someone else's) Ryzen can check how the code forces FMA3 usage. :) Basically, you can force that while compiling (even when coding in a high-level language).
 
Honestly, I'm not sure, but I guess it would look something like this:
VFMADD132PDx %a, %b, %c

You're missing the point that you think it's a single line of code.
  • Resolved a condition where an unusual FMA3 code sequence could cause a system hang.
 
You're missing the point that you think it's a single line of code.

Umm, you do know how a compiler works, right?

And so what if it takes more than one line of code in your language of choice? Sorry but your being rather pedantic about this.
 
Sorry but your being rather pedantic about this.

Sure, to counter some grand sweeping mud being thrown at the wall. Get it right if you're gonna do that.
 
I'm pretty sure you can crash ANY system by feeding it with instructions that are not meant for it.

Actually, it's not really that simple at all. You aren't supposed to be able to crash a complete system. A process, sure. A system? No. That's bad.
 
I'm pretty sure you can crash ANY system by feeding it with instructions that are not meant for it. And we know how "standards" work with instructions. If they really were 100% standard, then they'd exhibit IDENTICAL performance gains on ALL CPU's. Which we know for a fact it's not true...
CPUs have a register that stores flags for representing when something goes wrong and have their own form of exception handling, such as division by zero, overflow, etc. The problem is that if the machine is unstable handling exceptions, how do you recover from recovering from exception processessing? It's not like there is an "Exception, Exception" flag. Since it sounds like this isn't an issue when overclocking, it's possible that bumping the voltage is making the CPU stable enough to not cause a problem, indicating that as far as FMA3 is concerned, the CPU might be running a little lean with respect to voltage to keep it stable.
 
Back
Top