Announcement

Collapse
No announcement yet.

AGESA 1.0.0.6b Might Fix The Ryzen Linux Performance Marginality Problem

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

  • #31
    Unfortunately for me and my Biostar board, I don't think I'll be getting this update for another month or two, if ever. But, though my CPU is affected by this problem, it overall seems to have no impact on my regular workload. It takes tens of minutes for the segfaults to occur, and there is nothing I compile that takes that long. I currently am unaware of anything else that triggers this problem.

    Originally posted by plasmasnake View Post
    It didn't fix it for me, on an ASRock X370 Killer SLI... Even after cranking up the Vcore and SoC voltage like AMD tech support asked me to. Tech support asked me to crank Vcore up to 1.42V (seriously?), but I stopped at 1.375V since the CPU was already running 15 degrees hotter, and BIOS was giving red warning text if I went any higher. Hopefully the RMA gets approved and the replacement CPU resolves the issue... I wasn't very appreciative of the "debugging" steps that AMD tech support made me go through, considering that this is a known problem.
    Was it ASRock telling you to crank the Vcore to 1.42 or AMD? Because I really have a hard time believing AMD would tell you to do such a thing, considering (from my recollection) they recommend people stay below 1.35v. On the other hand, if AMD obliges RMAs to OC'd CPUs, they probably realize "well, this CPU is defective and we're never going to be able to re-sell it, so we might as well tell customers to push the limits".

    Comment


    • #32
      Gigabyte should fix booting problems first on AB350 Gaming 3. Currently my setup will not boot Fedora on anything newer than F4 BIOS (there is now F5 and F6 with AGESA 1.0.0.6a). I need to check Fedora install media if that doesn't work either and report this (to Red Hat, since Gigabyte doesn't care). The problem is that with newer bios Grub works fine, Fedora starts to boot but after a little while the screen becomes white, then black and the CPU fan speeds up. It will not recover without resetting (e.g. pressing reset button). I said about this to Gigabyte support, but they just replied that they don't support Linux.

      Comment


      • #33
        Originally posted by Tomin View Post
        Gigabyte should fix booting problems first on AB350 Gaming 3. ... I said about this to Gigabyte support, but they just replied that they don't support Linux.
        This means that I won't be buying Gygabyte anymore then, I have been buying their boards for years.

        Vote with your wallet.

        Comment


        • #34
          Originally posted by JPFSanders View Post

          This means that I won't be buying Gygabyte anymore then, I have been buying their boards for years.

          Vote with your wallet.
          k7 of mine and the b350 gaming(friends) has been flawless tbh, swings and roundabouts I guess on all vendors

          Comment


          • #35
            the new msi bioses have updated CPU microcode: version 8001129 (was 8001126). didn't fix the segfaults, though.

            Comment


            • #36
              Ran the ryzen-test and mprime, individually and together for at least 30 minutes, before and after AGESA 1.0.0.6b on ASRock Fatal1ty AB350 Gaming-ITX/ac with 1700. Never got a segment fault but the BIOS update did fix stability issues. System still ran smooth while running both tests together after the update.

              Originally had an issue loading a VirtualBox export off a USB stick before the update, which took an excessive amount on time with USB 3.0. VirtualBox stated everything was successful but OS never booted. Had to first copy the export to a local a SATA drive so it would import uncorrupted.

              Comment


              • #37
                I would recommend shying away from gigabyte motherboards for linux support. Gigabyte doesn't seem to care about linux and the linux community had to work around an gpio issue with some of their ryzen motherboards.
                [Impact] Gigabyte AM4 boards users cannot boot Ubuntu successfully. Commit linux-gpio/fixes babdc22b0ccf4ef5a3075ce6e4afc26b7a279faf "pinctrl/amd: Use regular interrupt instead of chained" can fix the issue. [Test Case] All Gigabyte AM4 boards can reproduce the issue. With the patch, the issue is resolved, per comment #170. [Regression Potential] Regression Potential is low. It limits to rather new AMD platform which has pinctrl-amd. As the commit log says, use chained interrupt is not a...


                Basically all they could do was make the code more robust so that when this stuff blew up, the kernel was able to recover.


                Comment


                • #38
                  Originally posted by schmidtbag View Post
                  Was it ASRock telling you to crank the Vcore to 1.42 or AMD? Because I really have a hard time believing AMD would tell you to do such a thing, considering (from my recollection) they recommend people stay below 1.35v.
                  It was AMD. And 24/7 safe voltage is supposed to be 1.45 not 1.35. 1.35 is default for "X" chips.
                  AFAIK 1006b does not fix segfaults only minor changes were done.
                  For ASUS C6H users:

                  1601/1602 coming online soon but nothing too exciting, updated AGESA 1006b but no major improvements.
                  We're waiting for 1007 before next release here, which would include the improvements in 9920.
                  Anyway I mailed AMD and got my RMA number - I'll be sending my chip back soon.

                  P.S.
                  AMD should work on better PR. They do not bother to publish what given AGESA version brings. Full BKDG RYZEN documentation is still a secret....

                  Comment


                  • #39
                    Originally posted by schmidtbag View Post
                    Unfortunately for me and my Biostar board, I don't think I'll be getting this update for another month or two, if ever. But, though my CPU is affected by this problem, it overall seems to have no impact on my regular workload. It takes tens of minutes for the segfaults to occur, and there is nothing I compile that takes that long. I currently am unaware of anything else that triggers this problem.


                    Was it ASRock telling you to crank the Vcore to 1.42 or AMD? Because I really have a hard time believing AMD would tell you to do such a thing, considering (from my recollection) they recommend people stay below 1.35v. On the other hand, if AMD obliges RMAs to OC'd CPUs, they probably realize "well, this CPU is defective and we're never going to be able to re-sell it, so we might as well tell customers to push the limits".
                    Well they actually do ask you to go that high.
                    For me it was "up to a maximum of 1.425V (but not going over)".
                    Still did not help so RMA it is.

                    Comment


                    • #40
                      Originally posted by JPFSanders View Post

                      This means that I won't be buying Gygabyte anymore then, I have been buying their boards for years.

                      Vote with your wallet.
                      Is there any brand that openly supports linux on consumer hardware and will actually care about linux-related issues on their hardware?

                      That said, Gigabyte is in my blacklist because they make a zillion of revisions, and they happen to cut off features, and this is a pain to find out since most sellers don't have any idea of the board revision of their hardware at all.

                      Comment

                      Working...
                      X