Announcement

Collapse
No announcement yet.

Continuing To Stress Ryzen

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

  • Originally posted by RyzenNewbie View Post
    I have no idea whether a guard page is already included or not - I'm currently trying to clarify that with the FreeBSD devs and in how far that could be relevant. But my question still stands: why do I need that now and not with all the previous CPUs (including Phenom)?
    I'm new to this myself (I work on the GPU SW side) but AFAICS there are at least three different CPU families (1 from AMD) over the last decade which required special treatment, basically making sure that no code gets executed near the end of canonical user address space. The top of user process address space is the dividing line between the least privileged code and the touch-it-and-die non-canonical address space.

    Over time it seems that more "safe area" is required - presumably because each new CPU generation pre-fetches further ahead than the last one. In a sense Linux (and Windows I believe) got lucky by reserving a full guard page while BSD allocated a smaller guard area. As a result BSD has had to bump the guard area (to a full page) while other OSes did not.

    That's my impression anyways.
    Last edited by bridgman; 07 August 2017, 02:02 PM.
    Test signature

    Comment


    • Originally posted by drSeehas View Post
      Where can I find these official links?
      I couldn't find it neither on their websites nor in the manuals. At least for the ASRock Fatal1ty X370 Gaming K4. The manual of BIOSTAR X370GT7 Ver. 5.x (don't like the BIOSTAR as it doesn't have intel LAN) states "supports non-ECC 4/ 8/ 16 GB DDR4 module".
      About ASRock, I asked in their official forums for the AB350M.
      http://forum.asrock.com/forum_posts....n-ab350m#24361
      Biostar I read from their mobo specs. Will have to look up.

      Comment


      • 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.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • Originally posted by bridgman View Post
          Over time it seems that more "safe area" is required - presumably because each new CPU generation pre-fetches further ahead than the last one. In a sense Linux (and Windows I believe) got lucky by reserving a full guard page while BSD allocated a smaller guard area. As a result BSD has had to bump the guard area (to a full page) while other OSes did not.
          thank you for the detailed explaination - appreciate it, seriously. I'll forward that to the FreeBSD devs as well. If that's all true it would haven very nice and kind to have been told earlier...

          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.
            thank you, Michael; at least, there's some real progress going on now; and I think that all the hassle - even with my two buddies - could be worth it because that's more advancement than in the last four months...

            Comment


            • Originally posted by chithanh View Post
              About ASRock, I asked in their official forums for the AB350M.
              http://forum.asrock.com/forum_posts....n-ab350m#24361 ...
              ???
              "support DDR4 2667/2400/2133 ECC & non-ECC, un-buffered memory"
              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!
              Last edited by drSeehas; 07 August 2017, 01:41 PM.

              Comment


              • I have spent a lot of time reading the forum at AMD: https://community.amd.com/thread/215...t=420&tstart=0. [This link may be to the thread point where I am so far.] There seem to be a few ameliorations that have been discovered, but they are not satisfactory for most in the long run. As my Ryzen PC is aimed at home theater, I am not likely to be affected very often by the segfault, but adopting Ryzen for other purposes would certainly bring this issue to the foreground.

                Some "fixes" that have been noted include:
                • turning off the RAM randomizing function via sudo echo 0 > /proc/sys/kernel/randomize_va_space (I haven't tested this yet, normally the value there should be 2.)
                • disabling opcache (In the C6H, this is apparently in Advanced>AMD/CBS>Zen....>Opcache control
                • disabling SMT (and making your CPU 8 cores and 8 threads)
                • RMA the CPU (just another spin of the silicon lottery faro wheel)

                Of specific interest to me is the discovery that along with kill-ryzen, there is a script called save-ryzen in the same package. Save-ryzen has the property of keeping the computational threads from wandering among the core threads. This was intended to potentially minimize the segfault problem or at least narrow the range of causes; however, I am running it now and there are 2 segfaults at start. This mode of compilation does make Mint's System Monitor's cpu utilization plot a lot less busy. I'll run it for a while to see if the total fault count is lower than for kill-ryzen.

                It seems that if one has to do a heavy compilation under Linux and has a segfault problem keeping it from completing, then disabling SMT and taking a hit on speed is the best technique at present.
                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

                Comment


                • Originally posted by RyzenNewbie View Post

                  thank you, Michael; at least, there's some real progress going on now; and I think that all the hassle - even with my two buddies - could be worth it because that's more advancement than in the last four months...
                  They sound pretty committed now to getting the issue under control. (It may have been that the upper management wasn't aware of the Linux issues until splashing attention onto it in recent days.)
                  Michael Larabel
                  https://www.michaellarabel.com/

                  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.
                    That is something already. Thanks for pinging them!

                    Comment


                    • Originally posted by kaseki 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
                      Same here, this machine is the nighlty packages builder ( Debian, Ubuntu, Windows, macOS) bought with user donations for a electrical opensource software, I dream of a new AGESA or firmware fix, without do RMA this CPU and try my luck again to a new silicon lotery. ;-)
                      https://qelectrotech.org/forum/viewt...pid=6405#p6405
                      Last edited by scorpio810; 07 August 2017, 02:37 PM.

                      Comment

                      Working...
                      X