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!
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.
..the faults only happen for people with massive parallel loads.
You know... the main reason people buy the CPUs.
Well you can (run make -j ), just be prepared to rerun that if/when it segfaults... For most people so far they only get the segfault if they do "make clean && make -jX" a few times so a single make of even a large project should probably work most of the time. Will be interesting to see if/when AMD will be able to fix it, particular why Windows does not seam to suffer from it yet will be interesting to see.
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.
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.
Processors are not components where you design for the average case and accept failures during peak load. How can a single byte of anything compiled on this processor from now on be trusted not to have been silently corrupted? Does multithreaded disk access run the risk of silently corrupting my files? Until fixed, this processor is toast.
I tend to buy at least one AMD system from each generation to give it a go and see if we can't get somewhere without these problems.
... which in itself was the best thing they ever did.... was amazingly fast. Instead of making a fancier CPU, AMD just kept making the same one and in each generation, focused on moving more bottlenecking systems on-die so the chip performance wouldn't be throttled by external buses. Unfortunately, during this era, both Intel and AMD sucked for development. GCC was a hot wreck as it was still running the crap based on Richard Stallman's code, 2.77 was useless for optimization and 2.89-2.95 was absolutely unreliable. RedHat was trying to make a living porting Linux to every damn device and make it run on ARM (SHITTY DEVELOPMENT PLATFORM at the time), etc... Visual C++ was great and Intel C++ was amazing but you weren't allowed to say that out loud. See, Microsoft was truly evil at the time.
amd486 - system/memory clock (same thing back then) was unstable and too high. This caused all kinds of issues with Maxwell's theorem and it was impossible to run a VESA local bus IDE or VGA adapter reliably. Also consider that the CPU was implemented almost entirely without x86 debug registers which made debugging GPFs a complete nightmare. Very often, Windows NT 3.1 and 3.5 would crash on there and people immediately pointed a finger at Microsoft for the GPFs and blue screens. In reality on AMD CPUs, nearly 50 percent of the GPFs were actually AMD's fault.
amd586 and 686... these CPUs were huge improvements, but there was some weird issue with the NMI that made debugging code almost impossible. They also had a really bad tendency of bursting capacitors on the system board
AMD with later generations
- built in MMU was implemented for users, not servers and developers. it was absolutely horrifying wondering whether my code was going to come out right. memory protection was more of a suggestion to them than a rule.
- AMD was killing every desktop benchmark, I actually loved AMD at this time as I was playing games and I had bought myself four Shuttle Cubes with the nVidia chipsets and AMD CPUs. I programmed on a dual-Celeron system at work with Linux because it was just faster and better.
- P4 vs Athlon days. Intel botched the P4 in so many ways it was terrible. It was almost not a challenge for AMD to out-perform Intel as the P4 architecture was an endless mess of cache miss hell. Now... let's be REALLY REALLY fair. P4 would have been the ultimate winner if CPUs were meant for DOS. What I mean is that on a system where there is only a single task (not including hardware interrupt handlers) the P4 pipeline is still a thing of true beauty. But the whole world had moved to Windows XP (got XP and my first P4 on the same shopping trip) and people left DOS, Windows 95/98/ME behind to run a real operating system for the first time... And the P4 was dead before it left the door. The Athlon which was basically equal to a higher clocked Pentium III with an internal MMU
Following generations of AMD (not including Ryzen)
- Branding hell... no one that didn't take an obsessive interest in AMD could tell what generation of chip they were buying or even what tier. Even now, having owned many of them, I couldn't tell you which ones were good or bad because I was lost. Intel's current numbering is bad... but not that bad.
- Memory problems. Yeh... wasted 5 days trying to debug a buffer overflow... then I switched to my Intel based laptop and it showed up in the debugger on the first try. AMD still can't make a fucking MMU. How the hell are you supposed to write a memory manager for an operating system if you can't trap buffer overflows when you clearly defined in the GDT and/or LDT where it should set bounds.
- Order of execution. On an Intel Core CPU, I can write multiprocessing code, set core affinity based on the position of the core relative to the ring buses. Then I can queue tasks that read/write L1/L2/L3 cache and based on the queui
How was the parent modded as "Funny"?
This is definitely not funny. Some users of compiled distros such as Gentoo have encountered the bug in fairly regular basis when trying to compile the distro -- which is needed to make it install.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley