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

  • #91
    Originally posted by debianxfce View Post

    Cool down you open source believer. It is very expensive to fix errors in silicon. It is cheap to fix software bugs.
    dude you even call yourself "debian"+"xfce".. both Open-Source with copyleft licenses....

    in fact this topic of hardware bugs here is all about closed source solutions who prove the point that ISA+BIOS+Microcode+Firmware should be open-source to find bugs like this.
    Phantom circuit Sequence Reducer Dyslexia

    Comment


    • #92
      What, aside from CPU is common to the problems? Common motherboard? Overclocking? Power supply voltage jitter due to work load? Re CPU's, is it only with the x series like the 1800x to 1700x or it includes the 65 watt CPU's as well?
      Crosstalk can occur if mother board signal traces are too close to each other.

      I recall in some of my ancient high frequency circuit designs that we had to put a ground trace between pairs of signal lines. Could that be the cause of the random abort problem?
      Last edited by lsatenstein; 08-06-2017, 04:16 PM.

      Comment


      • #93
        Originally posted by garegin View Post
        Can someone tell me why this doesn't happen in windows?
        My answer to you. Simply because most Linux and Windows users do not run 8 or 9 concurrent large large compiles concurrently and repeatedly.

        Comment


        • #94
          I do not wish to blame a vendor, but from the statistics I have seen, and reported on the web, including configurations, the common motherboard vendor is MSI.
          In an earlier posting, the Asus motherboard user reported no errors.

          I posted an idea about cross talk between adjacent lines laid out too close together on the mother board. It may be that between each line they need to lay a ground line.
          I think the problem is not the CPU chip, but the hardware layout with the mother board.

          Comment


          • #95
            Linux is just busted again.. what else is new.. you can work around this by setting make -j1

            Edit: With Ryzen 7 1700, on FreeBSD 12-CURRENT, building gcc-6.4.0 from ports default opts except:
            FORCE_MAKE_JOBS=YES MAKE_JOBS_NUMBER=17 CPU load shows all 16 threads at 100% I built it 3 times, no segfaults. the build takes about 20 minutes. Ryzen is fine.. Linux well.. hmm.. ya idk.. Oh wait maybe I hit it with Mesa, testing.. looks like maybe, 1 success 1 fail. Just more prevalent on Linux? hmm..

            The Gentoo people are still fucking crazy, they should be building with generic, not the intel cpu options and znver1 doesn't even work yet.
            Last edited by k1e0x; 08-07-2017, 09:53 AM.

            Comment


            • #96
              Originally posted by lsatenstein View Post
              I do not wish to blame a vendor, but from the statistics I have seen, and reported on the web, including configurations, the common motherboard vendor is MSI.
              In an earlier posting, the Asus motherboard user reported no errors.

              I posted an idea about cross talk between adjacent lines laid out too close together on the mother board. It may be that between each line they need to lay a ground line.
              I think the problem is not the CPU chip, but the hardware layout with the mother board.
              Nope, it's not only MSI: https://docs.google.com/spreadsheets...#gid=950983791

              Comment


              • #97
                Guys, such artificial torture tests may fail any CPU. Let's not panic.
                The "situation" can also be temporal depending on the updates on BIOS, kernel, gcc, libc, etc...
                By the way, on different Linuxes different results, can it be also scheduler stuff? Do people posting about their scheduler?
                How about other compilers, interpreters? Pyhton, java,...?
                You may try compiling ns3 (http://www.nsnam.org/) network simulator which is one of the toughest compile job I have ever seen so far!
                I would love to see a "compilation of responses" from AMD and from motherboard manufacturers. Also from kernel guys!!!

                All the best...

                Comment


                • #98
                  maybe now finally fixed in dragonflybsd? http://lists.dragonflybsd.org/piperm...st/626190.html

                  Comment


                  • #99
                    Originally posted by kemalihsan View Post
                    Guys, such artificial torture tests may fail any CPU. Let's not panic.
                    The "situation" can also be temporal depending on the updates on BIOS, kernel, gcc, libc, etc...
                    By the way, on different Linuxes different results, can it be also scheduler stuff? Do people posting about their scheduler?
                    ...
                    no, an artificial torture test will not fail any CPU - a stable CPU should be "bug-free" enough that how matter how long you throw math to it it will calculate correctly.

                    Comment


                    • Originally posted by rene View Post
                      maybe now finally fixed in dragonflybsd? http://lists.dragonflybsd.org/piperm...st/626190.html
                      See https://www.phoronix.com/forums/foru...206#post969206

                      Comment

                      Working...
                      X