• 6.9.0-rc2 AMD 3400G iGPU not working


    adams95
    • Closed

    I have enabled amdgpu support by creating the file /boot/config/modprobe.d/amdgpu.conf. The issue that I have noticed is that while lsmod shows amdgpu as loaded, I have no folder /dev/dri. Additionally, Unraid will not work in GUI mode. With a screen attached and booting in GUI mode, it hangs at: vfio-pci 0000:08:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem, decodes=io+mem:owns=none

    My understanding of this is that the system has not actually hung, it is just the graphics output no longer functioning. The webui remains accessible at this point. 

    marvin-diagnostics-20210209-2345.zip




    User Feedback

    Recommended Comments

    I have a server with a Ryzen APU. I'm not in a position to reboot it at the moment because it's busy but if I load the amdgpu module manually I get a /dev/dri folder:

     

    root@Pusok:~# ls -lR /dev/dri
    /bin/ls: cannot access '/dev/dri': No such file or directory
    root@Pusok:~# modprobe amdgpu
    root@Pusok:~# ls -lR /dev/dri
    /dev/dri:
    total 0
    drwxr-xr-x 2 root root        80 Feb  9 20:38 by-path/
    crw-rw---- 1 root video 226,   0 Feb  9 20:38 card0
    crw-rw---- 1 root video 226, 128 Feb  9 20:38 renderD128
    
    /dev/dri/by-path:
    total 0
    lrwxrwxrwx 1 root root  8 Feb  9 20:38 pci-0000:09:00.0-card -> ../card0
    lrwxrwxrwx 1 root root 13 Feb  9 20:38 pci-0000:09:00.0-render -> ../renderD128
    root@Pusok:~# lspci | grep 09:00.0
    09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev cb)
    root@Pusok:~# 

     

    It usually runs headless but I'll do some tests with GUI mode when I get an opportunity.

     

    • Like 1
    Link to comment

    Thanks for the help. This is my output from the same command (also running headless, I had previously just booted in GUI mode with a display for testing purposes).

     

    root@Marvin:~# ls -lR /dev/dri
    /bin/ls: cannot access '/dev/dri': No such file or directory
    root@Marvin:~# modprobe amdgpu
    root@Marvin:~# ls -lR /dev/dri
    /bin/ls: cannot access '/dev/dri': No such file or directory
    root@Marvin:~# lsmod | grep amdgpu
    amdgpu               4308992  0
    gpu_sched              20480  1 amdgpu
    i2c_algo_bit           16384  1 amdgpu
    drm_kms_helper        163840  1 amdgpu
    ttm                    73728  1 amdgpu
    drm                   356352  4 gpu_sched,drm_kms_helper,amdgpu,ttm
    backlight              16384  3 video,amdgpu,drm
    i2c_core               45056  5 drm_kms_helper,i2c_algo_bit,amdgpu,i2c_piix4,drm
    root@Marvin:~# 

     

    EDIT: Closing this report as it was my own mistake, not an unraid bug. I previously had my IOMMU group containing the APU bound to VFIO at boot, and had forgotten to disable this. 

    Edited by adams95
    Updating information and avoiding double post
    Link to comment
    11 minutes ago, adams95 said:

    I previously had my IOMMU group containing the APU bound to VFIO at boot, and had forgotten to disable this. 

     

    As a matter of great interest, you presumably did that in an attempt to pass the GPU through to a VM? Did you have any success? I haven't and I don't think it's possible but I'd be happy to be proved wrong!

     

    As another matter of great interest :) have you found a docker container that can actually make use of the Radeon Vega's video encode/decode or compute capability? I know that the Linux version of Plex isn't built to make use of it and therefore the dockerized version can't, either. It's recognised as a GPU by the FoldingAtHome container but the necessary OpenCL subsystem isn't included so it can't be used. Maybe a Handbrake container could make use of it?

     

    • Like 1
    Link to comment

    That was what I had been trying but never did manage to get it working, my entire system would crash every time I tried to boot a VM that had the APU attached.

     

    Regarding the docker containers, I had found someone on the Plex forums who had managed to get hardware transcoding working in a plex docker container on a Ryzen 7 4700U APU. Here's the link to the thread. I've just installed their fork of the linuxserver.io plex docker container and HW transcoding isn't immediately working for me, but I do get a response when I run vainfo from the docker container console. 

     

    Also, when I previously built the Unraid kernel with amdgpu support before it was officially supported, I manage to get hardware transcoding working in the linuxserver emby container, but didn't continue down this path due to VOBSUB subtitles forcing transcoding within Emby on a lot of my media. Hope this info is helpful. 

    • Like 1
    Link to comment
    12 minutes ago, adams95 said:

    my entire system would crash every time I tried to boot a VM that had the APU attached.

     

    That was my experience too. Thanks for the info - I'll do some reading.

     

    Link to comment

    For a while I feared it would only work with Renoir APUs but I have success with a mere Athlon 200GE (Raven Ridge).

     

    7792928_ScreenShot2021-02-12at14_29_21.png.0d757f9de61caa6ec811468068467932.png

     

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.