Announcement

Collapse
No announcement yet.

The Strange Behavior Of My Radeon R9 290 Is Still There

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

  • #11
    Originally posted by Michael View Post

    Keep in mind it performs well on Linux 4.6 and older, other minority of R9 290/390 owners have also still have this issue outstanding, and if using AMDGPU-PRO this R9 290 does work fine.
    I wonder if you're experiencing the same DPM-related bug reported here: https://bugs.freedesktop.org/show_bug.cgi?id=98988

    To test it, delete /lib/firmware/radeon/hawaii_uvd.bin, and then re-install your kernel .deb files. You need to do the reinstall, because then it will rebuild initrd, where the firmware file is cached, and you'll receive a warning that the firmware file is missing.

    After you reboot, you'll see an error in your dmesg saying that the hawaii_uvd.bin file wasn't found (this was added in 4.7), and it will fall back to the old HAWAII_uvd.bin file.

    Comment


    • #12
      Michael,
      Did you try running some tests in Windows? A few years back I had a misbehaving GPU that I just chalked up to poor Linux drivers. Before the year warrantee was up I finally installed Windows and sure enough I was having the same problems there. RMA'd it and all my problems went away.

      At a minimum, have you tried going back to old kernel? Does the performance come back?
      Last edited by slacka; 18 December 2016, 02:58 PM.

      Comment


      • #13
        But what's rather strange is that after either a certain operation with GpuTest, length of time, or other internal change, the Radeon R9 290 was back to running fast for the remainder of the automated OpenGL benchmarks:
        Now that is seriously weird. Thanks for noting that; there's a chance it might be a clue re: why this doesn't reproduce easily.

        I'm thinking that there has to be more to this than just kernel driver since the problem does not show on AMDGPU-PRO - maybe X driver or microcode. Given what you have seen, presumably it would be fast on stock Ubuntu 16.04 but slow on 16.10 ?

        EDIT - when I clicked to the OpenBenchmarking page I noticed there were two different X drivers used - modesetting 1.18.4 and amdgpu 1.2.99. Was that a "some cards used one driver, the rest used the other" split or is there any chance the X driver changed between tests ?

        OpenBenchmarking.org, Phoronix Test Suite, Linux benchmarking, automated benchmarking, benchmarking results, benchmarking repository, open source benchmarking, benchmarking test profiles
        Last edited by bridgman; 18 December 2016, 03:55 PM.
        Test signature

        Comment


        • #14
          This is going to be a dumb question, but have you tried setting your power settings to performance? Ubuntu defaults to powersave and it may not be attempting to clock it properly.

          Comment


          • #15
            my 290 doesn't have any issues

            Comment


            • #16
              Originally posted by bridgman View Post
              Now that is seriously weird. Thanks for noting that; there's a chance it might be a clue re: why this doesn't reproduce easily.
              Yes... Same thing here on my R7 260X. Sometimes it would just start working fine after a suspend/resume cycle.


              Originally posted by bridgman View Post
              I'm thinking that there has to be more to this than just kernel driver since the problem does not show on AMDGPU-PRO - maybe X driver or microcode.
              In my case, I'm 100% sure it's the microcode. Because I'm running 4.9 and when I force it to use the old microcode, it works fine: https://bugs.freedesktop.org/show_bug.cgi?id=98988

              Comment


              • #17
                Michael just post the card to AMD.. @bridgm

                Comment


                • #18
                  Originally posted by plasmasnake View Post

                  I wonder if you're experiencing the same DPM-related bug reported here: https://bugs.freedesktop.org/show_bug.cgi?id=98988

                  To test it, delete /lib/firmware/radeon/hawaii_uvd.bin,
                  hawaii_uvd.bin is only used by the amdgpu kernel driver. With the radeon kernel driver, one would have to delete bonaire_uvd.bin instead, even with a Hawaii GPU.

                  and then re-install your kernel .deb files. You need to do the reinstall, because then it will rebuild initrd, [...]
                  FWIW, there's no need to re-install the kernel package for that, you can just run "update-initramfs -u -k <kernel version>" to update the initrd.

                  Comment


                  • #19
                    Originally posted by plasmasnake View Post

                    I wonder if you're experiencing the same DPM-related bug reported here: https://bugs.freedesktop.org/show_bug.cgi?id=98988

                    To test it, delete /lib/firmware/radeon/hawaii_uvd.bin, and then re-install your kernel .deb files. You need to do the reinstall, because then it will rebuild initrd, where the firmware file is cached, and you'll receive a warning that the firmware file is missing.

                    After you reboot, you'll see an error in your dmesg saying that the hawaii_uvd.bin file wasn't found (this was added in 4.7), and it will fall back to the old HAWAII_uvd.bin file.
                    GOOD hint!

                    Now, after the starting R7 260X (BONAIRE) there is now a >>> R9 290 <<< with same symptoms _bisected_ to the same commit!

                    @Michael:
                    Please try a quick test (commenting out the bisected commit our delete bonaire_uvd.bin (maybe hawaii_uvd.bin, too to be sure)) before you get in your own 'besecting mode'.

                    Comment


                    • #20
                      Leo Liu (I think that's his name) from AMD posted a firmware blob that fixes the problem for me. On my Mint 18 system, I put it in /lib/firmware/radeon/ and ran "update-initramfs -uk all" (it is crucial that you do this or equivalent on your OS, or the new firmware won't be loaded). It's on the bug report posted earlier (I'm John Brooks): https://bugs.freedesktop.org/show_bug.cgi?id=98988#c3
                      Last edited by Frogging101; 19 December 2016, 01:48 PM.

                      Comment

                      Working...
                      X