Slashdot Mirror
AMD Confirms Linux 'Performance Marginality Problem' On Ryzen (phoronix.com)
An anonymous reader writes: Ryzen customers experiencing segmentation faults under Linux when firing off many compilation processes have now had their problem officially acknowledged by AMD. The company describes it as a "performance marginality problem" affecting some Ryzen customers and only on Linux. AMD confirmed Threadripper and Epyc processors are unaffected; they will be dealing with the issue on a customer-by-customer basis, and their future consumer products will see better Linux testing/validation. Ryzen customers believed to be affected by the problem can contact AMD Customer Care. Michael Larabel writes via Phoronix: "With the Ryzen segmentation faults on Linux they are found to occur with many, parallel compilation workloads in particular -- certainly not the workloads most Linux users will be firing off on a frequent basis unless intentionally running scripts like ryzen-test/kill-ryzen. As I've previously written, my Ryzen Linux boxes have been working out great except in cases of intentional torture testing with these heavy parallel compilation tasks. [AMD's] analysis has also found that these Ryzen segmentation faults aren't isolated to a particular motherboard vendor or the like, contrary to rumors/noise online due to the complexity of the problem."
Will only affect a few people, so we aren't replacing any CPUs. Way to hand Intel the business, AMD!
certainly not the workloads most Linux users will be firing off on a frequent basis
I run Gentoo you insensitive clod!
Multi-threaded performance was the main advantage that Ryzen had over Intel. Single threaded is still Intel's game and now you are telling that I can't run a make -j all my cores?
I do not envy the crew assigned to tracking that bug down.
It is not like the CPU is testing for that particular combination of conditions alone and conditionally segfaulting. Really, there is a flaw in the CPU design which so far has only been demonstrated to exhibit itself under those conditions. That is much more worrying than the summary leads us to believe.
I like AMD and Ryzen is a good bargain compared to Intel. It will be my next CPU purchase, though I am holding out until they fix the bug. But I don't like the way they are minimizing the impact.
Ceci n'est pas une signature.
We have tons of cores so you can do many things at once. Just don't use them all at once!
..the faults only happen for people with massive parallel loads.
You know... the main reason people buy the CPUs.
This seems a bit concerning for their plans to take on xeons in the server market which would pretty much all run linux with high parallel loads
never mind my load type today, what about 2 years from now? why would I spend money on something that *might* segfault and for which the vendor isn't going to provide a solution to *everyone*. case by case basis my ass, that's the sign of a tech hardware vendor which should be shunned.
And could still wind up being a Linux fault, though the various Intel errata have this sort of fault showing up a number of times, with multi-byte ops crossing page boundaries or the ilk, so no reason to single out Linux yet. Windows does so much structure-padding everywhere by default it's much less likely to occur there. This is where the ops pipeline dump comes in handy if it's deep enough.
Phoronix: "certainly not the workloads most Linux users will be firing off on a frequent basis"
Bullshit. Anyone who does video encoding will easily max out a Ryzen. Anyone who builds software for a living will max out q Ryzen. In fact, just about anybody who needs more computing power than a Chromebook will max out Ryzen.
AMD you fucked up big time. Bigly.
And Phoronix, who are you to say what people should be doing with their machines? People paid for this computational hardware and should expect it to perform as advertised.
Microsoft and Intel doesn't support Windows 7 with their latest chips either (like that i7 7700 Kaby Lake for example). What's your point?
and assumed AMD would release a microcode fix (as they usually do) you would realize neither company has been making solid chips for at least 15 if not 20 years, and as they have tried to squeeze every ounce of performance out of, and every optimization into each chip, they've made design compromises that often don't show up until real world workloads.
Personally I am pretty sure the AMD segfaults could be handled by either retuning, or disabling that nice little 'neural network' frontend, and I am not entirely convinced the segfaulting wasn't some sort of intentional government approved cornercase for breaking the chips without need of an overt backdoor (like existing access to the AMD PSP for instance..)
Having said all this, I am going to be sticking to either AM3 or AM3+ chips for a few more years, and maybe a dual or quad G34 or an older (me_cleaner compatible) LGA 2011 motherboard until secure non-x86 alternative processors make it out. Basically everything 'indie' videogame-wise is running on Unity/dotnet/mono now, and most of what is not could be run with machine translation given Loongson MIPS style x86 translation microops and a 3-4ghz processor clock.
The end of x86 is nigh, lost not due to the performance crown, but to the security crown.
Whatever, dude. They blew it first.
You're dreaming if you don't think you run a similar risk with Intel. The only difference here is the proximal news cycle.
Tomorrow's Market Probably Won't Look Anything Like Today
Well, I suppose there are worse problems in life than paying 20% more for 20% less because of an edge case.
Unless you make it a habit, and it begins to consume larger fish, like your 401(k).
Anecdote here...
Ryzen 1700 w/ 64GB running Promox and 6 virtual machines - 1 Debian, 1 Gentoo (build machine), 1 PF Sense, and 3 Windows.
Been rock solid doing full world builds on Gentoo, PCI passthrough of a GTX 1070 card to one of the Windows VMs (gaming actually works well), and has only been rebooted once since getting it going. Uptime of 24 days.
No segfaults,
It is amazingly fast & quiet. Quite the upgrade from my I7-3770K.
... yet AMD has refused to support Ryzen on Windows 7.
The correct wording is this: ... yet AMD has refused to support Windows 7 on Ryzen.
You don't run a CPU on an OS unless you're talking virtualization - and even then most OSes rely on hardware support for the virtualization.
what causes the problem or the exact circumstances it happens under.
Not (necessarily) a big deal. CPUs have bugs. The kernel, the compilers and the standard libraries are all stuffed full of workarounds for various CPU errors. They are called "errata" and pretty much every CPU has them. (One could argue that corrigendum would be a more appropriate word for them.) Intel has had some big ones, the most memorable (off the top of my head) were FOOF and FDIV. The 286 was so riddled with bugs that everyone gave up trying to write a protected mode kernel and just waited for the 386.
Basically, they'll figure out what is causing the error and how to avoid it. If the workaround is easy, like "have the compiler reorder some instructions", a few patches will go out and life goes on, no big deal.
If the workaround is less easy, like "don't utilize all cores", or "bump the clock multiplier down to overcome a thermal or electrical issue", that is a much bigger deal. If you don't meet marketing numbers, your choices are refund or replace. Intel spent a half billion dollars replacing CPUs because of the FDIV bug, even though they calculated that most people would never encounter it and it was relatively easy to patch around (but the patch would have been a drag on FPU performance - and marketing again had made promises).
See that "Preview" button?
The correct wording is this: ... yet AMD has refused to support Windows 7 on Ryzen.
You don't run a CPU on an OS unless you're talking virtualization - and even then most OSes rely on hardware support for the virtualization.
Are you mentally retarded?
The OS runs on the CPU.
It was perfectly worded.
I've been having problems compiling various ports (such as emacs) under released versions of FreeBSD (both 10.3 and 11.1) on a Ryzen 5 (1600). It seems fairly repeatable, although at different places. This might be due to either the most recent bug or the other one mentioned in the Phoronix article.
The correct wording is this: ... I'm a big fat moron and you can ignore everything I say.
FTFY
It seems that Ryzen's hyperthreading, on Linux, under very rare circumstances, can cause memory errors. And Intel is spending millions flooding every tech forum and tech site with shill propaganda decaring this to be the 'end of the world'.
But Intel would like you to forget that its first two generations of hyperthreading were so broken, you had to switch it off altogether to do any serious work.
Hyperthreading needs scheduling to be sane and sympathetic. So no issues on the vastly better coded Windows. Sadly Linux is a joke from a software stability POV. So two threads on one core with inter-dependencies have many possibilities to cause bugs.
I once had Windows crash rarely when launching video. Turned out that I had a driver (emulating a DVD ROM) that failed to prevent its IRQ driver from 'paging out' under memory 'pressure'. And for some reason playing video had a real chance of grabbing the memory used by the interrupt code. The bug was 100% the fault of the IRQ code. And when i tracked it down, turned out there was a driver update that fixed the very bug.
Seems the Linux bug on Ryzen is the same sort of thing. One thread, apparently, has to be an interrupt. The compile load has to be so very taxing, the entire system RAM is under constant load. And I bet my bottom dollar the hopeless Linux coder has failed to flag the interrupt handling code as 'non-paging'. Or the Linux scheduler screws up ring zero ultra-priority interrurpt handlers, and lets then 'time out' under pressure.
Before you say "but Intel works"- WRONG. The person (sponsored by Intel) flooding forums with this 'bug' and the script to trigger it had to change the script code over and over again when users discovered it was triggering the same errors on Intel systems as well. What we know for REAL (as opposed to this fake news) is that certain compile workloads on Intel and AMD cause memory issues if hyperthreading is on. And the reason is certain to be bad linux coding.
If version 1,2,3,4,5 and 6 of the workload script crashed both Intel and AMD, and version 7 so far (so its claimed) only affects some ryzen chips, well the problem is clearly not unique to Ryzen.
PS again the people responsible for banging on about the issue are sponsored by Intel- and Intel has a very large active bounty for anyone who can 'prove' faults in Ryzen.
That tells me someone's code is fucked up, not that AMD's processors are screwed. Ain't happening on my Hackintosh, ain't happening on my Windows box.
Did someone let Grsecurity do the SMT kernel code?
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Well, the last time I had mod points, I wasted them on comments in a post announcing the invention of the telegraph so don't expect much modding from me.
Intel has been rock-solid since forever. AMD has been unreliable since forever. If you think this will change today, you're kidding yourself.
AMD makes gadgets for overclocking enthusiasts and gamers on a budget. There's nothing wrong with that, and they've kept Intel on their toes which is a good thing. But it's not the same class of product unless your focus is only on net gigahertz per dollar.
Being surprised by this kind of problem is like being surprised that Windows phones home or that HP is fucking you in the ass with their ink cartridges.
lucm, indeed.
> Intel has been rock-solid since forever.
The errata for Intel CPUs for the past five+ years indicate that this is not true.
What _else_ would people buy such CPUs for then, if not for "massive workloads"?
Also, somehow I'm feeling considerable distrust that the OS should be able to somehow 'fix' this. Probably by turning off features until it runs at a fraction of the speed, my guess is...
Anyway, yesterday I already sent out an email saying "don't buy Ryzen". First time I've ever done that, so well done, AMD.
Correct wording: Microsoft refuses to take patches from and or Intel for anything older than win10
Hah. Seems Intel has found a use for its coasters. Hanging out on Slashdot.
Somehow Intel having an HT bug and everyone's "hey, look they fixed it" meanwhile AMD has something similar and everyone's "yeah nope, dead architecture. shitty processor."
If you bothered to look further, it seems to affect only a specific batch of Ryzens and seems to be patchable via microcode.
Complete F00F.
https://arstechnica.com/inform...
I do believe that this has been confirmed to be the processor's fault.
In addition;
The person (sponsored by Intel) flooding forums
Citation Needed
It seems that Ryzen's hyperthreading, on Linux, under very rare circumstances, can cause memory errors. And Intel is spending millions flooding every tech forum and tech site with shill propaganda decaring this to be the 'end of the world'.
But Intel would like you to forget that its first two generations of hyperthreading were so broken, you had to switch it off altogether to do any serious work.
Hyperthreading needs scheduling to be sane and sympathetic. So no issues on the vastly better coded Windows. Sadly Linux is a joke from a software stability POV. So two threads on one core with inter-dependencies have many possibilities to cause bugs.
I once had Windows crash rarely when launching video. Turned out that I had a driver (emulating a DVD ROM) that failed to prevent its IRQ driver from 'paging out' under memory 'pressure'. And for some reason playing video had a real chance of grabbing the memory used by the interrupt code. The bug was 100% the fault of the IRQ code. And when i tracked it down, turned out there was a driver update that fixed the very bug.
Seems the Linux bug on Ryzen is the same sort of thing. One thread, apparently, has to be an interrupt. The compile load has to be so very taxing, the entire system RAM is under constant load. And I bet my bottom dollar the hopeless Linux coder has failed to flag the interrupt handling code as 'non-paging'. Or the Linux scheduler screws up ring zero ultra-priority interrurpt handlers, and lets then 'time out' under pressure.
Before you say "but Intel works"- WRONG. The person (sponsored by Intel) flooding forums with this 'bug' and the script to trigger it had to change the script code over and over again when users discovered it was triggering the same errors on Intel systems as well. What we know for REAL (as opposed to this fake news) is that certain compile workloads on Intel and AMD cause memory issues if hyperthreading is on. And the reason is certain to be bad linux coding.
If version 1,2,3,4,5 and 6 of the workload script crashed both Intel and AMD, and version 7 so far (so its claimed) only affects some ryzen chips, well the problem is clearly not unique to Ryzen.
PS again the people responsible for banging on about the issue are sponsored by Intel- and Intel has a very large active bounty for anyone who can 'prove' faults in Ryzen.
you seem like someone who has been payed (by most likely MS) to badmouth Linux
Hyperthreading needs scheduling to be sane and sympathetic. So no issues on the vastly better coded Windows. Sadly Linux is a joke from a software stability POV.
The problem has been reproduced on Windows, using WSL. Also FreeBSD and DragonFlyBSD are affected.
Just FYI: On Linux IRQ handlers can never be paged out on a very fundamental level.
You might think it's useful, but the thinking is that it just MIGHT be the IRQ (kernel memory) for the "get it back from disk" part. So in general stuff like that is never paged out.
In modern systems you'll probably use maybe 3-10Mb of memory for kernel code. If you have little main memory (1GB) that's still less than 1%. So no reason at all to change this policy.
Intel has been rock-solid since forever.
FDIV bug. F00F bug. TSX bug. Hyperthreading bug. Need I continue?
found your problem.
Its the systemd-amd thingy
My intel processors don't segfault under heavy load. That includes compiler load at home and virtual machine load at my employer. Why would I risk changing that?
It doesn't affect current chips, only the first series.
Untrue, my 2 week old Ryzen build exhibits this problem, also CPUs from multiple batches are affected.