Continuing To Stress Ryzen

[RyzenNewbie]

Theory: So in the end it could be an Intel bug that has been circumvented in every compiler and most software out there, because it was build and tested on Intel and if the Ryzen CPU does it "right" and suddenly every compiler out there "fails" because it is implemented with the "wrong" method - we would still blame Ryzen?

(I'm not saying I bet on this - I just want to have people take a step back and try to be objective here)

interesting theory - but let me ask you this: if that software builds successfully on a Phenom - which, obviously, is not made by Intel - and suddenly does not successfully build anymore on a Ryzen; why should AMD have removed that wrong method? And especially, why not have told anyone about that change?

[V10lator]

performance-wise, correct. Architectural-wise, wrong. If I calculate "1+1=2" on CPU A, then I expect that CPU B calculates "1+1=2", too; everytime. Given that CPU B claims having architectural compatibility with CPU A. And no, CPU A is not an Intel CPU.

Exactly. To explain that to sdack: There are amd64 instructions. They where defined by AMD itself and every amd64 CPU (yes, even Intel ones) should be able to handle them. If the CPU can't speak amd64 or missbehaves while interpreting it that's a bug. Then there are extension to that (SSE, MMX and so on) but your code won't hit them as you don't know them. So FreeBSD only using amd64 + documented extensions and still having this issue must be a hardware bug.

//EDIT And btw: The failing amd64 instruction is documented, see page 290 at https://support.amd.com/TechDocs/24594.pdf - I fail to read "The CPU should corrupt the programs code while an interrupt arrives at the same core + the programs code is in the upper user memory area". So do you still think it's software related?

[timofonic]

grep CONFIG_RCU_NOCB_CPU= /boot/config-4.11.12-vanilla
CONFIG_RCU_NOCB_CPU=y

grep CONFIG_RCU_NOCB_CPU_ALL= /boot/config-4.11.12-vanilla
CONFIG_RCU_NOCB_CPU_ALL=y

This options in kernel + disable core C6 can help when you have idle freezes.
Never see idle freezes since I added this options in my custom kernel.

Excuse me, but what's "core C6"? And what that kernel config does? Uhm...

[slotdime]

Does anyone has run into these problems on RED HAT ENTERPRISE LINUX 7.3, SUSE LINUX ENTERPRISE SERVER 12.2 or UBUNTU LINUX 17.04 ?
I can't help thinking that "naples" linux support "officialy" should come with those Oses. As I understand, Ryzen is a "subset" of Epyc .
Those are the distros mentioned in the SOLUTION BRIEF June 2016 about EPYC pdf on http://www.amd.com/en/products/epyc-7000-series .

[sdack]

If I calculate "1+1=2" on CPU A, then I expect that CPU B calculates "1+1=2", too.

That's the problem with you. You think everything inside a CPU is as simple as 1+1. It isn't. You're really awful, you know?

[RyzenNewbie]

You think everything inside a CPU is as simple as 1+1. It isn't.

it is not?

https://en.wikipedia.org/wiki/X86_instruction_listings

CTRL + F and then entering "unpredicted" or "arbitrary" gives me only a red search mask in Firefox, unfortunately.

You're really awful, you know?

more, more. Give me more personal descriptions. I'm going to start a new RPG, and I'm out of ideas how to define my character there...

[Shevchen]

interesting theory - but let me ask you this: if that software builds successfully on a Phenom - which, obviously, is not made by Intel - and suddenly does not successfully build anymore on a Ryzen; why should AMD have removed that wrong method? And especially, why not have told anyone about that change?

Technology advances (like the Hyper Threading efficiency) and thus new techs are introduced or old ones altered/updated. (Yes, you can make mistakes doing that, but my example is a mind game anyway)

As of such, AMD might have gone from "old faulty tech copied from Intel" (due to compatibility concerns) to "we make it this way now".

Anyhow, we should try to watch how this develops.

[RyzenNewbie]

As of such, AMD might have gone from "old faulty tech copied from Intel" (due to compatibility concerns) to "we make it this way now".

and you know what? I am completely fine with that - to ditch "old faulty tech". But, a manufacturer has to communicate that then, either by provding an official statement or by packaging a little note on the package: "carefully, this CPU handles things differently than before".

That leads to a possible hidden workaround in Windows - that neither has been approved nor declined by anybody, yet.

Anyhow, we should try to watch how this develops.

Well, "AGESA 1.0.0.7" perhaps?

[sdack]

it is not?

No. Well, at least you know what equals 1 + 1. Leave it at that and don't break your head over it. Tomorrow at school will you learn what equals 1 + 2, if you don't choke on your cereals and die before school.

[RyzenNewbie]

But, a manufacturer has to communicate that then, either by provding an official statement or by packaging a little note on the package: "carefully, this CPU handles things differently than before".

and because they (AMD) haven't - and if they will do, they should have done that since day zero - I assume that this new CPU is acting like the CPUs before. And because it doesn't, I'm "bitching" (to quote my buddy) around. It bugs me immensly when an 8 hour-"libreoffice" compilation fails in the last steps because there is a "bus error" of some kind and in the next run it builds without hiccups...