Announcement

Collapse
No announcement yet.

AMD RX560 crashing OS under slight load

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

  • AMD RX560 crashing OS under slight load

    Hi everyone, I'm a fellow Linux dude who recently bought a Gigabyte RX560 2GB GPU for my desktop. All nice and dandy on Windows, sadly Linux is...a totally different story.

    At first I tried using in on OpenSUSE Leap and Tumbleweed. I saw my games didn't work, so I said "eh, Debian should have decent gaming support". Then I moved to Kubuntu 17.04 and Kubuntu 16.10 LTS. I really don't know with what to start, but the general bug is the OS crashes when it's under more intensive 3D graphics(and sometimes even 2D). I have no idea what the matter is.

    Things I've tried:

    -I shouldn't use modesetting on AMDGPU drivers, but that sort of worked. Nothing crashed, but boy barely anything rendered.
    -Changing the mobo, thinking that other issues I had with btrfs were connected, and that Gigabyte might have issues, but nope, it wasn't that.
    -Playing with
    Code:
    amd_iommu=on
    and
    Code:
    iommu=pt
    -Padoka PPA. Nope.
    -Can't currently use the AMDGPU-PRO since they don't have proper support for the LTS version of *ubuntu. AMDGPU is already included in the distro, so to speak.
    -Generating a custom Xorg.conf fails, and pops me up with things I barely understand. It gives a Segfault error usually, but I tried using that kilometers long xorg.conf.new file it generates and editing it to work and moving it to /etc/X11/.

    I have one HDMI monitor. One (AMD) CPU. One GPU. One SSD and one HDD, one mobo, and one monkey brain that doesn't help me at all. If you people have any idea how to help me out, I'd be truly thankful from the bottom of my heart. I've wasted 3 weeks of my existence trying to fix this, and although I've been using Linux on my laptop for the past 2 years, I'm truly an idiot in such matters.

    Current xorg.conf bits I added/edited:

    Code:
    Section "Device"
            ### Available Driver options are:-
            ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
            ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
            ### <percent>: "<f>%"
            ### [arg]: arg optional
            Option     "Accel" "true"
            #Option     "SWcursor"               # [<bool>]
            #Option     "EnablePageFlip"         # [<bool>]
            #Option     "SubPixelOrder"          # [<str>]
            #Option     "ZaphodHeads"            # <str>
            Option     "AccelMethod" "glamor"
            Option     "DRI3" "true
            Option     "DRI" "3"
            #Option     "ShadowPrimary"          # [<bool>]
            Option     "TearFree" "true"
            Option     "DeleteUnusedDP12Displays" "true"
        Identifier  "AMD"
        Driver      "amdgpu"
        BusID       "PCI:0:0:0"
    EndSection
    The rest of the file that I took from xorg.conf.new and edited is basically 19 monitor/screen entries, 19 device entries, and a couple other details (mouse, keyboard, etc.).

  • #2
    Originally posted by debianxfce View Post
    You do not need xorg.conf. See the second message how to make it work if you hardware is ok and works ok with win virus hoover.
    https://www.phoronix.com/forums/foru...in-living-room
    Well, it's ironic now. At last I ask for help on a forum, and I finally fix it for myself on Ubuntu.

    Anyways, thanks a lot, and I truly might consider Debian KDE instead of Kubuntu.


    What I did, for future reference:
    -amd_iommu=on + iommu=pt in the GRUB settings and updated GRUB
    -Updated my LTS release
    -Upgraded (took only the nonlatency ones, added all of them in a folder, sudo dpkg -i *, update-initramfs -u -k all) my kernel first at 4.12:

    Then at 4.13 (same procedure):

    However, I noticed that it was missing a kernel module, and I used the one from your link, respectively this place: https://people.freedesktop.org/~agd5...ucode/polaris/
    added it to its respective place, and sudo update-grub && sudo reboot

    Boy, was that a ride. There are still slight glitches here and there, but it works, and I'm thankful as hell. I'll check your link for potential improvements.

    Comment


    • #3
      Originally posted by debianxfce View Post
      Those ubuntu kernels you are using does have partially implemented amdgpu driver, see the diff column at kernel.org and compare to this:
      https://cgit.freedesktop.org/~agd5f/...-next-4.14-wip

      So use above kernel and Oibaf ppa for latest Mesa.
      Ok, you're tempting me. Is it possible to run Debian stable yet have that bleeding-edge kernel? I tried using testing release of Debian a couple days ago, but that ended in a black screen with no way to access console (unless using an older kernel).

      Comment


      • #4
        I recently got an A9-9400 APU (Asus) laptop and under load the system would at some random point become irresponsive except for the mouse (barely), filling my kern.log with these lines:
        Code:
        IOTLB_INV_TIMEOUT device=00:01.0 address=0x000000010c4433c0]
        AMD-Vi: Completion-Wait loop timed out
        WARNING: CPU: 1 PID: 2465 at /home/kernel/COD/linux/drivers/iommu/amd_iommu.c:1256 __domain_flush_pages+0x13a/0x150
        Which additionally caused nasty and scary filesystem corruption. Happened with stock Ubuntu 17.04 4.10 kernel and 4.12 from mainline PPA.

        After adding "amd_iommu=fullflush iommu=pt" to the kernel options about 12 hours ago, crashes seem to have disappeared. Maybe it's not related to your problem, but leaving a note may help other users and it seems that amd_iommu is still not totally bug-free yet? (or is it Asus' BIOS?)
        Last edited by Azultra; 14 August 2017, 06:46 PM.

        Comment


        • #5
          Originally posted by debianxfce View Post
          Do not use iommu.

          What's the deal with IOMMU and AMD/Linux? I, for example, have only USB keyboard/mouse, thus no IOMMU enabled in BIOS means I can't use the keyboard/mouse, usually. Another thing that I understand is that IOMMU may corrupt HDDs/SSDs, if enabled.


          I'm currently running the same Ubuntu build earlier with IOMMU, but if I intend to install Debian and I disable IOMMU in BIOS I simply can't install it, no matter what.


          Are there any circumstances in Linux in which IOMMU use is favorable?

          Comment


          • #6
            Originally posted by Deformat View Post
            thus no IOMMU enabled in BIOS means I can't use the keyboard/mouse, usually.
            Do you mean that enabling IOMMU means you can't use the keyboard mouse, or not enabling it causes the problem ?

            We looked at a few IOMMU-related problems with high speed network cards during ROCm development and found that the driver was instructing the card to perform DMA operations without having first made the proper DMA interface mapping calls (which also set up IOMMU mapping).

            With IOMMU disabled you can often get away with this, but with IOMMU enabled the HW does what it is supposed to and blocks the illegal access, which is a problem if the driver relies on illegal accesses to function.

            If you have drivers which use the kernel DMA subsystem calls correctly then enabling IOMMU gives you a more robust system and eliminates some of the concerns about a rogue device accessing memory it should not be seeing.
            Last edited by bridgman; 19 August 2017, 08:18 PM.
            Test signature

            Comment


            • #7
              Originally posted by bridgman View Post

              Do you mean that enabling IOMMU means you can't use the keyboard mouse, or not enabling it causes the problem ?

              Enabling IOMMU in BIOS means I can use my USB keyboard or USB mouse. Disabling IOMMU means I can not use the keyboard/mouse at all, in any circumstances, whether we talk about the Debian nonfree firmware installer, or we mean about my current Ubuntu installed system.

              I really don't wanna wake up with HDD/SSD being screwed up, as I did wake up in the past few weeks with such issues (granted, on Btrfs, not EXT4). I want this system to work in the long run.

              I am more scared about possible data corruption on my system, rather than my USB not working, since I suppose there are workarounds for that.

              Comment


              • #8
                Originally posted by Deformat View Post
                Enabling IOMMU in BIOS means I can use my USB keyboard or USB mouse. Disabling IOMMU means I can not use the keyboard/mouse at all, in any circumstances, whether we talk about the Debian nonfree firmware installer, or we mean about my current Ubuntu installed system.
                OK, now that is wierd. If anything I would expect enabling IOMMU to prevent USB from working, not make it work.

                My first thought is BIOS bug somewhere, although it would have to be a bit of an odd bug.
                Test signature

                Comment


                • #9
                  Originally posted by bridgman View Post

                  OK, now that is wierd. If anything I would expect enabling IOMMU to prevent USB from working, not make it work.

                  My first thought is BIOS bug somewhere, although it would have to be a bit of an odd bug.
                  Gigabyte GA-970A-UD3P, just for the future reference.

                  Comment


                  • #10
                    Others reported the same problem with IOMMU and USB on this board:


                    http://www.tomshardware.co.uk/answer...ud3p-mobo.html

                    UPD: Similar problem with GA-970A-DS3
                    http://www.linux-hardware-guide.com/...970-socket-am3
                    By default, the board is shipped with IOMMU deactivated in the BIOS. With such settings the USB 3.0 ports work under Linux, but the USB 2.0 and Ethernet are deactivated. If IOMMU is activated, USB 2.0 and Ethernet work under Linux, but the USB 3.0 ports are deactivated.
                    Last edited by puleglot; 24 August 2017, 06:34 PM.

                    Comment

                    Working...
                    X