Announcement

Collapse
No announcement yet.

New Ryzen Is Running Solid Under Linux, No Compiler Segmentation Fault Issue

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by BillBroadley View Post
    For those us of who haven't upgraded yet. How do we buy a known good Ryzen from week 30 or newer?
    I guess just wait a few more weeks for old stock to clear out of the channels...

    Comment


    • #32
      Originally posted by chuckula View Post
      So does this mean that it takes a silicon fix to get around the bug or will it be possible to fix via microcode?
      If it was a bug, it probably was fixed with microcode, as a silicon fix would take way longer IMO.

      Comment


      • #33
        I just ran the kill-ryzen script, it takes around a minute for the first segfault to occur. I haven't noticed this happen outside of this script. The system freezes haven't been as rare as I want them to be, though.

        I'll probably have to RMA the CPU once the cause of the freezes has been found.

        Comment


        • #34
          Running ./ryzen-kill.sh on my week 5 1700X as we speak. 40 minutes and counting. Still no segfaults. Looks like I'm one of the lucky one's who bought on launch but didn't get a bad chip.
          • Distribution: Ubuntu-GNOME 17.04
          • Desktop Environment: GNOME
          • Kernel: 4.12.8-041208-generic
          • Distribution Architecture: 64bit
          • RAM: 64GB DDR4-2400 Kingston HX424C14SBK4/64
          • CPU Model: Ryzen 1700X
          • Motherboard: Asus PRIME X370-PRO (BIOS 0807)
          • GPU Model: Radeon R9 Fury

          Comment


          • #35
            Originally posted by nomadewolf View Post
            If it was a bug, it probably was fixed with microcode, as a silicon fix would take way longer IMO.
            We'll never know for sure unless AMD decides to spill it out, which they likely never will. It's fixed, and they'll have other things to work on.

            Microcode, and fixes to it, get uploaded into the CPU by the BIOS at boot-up by the way. Nor was it a "silicon fix", because it's the same stepping. It's more likely a new issue they haven't encountered before. It's not their first CPU design. Why would one want to assume it's something one would know or understand when AMD themselves describe it as being a complex issue? If they told you the exact cause and how it led to the symptoms would you even comprehend it all? If AMD held a 3 hour lecture on the issue would most people on this forum get bored after only 10 minutes, walk out and hope for Phoronix to sit through it and sum it up into something they can comprehend.
            Last edited by sdack; 25 August 2017, 06:37 AM.

            Comment


            • #36
              Originally posted by Michael View Post

              I haven't been told anything from AMD about the possibility of a microcode fix. If affected by the issue they recommend contacting AMD Customer Care, which at least for now sounds like an RMA.
              Michael, can you compare some test made with the old cpu with the new cpu to view if there is any cpu performance difference?

              Thanks,

              Comment


              • #37
                Originally posted by bisby View Post

                I'm at 45 minutes now. The real question I guess i have is: is this just a lucky run where the issue could show up after 15 seconds on a quick compile? I compile a lot of stuff from the AUR, but i'm not using gentoo or something. or if it doesnt show up after an hour or so, will it generally not affect day to day operations.

                Does this affect things other than compilation, or is compilation just the obvious and most reliable way to get a visible response.
                I discovered the problem after getting a segfault while compiling openblas. This is not a very long compilation. So at least for my case, it does happen in real world scenarios. I say many people that compiled mesa complaining too. On the other hand I had also compiled the kernel many times while testing for possible fixes and it never crashed. So, your mileage may vary.

                Comment


                • #38
                  Originally posted by Brisse View Post
                  Running ./ryzen-kill.sh on my week 5 1700X as we speak. 40 minutes and counting. Still no segfaults. Looks like I'm one of the lucky one's who bought on launch but didn't get a bad chip.
                  • Distribution: Ubuntu-GNOME 17.04
                  • Desktop Environment: GNOME
                  • Kernel: 4.12.8-041208-generic
                  • Distribution Architecture: 64bit
                  • RAM: 64GB DDR4-2400 Kingston HX424C14SBK4/64
                  • CPU Model: Ryzen 1700X
                  • Motherboard: Asus PRIME X370-PRO (BIOS 0807)
                  • GPU Model: Radeon R9 Fury

                  Nope, not one of the lucky ones. It just took a little more time than I expected:
                  [loop-13] TIME TO FAIL: 2384 s

                  I then went ahead and updated to latest BIOS (0810) and kernel (4.12.9). Tried again, and it failed after just forty something seconds IIRC, but then ran quite a while without errors after that. Looks like the time to failure is very inconsistent on my machine.

                  Comment


                  • #39
                    Originally posted by khnazile View Post
                    Well, fuck. Getting the CPU RMAed would be really hard here in Russia, and I'm not sure if it would work for OEM CPU.
                    RMA form has fields for part number and serial number. On the retail box it's printed on a sticker. Unless it's on the tray/box somewhere for your OEM part, it's only printed on the top face of the CPU itself.

                    The other entrypoint is via the regular support contact address, which doesn't have such a mandatory field.

                    In any way, as mentioned before you're going to be told to demonstrate that your case isn't horribly cooled, run some tests with stock and altered vcore and soc voltages, and eventually be fed into the RMA process.

                    In my case, I'm 10 days into the process and am currently enjoying the wonders of interacting with DHL to get the part shipped to AMD in the Netherlands, I'm in Sweden. Freight companies may vary by region, but if you have a DHL presence in Russia, you're probably good.

                    As for OEM vs. retail, official stance on the website seems rather bleak, but I'd say it probably doesn't hurt to try in this case, as it's rather exceptional.

                    Comment


                    • #40
                      Originally posted by sdack View Post
                      Microcode, and fixes to it, get uploaded into the CPU by the BIOS at boot-up by the way.
                      Also by OS kernel (both Windows and Linux), and in many cases the one loaded by OS is newer, because board firmwares aren't really up-to-date to anything.

                      Why would one want to assume it's something one would know or understand when AMD themselves describe it as being a complex issue? If they told you the exact cause and how it led to the symptoms would you even comprehend it all? If AMD held a 3 hour lecture on the issue would most people on this forum get bored after only 10 minutes, walk out and hope for Phoronix to sit through it and sum it up into something they can comprehend.
                      Yeah, I would totally understand it and be able to dumb it down enough to explain it to plebes in the forum after Phoronix made yet another "article" where you can find a few cherry-picked (highly technical) statements from the source that are not explained in any way.

                      Comment

                      Working...
                      X