Announcement

Collapse
No announcement yet.

Ryzen-Test & Stress-Run Make It Easy To Cause Segmentation Faults On Zen CPUs

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

  • #41
    Originally posted by nightmarex View Post

    This problem happens on intel chips as well, the "kill_ryzen" script was ridiculed for throwing segfaults on every cpu it was tested on.
    Incorrect, kill_ryzen would only lead to segfaults on Ivy bridge and this is a know hardware defect that newer generations don't have (or is fixed in microcode already).

    Comment


    • #42
      Originally posted by cde1 View Post
      This is anecdotal evidence but I underclocked my A10-7870K to 0.2V below normal and while everything seemed fine in Windows, when in Linux the system had L1 parity errors that were corrected most of the time. At -0.1V the problem did not appear, so I'm not surprised a problem with voltages could lead to what people see with Ryzen.

      Also in another thread on Phoronix I explained how to underclock the RX 470/480 by patching the amdgpu-pro kernel source. After a few months it appears the voltage I chose (820mV) is too low as it sometimes leads to page faults in the GPU. When that happens only a reboot helps.
      This thread is about RYZEN CPU not APU mate

      Comment


      • #43
        Originally posted by nightmarex View Post
        (John there's threads you promised to drop an update in and haven't please do so)
        Is "John" in this case me ? If so, I don't think I promised (or even "said") that I would provide an update, just that I would make sure the info and concerns were getting to the right people. I did that, and posted back to confirm it.

        If that isn't how you read things could you try to point me to the threads ? Thanks...

        Comment


        • #44
          Originally posted by schmidtbag View Post
          My motherboard's BIOS keeps my RAM voltage at 1.2v, even though it's supposed to be 1.3v. This alone makes the RAM very unstable.
          Most DDR4 faster than 2333 requires 1.35V

          Comment


          • #45
            I got curious and tried ryzen-test/kill-ryzen.sh on my system and it took almost 40 minutes until I got the segmentation fault. Hopefully this behaviour gets fixed and while doing so also fixed other more rare crashes and stability issues.

            Comment


            • #46
              Originally posted by bridgman View Post
              just that I would make sure the info and concerns were getting to the right people.
              the ryzen GCC compiling segfault bug in the closed source microcode is the best example why open-source from top to bottom matters.
              and on an opensource system from top to botton this bug would not happen...
              it just monopoles the bug-fix to one company otherwise if it was open-source many companies can compete to fix the bug
              in the end it is just magic security features so in the end we all can be "save" ,... and "save" in this meaning means that we are save to say that we can not and we should not fix bugs instead we need to obey our masters and hope for an update.
              Phantom circuit Sequence Reducer Dyslexia

              Comment


              • #47
                I can also confirm I get random segfaults on a 1700X system which is mostly used for compiling packages with gcc. Let's see how it will go with this new test.

                Comment


                • #48
                  Originally posted by c2h5oh View Post
                  Most DDR4 faster than 2333 requires 1.35V
                  Exactly, but for whatever reason my motherboard wants to set it to 1.2v, even though the default speed is 3GHz. That's actually pretty stable, but if I OC to 3.2, then I need to bump up the voltage.

                  Comment


                  • #49
                    Originally posted by Qaridarium View Post

                    the ryzen GCC compiling segfault bug in the closed source microcode is the best example why open-source from top to bottom matters.
                    and on an opensource system from top to botton this bug would not happen...
                    it just monopoles the bug-fix to one company otherwise if it was open-source many companies can compete to fix the bug
                    in the end it is just magic security features so in the end we all can be "save" ,... and "save" in this meaning means that we are save to say that we can not and we should not fix bugs instead we need to obey our masters and hope for an update.
                    Yeah that's a load of crap from Quaridiot who assumes that magically open sourcing CPU microcode will mean that bugs can't happen.

                    Just like the open source OpenSSL has literally never had a single bug ever.

                    Yeah -- just like that -- with the one major exception being that OpenSSL code is at least auditable using normal tools while CPU firmware by its very nature is going to be much more esoteric be it "open source" or not.

                    I'd rather have one undergrad intern at AMD with a modicum of training trying to actually fix the microcode vs. a million Quaridiots drooling over themselves while they chant about open source and do nothing of value.

                    Comment


                    • #50
                      Originally posted by Qaridarium View Post
                      and on an opensource system from top to botton this bug would not happen...
                      It doesn't happen when using Microsoft Windows. Which is the diametrical opposite of open source.

                      Comment

                      Working...
                      X