Announcement

Collapse
No announcement yet.

Continuing To Stress Ryzen

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

  • #81
    Interesting enough. Not all segmentation faults are logged and can be shown in dmesg. If I run kill-ryzen.sh (I agree, thats a bad name), nothing appears when I type dmesg, but I get in the console that is running the script

    [loop-12] Sat Aug 5 20:11:06 -03 2017 start 0
    [loop-13] Sat Aug 5 20:11:07 -03 2017 start 0
    [loop-14] Sat Aug 5 20:11:08 -03 2017 start 0
    [loop-15] Sat Aug 5 20:11:09 -03 2017 start 0
    [loop-12] Sat Aug 5 20:13:10 -03 2017 build failed
    [loop-12] TIME TO FAIL: 136 s
    [loop-6] Sat Aug 5 20:16:05 -03 2017 build failed
    [loop-6] TIME TO FAIL: 311 s

    Now, to find out the reason for the failure, just go to /mnt/ramdisk/workdir/buildloop.d/loop-12/build.log where I can find

    /mnt/ramdisk/workdir/gcc-7.1.0/mpfr/src/generic/mparam.h:1:0: internal compiler error: Segmentation fault

    This internal segmentation fault is not logged in dmesg but the build fails anyhow. I am not sure you can get this information easily using phoronix-test-suite.
    Last edited by pjssilva; 05 August 2017, 07:21 PM. Reason: Again, fixing typo.

    Comment


    • #82
      ok I will not back to AMD after this.

      Comment


      • #83
        Just completed the one-hour Phoronix test on my Ryzen 7 1800X running at 3.9 GHz, with 2 x 16 Trident Z 3200C14 DDR4 operating at 3333 MT/s on an Asus Crosshair VI Hero board. Various voltages per the below image.

        There were just shy of 80 conftest seg fault errors, and one general protection error in libc. CPU temperature during this test was about 9 degrees lower than when rendering the "Classroom" scene from Blender's home page. The DRAM at the listed settings has passed 4 hours of Google Stress Application Test.

        Now to try the kill Ryzen test.

        Comment


        • #84
          Originally posted by andre30correia View Post
          ok I will not back to AMD after this.
          I wonder which CPUs you'll buy? After all, Skylake chips froze during complex workloads and had broken hyperthreading for almost two years.

          Comment


          • #85
            Besides the segfaults, the more annoying bug are random freezes and reboots (the mce bug).

            Comment


            • #86
              Originally posted by debianxfce View Post
              Michael and other beginners, it is easy to make software that segfaults intel cpus too. Did not Amd send you enough cpus and gpus for free...
              Lisa Su re-login please.

              Comment


              • #87
                Originally posted by debianxfce View Post
                Michael and other beginners, it is easy to make software that segfaults intel cpus too. Did not Amd send you enough cpus and gpus for free...
                Haha. That would be nice, but it isn't the truth. AMD has sent some review samples to Michael, but for the most part he has had to purchase the products he benches here. He would tell you that himself. If you add up the value of all his AMD products from the time they were acquired by him, then the value of the products he paid for is much higher than the value of the products he got from board partners and AMD.

                Comment


                • #88
                  As I already posted in the other thread, I used to see this bug with the original BIOS while doing kernel compilation and video encoding. However, since the last BIOS update (that contains AGESA 1.0.0.6a), I do not see it anymore. This is on Prime X370-Pro from ASUS w/ R7 1800X. Just for the hell of it I ran the test today for hours and I cannot make it fail. Perhaps this is buggy BIOS on some motherboards or perhaps something with voltages?

                  Comment


                  • #89
                    Originally posted by puleglot View Post
                    AFAIK conftest segfaults are pretty normal. You probably should count only segfaults of bash, gcc itself, etc..
                    Normal? Why? Can you explain that? How to avoid them?

                    Comment


                    • #90
                      Originally posted by Silverthorn View Post
                      I really hate that bug and it's super annoying when it happens. If you happen to sit by the computer while it happens you're usually able to move the cursor around, but that's about the only thing you can do except doing a hard reboot. The sad part is I've seen something similar happen on an old Intel system where it started with Firefox suddenly going to 100% activity and the process was completely unstoppable (zombie process). After a while the system got really unstable and then it became completely unresponsive. It never happened with the LTS of Ubuntu which the system was recently updated from.
                      This sounds exactly like what happened to me on Gentoo but not Fedora until I enabled config_rcu_nocb_cpu_all in my kernel. I checked Debian and they do not enable this so I tried it and sure enough it froze just the same. My system has been stable for months now but I haven't had anyone else confirm this fix/workaround yet.

                      Comment

                      Working...
                      X