Announcement

Collapse
No announcement yet.

AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR

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

  • sudo dmidecode | grep -w ID
    cpuid | grep serial
    Last edited by scorpio810; 09 August 2017, 09:05 PM.

    Comment


    • Originally posted by scorpio810 View Post
      sudo dmidecode | grep -w ID
      cpuid | grep serial
      That doesn't produce anything similar to UA1707PGT.

      Comment


      • Gotta pull the Heat sink to see it..

        The Good Ryzen chips people are getting back are 2017 - WEEK25, the ThreadRipper Chips are 2017 - WEEK27

        GoodRyzenChips = UA1725SUS
        ThreadRipper = UA1727SUT

        there might be a lot of "Marginal" ryzen chips older than 1725.

        Comment


        • Yes I know ! but AMD can know BUILD date by cpu serial, i think?
          Malaysia or china chips provenance can play?
          Last edited by scorpio810; 09 August 2017, 09:38 PM.

          Comment


          • Originally posted by bridgman View Post

            Actually the idea is to replace the CPU with one which works as expected, but since we started replacing CPUs while still investigating we didn't always get it right at first.
            So, u mean the earlier batch of ryzen is having hardware bug? and we can only avoid this issue by replacing the CPU to new unit? Is there any recall for ryzen?

            Comment


            • Originally posted by bridgman View Post

              Actually the idea is to replace the CPU with one which works as expected, but since we started replacing CPUs while still investigating we didn't always get it right at first.
              So, u mean the earlier batch of ryzen is having hardware bug? and we can only avoid this issue by replacing the CPU to new unit? is there any recall for ryzen?

              Comment


              • Originally posted by bridgman View Post

                Actually the idea is to replace the CPU with one which works as expected, but since we started replacing CPUs while still investigating we didn't always get it right at first.
                So, u mean the earlier batch of ryzen is having hardware bug? and we can only avoid this issue by replacing the CPU to new unit? is there any recall for ryzen?

                Comment


                • Originally posted by scorpio810 View Post
                  Yes I know ! but AMD can know BUILD date by cpu serial, i think?
                  Malaysia or china chips provenance can play?

                  Comment


                  • I have a Ryzen 5 1500X. Am I right that it should not be affected by this problem?

                    Building Linux 4.13-rc4 on 4.13-rc3, if I use

                    make -j

                    Everything slows down to a lurching crawl and eventually I get a segfault. If instead I do

                    make -j12

                    It works normally with almost no impact on desktop environment usability. Does this sound like plain system instabilty or could it be this bug?

                    BTW I want to add that I updated the BIOS for my Asus ROG Stril B350-F Gaming, which was released a few days ago. This BIOS release included something call CMB (AMD Common BIOS), a whole new set of options which had one option which seemed like it may be GCC-specific. They seemed to be a collection of workarounds and CPU-specific options? What do you guys think?

                    Comment


                    • Originally posted by keantoken View Post
                      Building Linux 4.13-rc4 on 4.13-rc3, if I use

                      make -j

                      Everything slows down to a lurching crawl and eventually I get a segfault. If instead I do

                      make -j12

                      It works normally with almost no impact on desktop environment usability. Does this sound like plain system instabilty or could it be this bug?
                      How much memory do you have and can you see how much memory is being used during the kernel compilation?

                      Compiling a source code as large as the kernel with an unrestrained make -j will spawn not only lots of parallel processes, far more than your CPU has cores, but each process requires memory and you'll probably need 32MB or so. I know 16MB isn't enough for me, but I have to restrain it to a -j64. Once it exceeds the memory limit will it start swapping and this can occasionally lead to kernel panics or oops'es or lock ups. You might find a message in the system log.

                      To reproduce the problem reported here should you use exclusively the Phoronix Test Suite and follow the instructions to reproduce the conditions to trigger it. Otherwise are you only adding more guesses onto this than is really necessary. Stick to what is currently the accepted method for reproducing the issue.

                      Comment

                      Working...
                      X