Slashdot Mirror

← Back to Stories (view on slashdot.org)

AMD Confirms Linux 'Performance Marginality Problem' On Ryzen (phoronix.com)

Posted by BeauHD on from the isolated-problems dept.

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."

68 of 120 comments (clear)

  1. Just like FDIV by Anonymous Coward · · Score: 3, Insightful

    Will only affect a few people, so we aren't replacing any CPUs. Way to hand Intel the business, AMD!

    1. Re:Just like FDIV by ravenshrike · · Score: 1

      Except it doesn't apply to Threadripper, Epyc, or Ryzen Pro. And it doesn't affect all of normal Ryzen either. So the entirety of the market they're handing to Intel is those buying personal systems who run large amounts of parallel compilation workloads and who don't feel like RMAing till they get a chip without the defect.

    2. Re:Just like FDIV by arglebargle_xiv · · Score: 3, Insightful

      Except it doesn't apply to Threadripper, Epyc, or Ryzen Pro.

      We don't even know if it's an AMD problem, it could be any one of a number of previously-unnoticed Linux issues that happen to show up on Ryzen (note that the text says "may also affect other Unix-like operating systems", not "exists under FreeBSD as well", so currently it's pure speculation that it extends past Linux). We'll have to wait and see what further investigation turns up...

    3. Re:Just like FDIV by Gr8Apes · · Score: 1

      Except it doesn't apply to Threadripper, Epyc, or Ryzen Pro.

      We don't even know if it's an AMD problem, it could be any one of a number of previously-unnoticed Linux issues that happen to show up on Ryzen (note that the text says "may also affect other Unix-like operating systems", not "exists under FreeBSD as well", so currently it's pure speculation that it extends past Linux). We'll have to wait and see what further investigation turns up...

      That's more than a little interesting. Wonder if it affects NetBSD? If both FreeBSD and NetBSD are free of this error, I may have my next system.

      --
      The cesspool just got a check and balance.
  2. oblig by Anonymous Coward · · Score: 5, Informative

    certainly not the workloads most Linux users will be firing off on a frequent basis

    I run Gentoo you insensitive clod!

    1. Re: oblig by Anonymous Coward · · Score: 1

      And taking a single step on their own is probably the heaviest thing they do

    2. Re: oblig by GameboyRMH · · Score: 2

      Have you tried watching H.265/HEVC-encoded anime? :-P

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
    3. Re:oblig by Misagon · · Score: 4, Insightful

      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
  3. MT was what AMD had over Intel by Anonymous Coward · · Score: 1

    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?

    1. Re:MT was what AMD had over Intel by F.Ultra · · Score: 3, Insightful

      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.

    2. Re:MT was what AMD had over Intel by Rockoon · · Score: 1

      Maybe someone can put on the table the key differences between Linux and Windows thread scheduling, because surely its in there somewhere.

      --
      "His name was James Damore."
    3. Re: MT was what AMD had over Intel by Anonymous Coward · · Score: 1

      I suspect there are more users compiling under Linux. I run 16 thread parallel compiles daily under Win10 and see a lot of internal compiler errors on my 1700x, errors my fx8370 never displayed on 8 thread builds. There a good chance they simply haven't had any reports for windows yet.

    4. Re:MT was what AMD had over Intel by OneAhead · · Score: 2

      This. The very existence of that flag in an ubiquitous utility that is commonly run even by end users (of at least some distros ;-)) makes the following sentence in TFA sound quite ignorant at best (and dishonest at worst):
      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.

    5. Re:MT was what AMD had over Intel by rew · · Score: 2

      Wait!

      What is happening is that the CPU will mis-execute some instruction so that some "data" becomes invalid. When a compiler is running such data is often a pointer and the wrong pointer often results in a segfault.

      But especially while we don't know what's going on exactly, this could also corrupt data. i.e. give the wrong results in a computation, or result in a bad binary when the running program is a compiler.

      So you're suggesting I trust the resulting binaries when the compilation doesn't segfault? Even when I have to try several times? Ehh. not me!

    6. Re:MT was what AMD had over Intel by Tough+Love · · Score: 1

      Multi-threaded performance was the main advantage that Ryzen had over Intel.

      This type of processor bug can typically be fixed with a microcode patch. Mainly a matter of getting sufficient engineering resources on it and isolating the cause. The publicity certainly helps that process, as does the extensive community testing.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    7. Re:MT was what AMD had over Intel by F.Ultra · · Score: 1

      Learn to live in the danger zone :)

  4. Micro needle in mega haystack. by saccade.com · · Score: 1

    I do not envy the crew assigned to tracking that bug down.

    1. Re: Micro needle in mega haystack. by Anonymous Coward · · Score: 5, Insightful

      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.

    2. Re: Micro needle in mega haystack. by lucm · · Score: 1

      Or it could just be buggy Chinese spyware.

      --
      lucm, indeed.
    3. Re: Micro needle in mega haystack. by LostMyBeaver · · Score: 5, Insightful

      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.

      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 ... 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.
      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

    4. Re: Micro needle in mega haystack. by beerbear · · Score: 1

      Apparently the segfault happens if the data corruption happens to affect a pointer. If it's not a pointer, you get no segfault, but could have silent corruption.

      --
      Hold my beer and watch this!
  5. so how does that work? by Jodka · · Score: 4, Insightful

    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.
    1. Re:so how does that work? by Kjella · · Score: 1

      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.

      Well, from the fact that RMAs has worked for some people and not for others as well as the non-deterministic crashes it seems like it's down to production variation, some chips get unstable and corrupt data if hammered a particular way. Most likely there'll be some microcode update to stagger the problematic sequence and a new stepping increasing the safety margin to fix it properly. Still not good news for AMD, since those who can't easily verify their results will stay away until the scope of the problem is known.

      --
      Live today, because you never know what tomorrow brings
    2. Re:so how does that work? by tlhIngan · · Score: 1

      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.

      Well, think of a modern CPU as a collection of execution units, In most CPUs, execution units overlap in functionality - a complex instruction may issue several loads (memory to CPU) and stores (CPU to memory), cause several integer units to be called into play (to actually calculate data, or compute addresses) which may cause other loads and stores (especially if it requires hitting the page tables) and more computation. Oh yeah, and data is held in registers, which are renamed - non-dependent uses of a register will allocate a new temporary register between instructions, while dependent registers may be worked on independently if it's not needed until later (result forwarding - if one instruction is computing a complex memory address, and the next one uses it, that instruction can work without knowing what the final destination is until the last minute - usually a cycle before when the result is finally computed, and the result forwarded so it's ready when the following instruction actually needs it).

      This complex dance is coordinated with a control unit controlled via microcode. And often, there will be combinations that get the control unit completely confused (especially so in hyperthread mode, which uses one core to emulate two processors, so one control unit has twice the accounting work). Just a bug that perhaps hangs onto a result a bit longer than it should causing another instruction using the same unit to corrupt the value. But that only happens if you get the control unit in a state caused by a series of instructions and then use another instruction that finally collapses the whole thing. Especially ones that happen using loads that get scheduled on the same core.

    3. Re:so how does that work? by AmiMoJo · · Score: 3

      All modern CPUs run microcode that is updated on boot by the BIOS. So fixing this will just be a microcode update, i.e. a BIOS update. AMD has been quite good at getting vendors to ship such updates for their motherboards and systems, but if for some reason they don't you could load it via a driver under Linux too.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    4. Re:so how does that work? by rew · · Score: 3, Interesting

      There MUST be some things in hardware to execute anything. While they (the chip manufacturers) have surprised me in the past, not all bugs CAN be fixed with a microcode update.

      A long, long time ago, people wrote "self modifying code". Say for doing bit-operations on parts of the screen buffer, you might pass 1 for AND 2 for OR and 3 for XOR. The function could then place the AND/OR/XOR opcode in the middle of the doit loop and then perform the loop.... So one day the manufacturer guarantees that the new machine will execute everything the old one did. Bad move. Turns out the new machine is faster because it prefetches instructions. By the time the code has determined the opcode for inside the loop, the loop (with the last AND/OR/XOR opcode in place) has already been prefetched. This prefetching is at the core of why the machine is fast. Implemented in hardware. Can you fix that with a microcode update? Apparently in the case at hand (PR1ME9955): yes.

      But I can easily see it happen that either you disable the whole prefetching stuff (slow everything down enormously) or you need say an extra comparator ("Is the store happening near my PC, possibly near my prefetch queue?") to allow for "normal" cases to use the prefetch queue, but this special case to flush the queue only when necessary. In any case, the microcode was updated and stuff worked properly again.

  6. Don't worry... by ckatko · · Score: 5, Insightful

    ..the faults only happen for people with massive parallel loads.

    You know... the main reason people buy the CPUs.

    1. Re:Don't worry... by alvinrod · · Score: 2

      Well they do say Threadripper and Eypic are unaffected, and I think those chips are a different stepping than the initial batch of Ryzen chips so the probably may already be fixed. It may be possible to fix the others with a firmware update, though who knows how long that will take to roll out depending on other things AMD is working on and their other priorities.

    2. Re:Don't worry... by arth1 · · Score: 1

      Yeah. i was contemplating getting a Ryzen for my new PC internals, which are due for changing out now.
      But if I can look forward to crap like this, it's not even an option - even if it were free, I wouldn't use it.

  7. why would I buy a processor that *might* segfault by iggymanz · · Score: 4, Insightful

    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.

  8. These are a bear to track down by Anonymous Coward · · Score: 1

    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.

    1. Re:These are a bear to track down by lucm · · Score: 1

      Or maybe the problem does happen on Windows and nobody noticed because they're constantly rebooting to install an update anyways.

      --
      lucm, indeed.
    2. Re:These are a bear to track down by Misagon · · Score: 4, Informative

      It has been confirmed to be a processor bug, not a software bug.
      BSD kernel developer Matt Dillon sent AMD a reproducible test case back in April.
      You can read more about it here.

      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
  9. Phoronix FAIL by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:Phoronix FAIL by 0123456 · · Score: 3, Informative

      Not to mention that one of the reasons we want more cores in our desktop machines is to speed up C++ compiles by compiling more files in parallel.

    2. Re:Phoronix FAIL by doconnor · · Score: 1

      Video encoding makes heavy use of the SIMD units of the processor which is a different type of load then compiling which makes heavy use of the conventional integer logic part of the processor.

    3. Re:Phoronix FAIL by snarfies · · Score: 1

      "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."

      In other words, Phornonix is 100% correct.

  10. Re:AMD shoots itself in the foot with Windows too by Anonymous Coward · · Score: 1

    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?

  11. Because if you read the errata for Intel... by Anonymous Coward · · Score: 1

    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.

  12. Re:AMD shoots itself in the foot with Windows too by Kremmy · · Score: 1

    Whatever, dude. They blew it first.

  13. So far so good by I'm+just+joshin · · Score: 4, Informative

    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.

    1. Re:So far so good by jon3k · · Score: 1

      PCI passthrough of a GTX 1070 card to one of the Windows VMs (gaming actually works well),

      I'm currently building a Ryzen linux box (parts are literally sitting on the desk beside me) and I've been following the PCIe pass-through intermittently, mostly Wendell and Level1Techs. Can you share some details on how you got everything working and issues you've run in to?

    2. Re:So far so good by I'm+just+joshin · · Score: 2

      I mostly followed this: https://pve.proxmox.com/wiki/P.... If you're passing a nVidia GPU, be sure to pull a copy of its BIOS and pass it to KVM.

      In addition, I passed most USB ports, and my PCI-E Soundblaster card to the Windows VM.

      Good luck.

    3. Re:So far so good by jon3k · · Score: 1

      Thanks for your reply, I appreciate it. Have you had good luck with it?

    4. Re:So far so good by I'm+just+joshin · · Score: 1

      It was a pain to get working, but has been fantastic.

      I lose about 5% performance from virtualizing everything. Obviously, when gaming, I have the load from the other stuff turned down.

    5. Re:So far so good by jon3k · · Score: 1

      That's really encouraging, thanks again.

  14. I don't see... by thadtheman · · Score: 1

    what causes the problem or the exact circumstances it happens under.

  15. You guys new or something? by Orgasmatron · · Score: 4, Interesting

    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?
    1. Re:You guys new or something? by Misagon · · Score: 2

      The first bug report with a test case that reproduced the bug was submitted to AMD in April, and they have acknowledged the bug first now.

      And how long would we have to wait for a microcode update?

      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
  16. Intel's first 2 gens of hyperthreading were bust by Anonymous Coward · · Score: 1, Interesting

    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.

  17. Re:Servers? by arth1 · · Score: 1

    They're not using Ryzen in the server market, they've got ThreadRipper and Epyc for that. Which (apparently) aren't affected.

    No, but they are targeting the workstation market, where a good sized chunk of the users do things like building software. That's one of the factors that make buyers choose more cores and RAM over higher clock speeds.

  18. Only on Linux by Khyber · · Score: 1, Interesting

    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.
    1. Re:Only on Linux by Dagger2 · · Score: 2

      You could just as easily argue that the fact that Linux works fine on other Ryzen processors, AMD's older processors and Intel's processors, and only segfaults on these specific Ryzen models, tells you that it's these processors that are broken, not Linux.

      Of course -- and I shouldn't really have to explain this on Slashdot of all places, but neither of these observations actually tell you where the problem is. Doing that involves doing some investigation, and the fact that AMD appear to be accepting blame suggests that they've done the investigation and believe it's their fault.

    2. Re:Only on Linux by Khyber · · Score: 1

      I have an actual background in hardware and software troubleshooting. This is very clearly the sign of bad code, not bad hardware. Testing for similar problems under both Windows and my Hackintosh boot partitions, using software compilation tools on a high thread count. Oh, BTW, since Windows 10 has a SMT Scheduling problem with Ryzen (but only Windows 10, Windows 7 is unaffected) again this tells me that it's clearly in the newer software implementations, not hardware, as I'm unable to trigger the SMT bug using Slackware and Linux kernel 2.6.39 but can reliably trigger it in any kernel 3 and higher.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    3. Re:Only on Linux by Ash-Fox · · Score: 1

      Try not to take Khyber too seriously.

      One time I reflected on the fact on IRC that there were very few musicians in the furry fandom. He then went and made a story that there are many, but they're on a secret IRC network at a certain domain which wasn't registered. When this was pointed out to him, he then went on a tirade about how his father works for the DoD and had his domain super special secret ninja registration. I pointed out that I couldn't resolve the domain anyway, he then went on to say it was IPv6 only. I checked over IPv6, no DNS resolution, no name servers, nothing.

      But we were wrong and he kept fabricating various credentials.

      Someone else shortly registered the domain in the chat to prove him wrong.

      --
      Change is certain; progress is not obligatory.
    4. Re:Only on Linux by Khyber · · Score: 1

      Windows 10 Pro has the SMT bug. It's reliably reproducible locally and via network nodes.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    5. Re:Only on Linux by Khyber · · Score: 1

      https://forums.anandtech.com/t...

      Have fun reading.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  19. Mod Points by bobbuck · · Score: 2
    "I have no idea how this isn't +5."

    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.

  20. Re:why would I buy a processor that *might* segfau by lucm · · Score: 1

    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.
  21. WTF? by johannesg · · Score: 1

    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.

    1. Re:WTF? by Anne+Thwacks · · Score: 1
      What _else_ would people buy such CPUs for then, if not for "massive workloads"?

      Because "shiny" - why do most people buy new processors?

      --
      Sent from my ASR33 using ASCII
  22. Something is bugging me about that by dbIII · · Score: 2

    Intel has been rock-solid since forever

    Complete F00F.

  23. Re:why would I buy a processor that *might* segfau by iCEBaLM · · Score: 2

    Intel has been rock-solid since forever.

    https://arstechnica.com/inform...

  24. Re:Intel's first 2 gens of hyperthreading were bus by Anonymous Coward · · Score: 1

    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

  25. Re:Intel's first 2 gens of hyperthreading were bus by Anonymous Coward · · Score: 1

    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.

  26. Re:Intel's first 2 gens of hyperthreading were bus by rew · · Score: 1

    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.

  27. Re:why would I buy a processor that *might* segfau by cheesybagel · · Score: 1

    Intel has been rock-solid since forever.
    FDIV bug. F00F bug. TSX bug. Hyperthreading bug. Need I continue?

  28. Re:why would I buy a processor that *might* segfau by iggymanz · · Score: 1

    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?