Announcement

Collapse
No announcement yet.

AMD To Restore Retry Faults Behavior To Help With Raven Stability

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

  • AMD To Restore Retry Faults Behavior To Help With Raven Stability

    Phoronix: AMD To Restore Retry Faults Behavior To Help With Raven Stability

    Last week I reported on a possible workaround for helping AMD APUs with stability issues on recent Linux kernels. That behavior will now be the new temporary default in dealing with stability issues on Raven APUs...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Good that someone noticed there are problems with the APU's. I'm affected and have to run the VESA driver with recent kernels =(.

    Comment


    • #3
      I'm the guy who bisected the issue. This would be my first kernel bisect and I guess my first real contribution to the kernel. I actually feel happy to see it helped a bunch of people.

      I was already used to compiling the kernel and applying patches but there are a couple of important things I learned while bisecting (drm-tip in particular).
      * I found this amazing thing: https://wiki.archlinux.org/index.php/Modprobed-db . Especially when compiling with just my measly quad core APU it's what made bisecting a practical thing to do for me (done in about a weekend).
      * Arch's kernel build system is pretty great and is able to do preserve build files and do incremental builds even when changing the commit in the PKGBUILD.
      * I should probably learn how to use git bisect. I was manually logging the commits in text files which, though admittedly effective, doesn't help with working through the git commit logs. In the middle of the process, I learned that github's commit log view isn't actually strictly ordered according to how it is in git. I also noticed some weird duplication of commits with different dates, and along the bad ordering these threw me off with having bad "older" commits and good "newer" ones. I settled on using git log to display the range of commits I needed.
      * Please don't bisect with an f2fs filesystem . Somehow even when disabling fsck in /etc/fstab it still does a disk check every time the kernel changes. This wasted me about a minute on each run.
      * Have a boot USB ready. I encountered an issue where grub didn't boot. Possibly the UEFI entries where somehow wiped out. arch-chroot to the rescue.
      * For issues like this one where it takes some chance to hit, find first a very reliable way of triggering it (probably >90% confidence). Halfway through I got the feeling that my method of just using Firefox with webrender and some webgl stress tests may not actually be enough. Then I opened steam and it's probably the store's huge canvases and galleries of images in its winter sale that made it such a reliable trigger. I retried my previously marked "good" commits and it turns out they weren't so good at all.

      I think that's all there is to it for now. I wish I could do more hacking on the actual sources but I'm just a lowly gamedev
      Last edited by mwgarcia; 07 January 2020, 09:36 AM.

      Comment


      • #4
        Originally posted by mwgarcia View Post
        I'm the guy who bisected the issue. This would be my first kernel bisect and I guess my first real contribution to the kernel. I actually feel happy to see it helped a bunch of people.
        Thanks for spending the time tracking this down.. I know how frustrating it can be when issues like this get I'm the way of either life or work.. But it does at least sound like you learned a bit in the process and it sounds like you're happy with the outcome.

        ​​​​​​It's good to know that the community can help out AMDs devs on issues like this. It's what makes the open source community so powerful, and it's why my next laptop will hopefully be one of those new Renoir APUs that we're just announced, as soon as a decent one is on sale.

        Comment


        • #5
          I never experienced this with a Ryzen 2200G + ASRock B450M Pro4 (firmware 3.60). I guess I'm on the lucky side.

          Comment


          • #6
            Originally posted by mwgarcia View Post
            I'm the guy who bisected the issue. This would be my first kernel bisect and I guess my first real contribution to the kernel. I actually feel happy to see it helped a bunch of people.
            Well you certainly helped me and I'd already submitted a bug report to the kernel maintainer of distro I use. The time you spent saved me a lot of grief and saved a lot of other people's time. You also brought it to the attention of AMD so thank you for all your work and effort.

            Comment


            • #7
              Originally posted by mwgarcia View Post
              * I should probably learn how to use git bisect. I was manually logging the commits in text files which, though admittedly effective, doesn't help with working through the git commit logs.
              You should honestly just type "git bissect" and follow the instructions, git holds your hand all the way

              Thank you for spending time on this, and for your post!

              Comment


              • #8
                Will it help to mention the ATOM BIOS model i.e. ATOM BIOS: 113-RAVEN-112 from dmesg? The bug seems affecting some Raven Ridge model.

                Comment


                • #9
                  Originally posted by M@yeulC View Post
                  You should honestly just type "git bissect" and follow the instructions, git holds your hand all the way
                  I can certainly echo that. The very first time I used git was to bisect the kernel!

                  Comment

                  Working...
                  X