Announcement

Collapse
No announcement yet.

Continuing To Stress Ryzen

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

  • https://community.amd.com/message/28...omment-2816382
    amdmatt  7 août 2017 13:35 (en réponse à ahartmetz)
    We have been working closely with a small but important subset of Linux users that have experienced segment faults when running heavy or looping compilations on their Ryzen CPU-based systems. The results of our testing and analysis indicate that segment faults can be caused by memory allocation, system configurations, thermal environments, and system marginality when running looping or heavy Linux compile workloads. The marginality is stimulated with very heavy workloads and when the system environment is not ideal. AMD is working with individual users to diagnose the issues.

    We are confident that we can help each of you identify the source of the marginality and eliminate the segment faults. We encourage all of our Linux users who are experiencing segment faults under compile workloads to continue working with AMD Customer Care. We are committed to solving this issue for all of you.

    Comment


    • Originally posted by Michael View Post
      Got off the phone with AMD a few minutes ago. They are able to confirm problem in the very heavily compilation workloads and will be working with affected users. More info in article shortly.
      Great work, and good to finally see an official confirmation from AMD.

      For new thread readers, the new Ryzen bug confirmation article is here:
      https://www.phoronix.com/scan.php?pa...-Segv-Response

      Those people here in the thread who insulted Michael and other brave testers for having encircled the Ryzen-when-heavy-load-on-Linux bug: a sincere apology would be due.

      Comment


      • Originally posted by Hadrian View Post

        Great work, and good to finally see an official confirmation from AMD.

        For new thread readers, the new Ryzen bug confirmation article is here:
        https://www.phoronix.com/scan.php?pa...-Segv-Response

        Those people here in the thread who insulted Michael and other brave testers for having encircled the Ryzen-when-heavy-load-on-Linux bug: a sincere apology would be due.
        Wait... Can I join, Michael you Shintel... crap one second.. um, drama queen! That's all I got. Last few years Michael's been doing much better, however he was hard on AMD in the past and some people probably remember that. That said, people need to understand that these things could have been less nasty if AMD was more reassuring/acknowledging of the issue. Of course the counter problem is these annoying bastards are shouting in every forum about this "bug" situation which is what it is I guess.
        Last edited by nightmarex; 07 August 2017, 03:16 PM.

        Comment


        • Originally posted by scorpio810 View Post

          "Hello. As a software guy, I compile a lot of code, and occasionally gcc crashes with a segmentation fault for no obvious reason. I seem to remember that"]
          Please note that that quote is not mine, but was extracted from the start of the link by the Phoronix forum link software. I'm more of a hardware guy, I would say. In any case, I had to kill the save-ryzen run because there were build failures without a cause given, and complaints of " ****stack smashing detected**** " -- a new one on me. Reads more like a bad day at Walmart than a CPU being abused.

          Comment


          • Thank you, Michael. That is great news! Now that AMD is taking the problem seriously things must get back into track!

            Comment


            • Originally posted by drSeehas View Post
              This means absolutely nothing!
              Each ECC module is supported by every mainboard. But only in non-ECC mode.
              I want an officially working ECC mode!
              ASRock AM4 UEFI setup does have ECC settings, like setting scrub rate.
              With ASUS/Gigabyte there is not even an option to enable/disable ECC.

              And amd64_edac driver confirms operation in ECC mode.

              Comment


              • Originally posted by chithanh View Post
                ASRock AM4 UEFI setup does have ECC settings, like setting scrub rate. ...
                Which page in the Fatal1ty X370 Gaming K4 manual?
                Find "scrub" with 0 results.
                Find for "ECC" only these results:
                • AMD Ryzen series CPUs support DDR4 2933+(OC)/
                2667/2400/2133 ECC & non-ECC, un-buffered memory*
                • AMD 7th Gen A-Series APUs support DDR4 2400/2133 ECC
                & non-ECC, un-buffered memory*

                Comment


                • Originally posted by RyzenNewbie View Post
                  (...) set "kern.hz=1000" and started a fresh poudriere run - let's see how it goes...
                  and it froze; granted, I used only half of the shared-user-page patch, but at least, increasing the clock ticks frequency alone doesn't do anything, unfortunately. But was worth a try...

                  Comment


                  • Originally posted by RyzenNewbie View Post
                    (..) increasing the clock ticks frequency alone doesn't do anything
                    at least at that freeze/reboot part - I think I'll apply the full shared-user-page patch and try again with increased "kern.hz"...

                    Comment


                    • Originally posted by bridgman View Post
                      Are you talking about adding a guard page at the top of canonical userspace (the workaround Matt Dillon mentioned)?

                      Linux has had that for years, and I imagine Windows has as well:

                      http://elixir.free-electrons.com/lin...sm/processor.h

                      If BSD does not already have a guard page then I strongly recommend you add one because there are at least three older CPU families (two Intel and one AMD IIRC) which can exhibit unexpected behaviour when executing code in the top page of user space.

                      EDIT - looks like a guard page was just added to FreeBSD:

                      https://svnweb.freebsd.org/base?view...evision=321899

                      Just remembered that there was already a small (less than a page) guard region in BSDs but AFAIK other OSes went with a full page from the start.
                      yep, you're right - before r321899 there was no "guard page", wasn't neccessary - until now, I suppose:

                      https://bugs.freebsd.org/bugzilla/sh...id=219399#c216

                      Documentation, though, is another story...

                      Comment

                      Working...
                      X