Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMD Ryzen 7 5800U support #155

Closed
ivan-volnov opened this issue Mar 27, 2022 · 20 comments
Closed

AMD Ryzen 7 5800U support #155

ivan-volnov opened this issue Mar 27, 2022 · 20 comments

Comments

@ivan-volnov
Copy link

Describe the bug
Hi there!

The new Ryzen 7 5800U doesn't work on 13.0-RELEASE with drm-fbsd13-kmod. Hope I will be fixed on 13.1-RELEASE.

Can help with testing and patching but don't want to upgrade the whole system.

FreeBSD version

FreeBSD hostname 13.0-RELEASE-p8 FreeBSD 13.0-RELEASE-p8 #0: Tue Mar 15 09:36:28 UTC 2022     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

PCI Info

pciconf -lv
hostb0@pci0:0:0:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1630 subvendor=0x1022 subdevice=0x1630
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne Root Complex'
    class      = bridge
    subclass   = HOST-PCI
none0@pci0:0:0:2: class=0x080600 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1631 subvendor=0x1022 subdevice=0x1631
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne IOMMU'
    class      = base peripheral
    subclass   = IOMMU
hostb1@pci0:0:1:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1632 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir PCIe Dummy Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib1@pci0:0:1:1: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1633 subvendor=0x1022 subdevice=0x1453
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir PCIe GPP Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:1:3: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1634 subvendor=0x1022 subdevice=0x1453
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne PCIe GPP Bridge'
    class      = bridge
    subclass   = PCI-PCI
hostb2@pci0:0:2:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1632 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir PCIe Dummy Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib3@pci0:0:2:1: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1634 subvendor=0x1022 subdevice=0x1453
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne PCIe GPP Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcib4@pci0:0:2:2: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1634 subvendor=0x1022 subdevice=0x1453
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne PCIe GPP Bridge'
    class      = bridge
    subclass   = PCI-PCI
pcib5@pci0:0:2:3: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1634 subvendor=0x1022 subdevice=0x1453
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne PCIe GPP Bridge'
    class      = bridge
    subclass   = PCI-PCI
hostb3@pci0:0:8:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1632 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir PCIe Dummy Host Bridge'
    class      = bridge
    subclass   = HOST-PCI
pcib6@pci0:0:8:1: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1635 subvendor=0x1022 subdevice=0x1635
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir Internal PCIe GPP Bridge to Bus'
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:0:8:2: class=0x060400 rev=0x00 hdr=0x01 vendor=0x1022 device=0x1635 subvendor=0x1022 subdevice=0x1635
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir Internal PCIe GPP Bridge to Bus'
    class      = bridge
    subclass   = PCI-PCI
intsmb0@pci0:0:20:0: class=0x0c0500 rev=0x51 hdr=0x00 vendor=0x1022 device=0x790b subvendor=0x1022 subdevice=0x790b
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'FCH SMBus Controller'
    class      = serial bus
    subclass   = SMBus
isab0@pci0:0:20:3: class=0x060100 rev=0x51 hdr=0x00 vendor=0x1022 device=0x790e subvendor=0x1022 subdevice=0x790e
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'FCH LPC Bridge'
    class      = bridge
    subclass   = PCI-ISA
hostb4@pci0:0:24:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166a subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 0'
    class      = bridge
    subclass   = HOST-PCI
hostb5@pci0:0:24:1: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166b subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 1'
    class      = bridge
    subclass   = HOST-PCI
hostb6@pci0:0:24:2: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166c subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 2'
    class      = bridge
    subclass   = HOST-PCI
hostb7@pci0:0:24:3: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166d subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 3'
    class      = bridge
    subclass   = HOST-PCI
hostb8@pci0:0:24:4: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166e subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 4'
    class      = bridge
    subclass   = HOST-PCI
hostb9@pci0:0:24:5: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x166f subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 5'
    class      = bridge
    subclass   = HOST-PCI
hostb10@pci0:0:24:6: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1670 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 6'
    class      = bridge
    subclass   = HOST-PCI
hostb11@pci0:0:24:7: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1671 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Cezanne Data Fabric; Function 7'
    class      = bridge
    subclass   = HOST-PCI
nvme0@pci0:1:0:0: class=0x010802 rev=0x01 hdr=0x00 vendor=0x1e4b device=0x1202 subvendor=0x1e4b subdevice=0x1202
    vendor     = 'MAXIO Technology (Hangzhou) Ltd.'
    device     = 'NVMe SSD Controller MAP1202'
    class      = mass storage
    subclass   = NVM
none1@pci0:2:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8125 2.5GbE Controller'
    class      = network
    subclass   = ethernet
re0@pci0:3:0:0: class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
nvme1@pci0:5:0:0: class=0x010802 rev=0x03 hdr=0x00 vendor=0x126f device=0x2263 subvendor=0x126f subdevice=0x2263
    vendor     = 'Silicon Motion, Inc.'
    device     = 'SM2263EN/SM2263XT SSD Controller'
    class      = mass storage
    subclass   = NVM
vgapci0@pci0:6:0:0: class=0x030000 rev=0xc1 hdr=0x00 vendor=0x1002 device=0x1638 subvendor=0x1002 subdevice=0x0123
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Cezanne'
    class      = display
    subclass   = VGA
hdac0@pci0:6:0:1: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1002 device=0x1637 subvendor=0x1002 subdevice=0x1637
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Renoir Radeon High Definition Audio Controller'
    class      = multimedia
    subclass   = HDA
none2@pci0:6:0:2: class=0x108000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15df subvendor=0x1022 subdevice=0x15df
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Family 17h (Models 10h-1fh) Platform Security Processor'
    class      = encrypt/decrypt
xhci0@pci0:6:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1639 subvendor=0x1022 subdevice=0x1639
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne USB 3.1'
    class      = serial bus
    subclass   = USB
xhci1@pci0:6:0:4: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1639 subvendor=0x1022 subdevice=0x1639
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Renoir/Cezanne USB 3.1'
    class      = serial bus
    subclass   = USB
none3@pci0:6:0:5: class=0x048000 rev=0x01 hdr=0x00 vendor=0x1022 device=0x15e2 subvendor=0x1022 subdevice=0x15e2
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Raven/Raven2/FireFlight/Renoir Audio Processor'
    class      = multimedia
hdac1@pci0:6:0:6: class=0x040300 rev=0x00 hdr=0x00 vendor=0x1022 device=0x15e3 subvendor=0x10ec subdevice=0x0000
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'Family 17h (Models 10h-1fh) HD Audio Controller'
    class      = multimedia
    subclass   = HDA
ahci0@pci0:7:0:0: class=0x010601 rev=0x81 hdr=0x00 vendor=0x1022 device=0x7901 subvendor=0x1022 subdevice=0x7901
    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
    device     = 'FCH SATA Controller [AHCI mode]'
    class      = mass storage
    subclass   = SATA

DRM KMOD version

drm-fbsd13-kmod 5.4.144.g20220128
drm-kmod g20190710_1

To Reproduce
Try to launch a wayland DM dwl:

❯ dwl
00:00:10.505 [backend/backend.c:217] Found 0 GPUs, cannot create backend
00:00:10.505 [backend/backend.c:386] Failed to open any DRM device
couldn't create backend

Additional context

Found here a tread about the Cezanne core cpu. They say that drm-devel-kmod can be built on 13.1-BETA1, but Xorg 1.20.14 (also 1.20.13) crashes while accessing amdgpu.

@neelchauhan
Copy link
Contributor

You need a newer version of drm-kmod. 13.0 won't work, but 13.1 can if you use 5.7 or newer.

@ivan-volnov
Copy link
Author

ivan-volnov commented Apr 13, 2022

Ok. Thanks. Switched to 13.1-RC1 (RC2 now) and installed drm-devel-kmod from ports. Works pretty well. Although there is no GPU accelerated video.

The only thing i have changed in /boot/loader.conf is hw.vga.textmode=1 to set booting fonts.

I also get this line in the logs:

amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.
If they do, bad things may happen!

Can I fix it somehow?

@pointcheck
Copy link

Xorg 1.20.14 still does not work on Cezenne CPUs, it crashes while, presumably, accessing AMDGPU. Also GPU offloading to NVIDIA does not work, I fail to make it detect more than one providers.

Using FreeBSD 13.1-RC1, drm-devel-kmod 5.7.19.g20220223, NVIDIA driver 510.60.02.

[drm] initializing kernel modesetting (RENOIR 0x1002:0x1638 0x17AA:0x3A5D 0xC6).
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 510.60.02 Wed Mar 16 11:03:12 UTC 2022

@ivan-volnov
Copy link
Author

ivan-volnov commented Apr 29, 2022

Updated to FreeBSD 13.1-RC5. And added a second monitor via DP.

I experience reboots on the DP monitor start.

  • On driver load during reboot
  • On wayland session create
  • On wake up from sleep

Some of dmesg hope it helps:

VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1440 width=2560 depth=32
pbase=0x1010c8d000 vbase=0xfffff81010c8d000
name=drmn0 flags=0x0 stride=10240 bpp=32
end FB_INFO
drmn0: ring gfx uses VM inv eng 0 on hub 0
drmn0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
drmn0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
drmn0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
drmn0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
drmn0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
drmn0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
drmn0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
drmn0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
drmn0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
drmn0: ring sdma0 uses VM inv eng 0 on hub 1
drmn0: ring vcn_dec uses VM inv eng 1 on hub 1
drmn0: ring vcn_enc0 uses VM inv eng 4 on hub 1
drmn0: ring vcn_enc1 uses VM inv eng 5 on hub 1
drmn0: ring jpeg_dec uses VM inv eng 6 on hub 1
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134AOD.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
driver bug: Unable to set devclass (class: ppc devname: (unknown))
intsmb0: <AMD FCH SMBus Controller> at device 20.0 on pci0
smbus0: <System Management Bus> on intsmb0
lo0: link state changed to UP
re0: link state changed to DOWN
uhid0 on uhub1
uhid0: <vendor 0x0c45 FC660M, class 0/0, rev 2.00/0.01, addr 1> on usbus1
ums0 on uhub1
ums0: <ROCCAT ROCCAT Kone Pure Military, class 0/0, rev 2.00/2.00, addr 2> on usbus1
ums0: 5 buttons and [XYZT] coordinates ID=1
pflog0: promiscuous mode enabled
re0: link state changed to UP
Security policy loaded: MAC/ntpd (mac_ntpd)
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring sdma0
[drm ERROR :drm_atomic_helper_wait_for_flip_done] [CRTC:62:crtc-3] flip_done timed out
[drm ERROR :drm_atomic_helper_wait_for_flip_done] [CRTC:62:crtc-3] flip_done timed out
WARNING atomic_read(&vblank->refcount) == 0 failed at /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/drm_vblank.c:1143
[drm] Fence fallback timer expired on ring gfx
[drm] Fence fallback timer expired on ring gfx

@xmhd
Copy link

xmhd commented May 4, 2022

I have a 5850u (which is the same cpu, just the 'pro' version) and it is working nicely (with gpu acceleration) on 14.0-CURRENT from April 7th 2022 along with drm-devel-kmod.

This morning I tried 13.1-RC5 and drm-510-kmod, which unfortunately do not work. I am able to 'kldload amdgpu' which compared to the same command on the aforementioned working setup, but doesn't seem to load the module properly -- when I load the module on 14.0-CURRENT, I see a decent amount of information output. On 13.1-RC5 I see the following info output:

isab1: <PCI-ISA bridge> at device 20.3 on pci0
device_attach: isab1 attach returned 6
<6>[drm] amdgpu kernel modesetting enabled

And when running 'startx' afterwards, the xorg server does not start.

edit: I have also observed the xf86-video-amdgpu 2d driver providing a significantly smoother experience than the modesetting driver that is part of xorg-server.

edit2: I was able to build drm-devel-kmod port on 13.1-RC5 and the 'amdgpu' module loads correctly. However I have now found that I am unable to move the mouse cursor (key input still works). I'm assuming this is i2c related and specific to my thinkpad x13 gen 2 (it works in 14.0-CURRENT).

edit3: drm-54-kmod does not work on 13.1-RC5 either.

tldr; the moral of this is:

  • if you need amd cezanne support, then drm-devel-kmod (5.7.x) will work
  • drm-510-kmod and drm-54-kmod likely do not work at this point in time

@xmhd
Copy link

xmhd commented May 6, 2022

so I done some digging and found the following missing pieces:

  • firmware for 5000 series/cezanne is currently missing, see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263793
  • however, as cezanne is a modified renoir, they work (mostly) with renoir firmware ...
  • drm-devel-kmod (v5.7) which works for my 5850u has the following commit adding the relevant device ID's 44a2eaf
  • v5.4 and v5.4 do not have these device ID's added

I will test this out and report back.

@wulf7
Copy link
Contributor

wulf7 commented May 6, 2022

Try to build recently created 5.10-lts branch from sources. It includes upstream support for all these Renoir chips.
But I am not sure if we have all required firmwares in gpu-firmware-kmod port now or not.

@xmhd
Copy link

xmhd commented May 6, 2022

I will try that @wulf7 thanks for the advice

@pointcheck
Copy link

Hi all.

I have just tried 5.10-lts, it does not load on Cezanne CPU at all, reports 'amdgpu/green_sardine_sdma.bin' is missing, see my dmesg output below. So, 5.7-stable branch is the only that loads but still does not work - Xorg crashes at AMDGPU access.

I have been investigating this issue for quite some time and came to conclusion that the problem is not in DRM driver, neither in Xorg, but in /lib/libthr.so.3 or even in /lib/libc.so.7 library which comes with FreeBSD/LLVM. In other words it is a bug in FreeBSD.

drmn1: on vgapci1
vgapci1: child drmn1 requested pci_enable_io
vgapci1: child drmn1 requested pci_enable_io
[drm] initializing kernel modesetting (RENOIR 0x1002:0x1638 0x17AA:0x3A5D 0xC6).
drmn1: Trusted Memory Zone (TMZ) feature disabled as experimental (default)
[drm] register mmio base: 0xD1400000
[drm] register mmio size: 524288
[drm] add ip block number 0 <soc15_common>
[drm] add ip block number 1 <gmc_v9_0>
[drm] add ip block number 2 <vega10_ih>
[drm] add ip block number 3
[drm] add ip block number 4
[drm] add ip block number 5 <gfx_v9_0>
[drm] add ip block number 6 <sdma_v4_0>
[drm] add ip block number 7
[drm] add ip block number 8 <vcn_v2_0>
[drm] add ip block number 9 <jpeg_v2_0>
drmn1: Fetched VBIOS from VFCT
drmn1: could not load firmware image 'amdgpu/green_sardine_sdma.bin'
[drm ERROR :sdma_v4_0_init_microcode] sdma_v4_0: Failed to load firmware "amdgpu/green_sardine_sdma.bin"
[drm ERROR :sdma_v4_0_early_init] Failed to load sdma firmware!
[drm] VCN decode is enabled in VM mode
[drm] VCN encode is enabled in VM mode
[drm] JPEG decode is enabled in VM mode
[drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
drmn1: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used)
drmn1: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
drmn1: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
[drm] Detected VRAM RAM=4096M, BAR=4096M
[drm] RAM width 128bits DDR4
[drm] amdgpu: 4096M of VRAM memory ready
[drm] amdgpu: 4096M of GTT memory ready.
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] PCIE GART of 1024M enabled (table at 0x000000F400900000).
drmn1: could not load firmware image 'amdgpu/green_sardine_asd.bin'
drmn1: fail to initialize asd microcode
[drm ERROR :psp_sw_init] Failed to load psp firmware!
[drm ERROR :amdgpu_device_ip_init] sw_init of IP block failed -2
drmn1: amdgpu_device_ip_init failed
drmn1: Fatal error during GPU init
drmn1: amdgpu: finishing device.
[drm] amdgpu: ttm finalized
device_attach: drmn1 attach returned 2

@xmhd
Copy link

xmhd commented May 6, 2022

Hi all.

I have just tried 5.10-lts, it does not load on Cezanne CPU at all, reports 'amdgpu/green_sardine_sdma.bin' is missing, see my dmesg output below. So, 5.7-stable branch is the only that loads but still does not work - Xorg crashes at AMDGPU access.

I have been investigating this issue for quite some time and came to conclusion that the problem is not in DRM driver, neither in Xorg, but in /lib/libthr.so.3 or even in /lib/libc.so.7 library which comes with FreeBSD/LLVM. In other words it is a bug in FreeBSD.

drmn1: on vgapci1 vgapci1: child drmn1 requested pci_enable_io vgapci1: child drmn1 requested pci_enable_io [drm] initializing kernel modesetting (RENOIR 0x1002:0x1638 0x17AA:0x3A5D 0xC6). drmn1: Trusted Memory Zone (TMZ) feature disabled as experimental (default) [drm] register mmio base: 0xD1400000 [drm] register mmio size: 524288 [drm] add ip block number 0 <soc15_common> [drm] add ip block number 1 <gmc_v9_0> [drm] add ip block number 2 <vega10_ih> [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 <gfx_v9_0> [drm] add ip block number 6 <sdma_v4_0> [drm] add ip block number 7 [drm] add ip block number 8 <vcn_v2_0> [drm] add ip block number 9 <jpeg_v2_0> drmn1: Fetched VBIOS from VFCT drmn1: could not load firmware image 'amdgpu/green_sardine_sdma.bin' [drm ERROR :sdma_v4_0_init_microcode] sdma_v4_0: Failed to load firmware "amdgpu/green_sardine_sdma.bin" [drm ERROR :sdma_v4_0_early_init] Failed to load sdma firmware! [drm] VCN decode is enabled in VM mode [drm] VCN encode is enabled in VM mode [drm] JPEG decode is enabled in VM mode [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit drmn1: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used) drmn1: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF drmn1: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF [drm] Detected VRAM RAM=4096M, BAR=4096M [drm] RAM width 128bits DDR4 [drm] amdgpu: 4096M of VRAM memory ready [drm] amdgpu: 4096M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] PCIE GART of 1024M enabled (table at 0x000000F400900000). drmn1: could not load firmware image 'amdgpu/green_sardine_asd.bin' drmn1: fail to initialize asd microcode [drm ERROR :psp_sw_init] Failed to load psp firmware! [drm ERROR :amdgpu_device_ip_init] sw_init of IP block failed -2 drmn1: amdgpu_device_ip_init failed drmn1: Fatal error during GPU init drmn1: amdgpu: finishing device. [drm] amdgpu: ttm finalized device_attach: drmn1 attach returned 2

Yes, even with the green sardine firmware missing the driver should still work (to a certain extent) with the renoir firmware as it had been doing so with the 5.7 branch.

I had last tested 5.7 branch with 14.0-CURRENT with the April 6th release of install media. So if it is broken in FreeBSD as you say, the change has happened somewhere in that time.

I did have the same outcome as you re: 5.10-lts branch though.

@pointcheck
Copy link

Can you please show me your Xorg.0.log as well as /etc/X11/xorg.conf ? Thanks.

I have installed missing green_sardine firmware manually from /usr/ports/graphics/gpu-firmware-kmod/ (strangely it's just missing in Makefile), now 5.10-lts driver loads ok, modesetting works, yet same issue with Xorg using amdgpu.

@xmhd
Copy link

xmhd commented May 6, 2022

Can you please show me your Xorg.0.log as well as /etc/X11/xorg.conf ? Thanks.

I have installed missing green_sardine firmware manually from /usr/ports/graphics/gpu-firmware-kmod/ (strangely it's just missing in Makefile), now 5.10-lts driver loads ok, modesetting works, yet same issue with Xorg using amdgpu.

I can try that tonight. If you don't mind, can you please provide the changes that you made?

I was looking at adding the firmware files to gpu-firmware-amd-kmod which doesn't look too difficult. But if we're debugging this and trying to come to the same outcome, I would prefer we follow the same steps.

@pointcheck
Copy link

pointcheck commented May 6, 2022

I did not do any changes. I just installed missing firmware from their resting directories:

# cd /usr/ports/graphics/gpu-firmware-kmod && make install

# ls -d /usr/ports/graphics/gpu-firmware-kmod/work/drm-kmod-firmware-*/amdgpukmsfw/green_sardine_* | xargs -I % /bin/sh -c '(cd %; make install)'

@xmhd
Copy link

xmhd commented May 7, 2022

I did not do any changes. I just installed missing firmware from their resting directories:

# cd /usr/ports/graphics/gpu-firmware-kmod && make install

# ls -d /usr/ports/graphics/gpu-firmware-kmod/work/drm-kmod-firmware-*/amdgpukmsfw/green_sardine_* | xargs -I % /bin/sh -c '(cd %; make install)'

I wasn't able to replicate an install of green_sardine_* firmware files with this method, sorry. While I have some experience with the amdgpu driver, my experience with drm-kmod + gpu-firmware-kmod is limited :-)

I would imagine that xf86-video-amdgpu being stuck at version 19.x is the reason behind the crashing that you are experiencing.

@ivan-volnov
Copy link
Author

Hi there!

Can anybody add a pull request to https://github.com/freebsd/drm-kmod-firmware to restore green_sardine support?

I opened an issue freebsd/drm-kmod-firmware#21 for that.

@xmhd
Copy link

xmhd commented May 7, 2022

Hi there!

Can anybody add a pull request to https://github.com/freebsd/drm-kmod-firmware to restore green_sardine support?

I opened an issue freebsd/drm-kmod-firmware#21 for that.

I have done so. As mentioned in my PR, the next piece to be added is the relevant bits in the Makefile for the gpu-firmware-kmod port.

@pointcheck
Copy link

I would imagine that xf86-video-amdgpu being stuck at version 19.x is the reason behind the crashing that you are experiencing.

As I said I begin thinking that the problem is not in Xorg/xf86-video-amdgpu per se, but in libc library used in FreeBSD 13. I would like to see if this same issue persists in FreeBSD 14-CURRENT. Can you please send me your Xorg.0.log for investigation ?

@xmhd
Copy link

xmhd commented May 8, 2022

I would imagine that xf86-video-amdgpu being stuck at version 19.x is the reason behind the crashing that you are experiencing.

As I said I begin thinking that the problem is not in Xorg/xf86-video-amdgpu per se, but in libc library used in FreeBSD 13. I would like to see if this same issue persists in FreeBSD 14-CURRENT. Can you please send me your Xorg.0.log for investigation ?

Ok now I see what you're talking about. I tried out the 14.0-CURRENT image from April 14th 2022 and now I experience the same problem, even with v5.7 in use. So the breakage occured somewhere between April 7th and April 14th.

With regards to xorg.conf - I don't change any defaults. The only 'tweaks' I make is to /usr/local/share/X11/xorg.conf.d/10-amdgpu.conf where I enable TearFree for no screen tearing.

@ivan-volnov
Copy link
Author

The firmware is available now.

Updated to 13.1-RELEASE, installed gpu-firmware-amd-kmod-green-sardine and drm-510-kmod. No luck. Described the issue here #167

Can anybody test it also?

@evadot
Copy link
Contributor

evadot commented May 20, 2022

Closing this issue, #167 will track the problem now that we (should) have everything to support this GPU generation.

@evadot evadot closed this as completed May 20, 2022
lutzbichler pushed a commit to lutzbichler/drm-kmod that referenced this issue Feb 7, 2024
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the address of the first
mutex of a given class locked in a sequence.
This has the odd consequence that if that first mutex is unlocked while
other mutexes of the same class remain locked and then its memory then
freed, the lock alloc tracking code will incorrectly assume that memory
is freed with a held lock in there.

For now, work around that for drm_exec by releasing the first grabbed
object lock last.

v2:
- Fix a typo (Danilo Krummrich)
- Reword the commit message a bit.
- Add a Fixes: tag

Related lock alloc tracking warning:
[  322.660067] =========================
[  322.660070] WARNING: held lock freed!
[  322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G     U           N
[  322.660078] -------------------------
[  322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there!
[  322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660104] 2 locks held by kunit_try_catch/4981:
[  322.660108]  #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test]
[  322.660123]  freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660135]
               stack backtrace:
[  322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G     U           N 6.5.0-rc7+ freebsd#155
[  322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[  322.660152] Call Trace:
[  322.660155]  <TASK>
[  322.660158]  dump_stack_lvl+0x57/0x90
[  322.660164]  debug_check_no_locks_freed+0x20b/0x2b0
[  322.660172]  slab_free_freelist_hook+0xa1/0x160
[  322.660179]  ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660186]  __kmem_cache_free+0xb2/0x290
[  322.660192]  drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660200]  drm_exec_fini+0xf/0x1c0 [drm_exec]
[  322.660206]  test_early_put+0x289/0x490 [drm_exec_test]
[  322.660215]  ? __pfx_test_early_put+0x10/0x10 [drm_exec_test]
[  322.660222]  ? __kasan_check_byte+0xf/0x40
[  322.660227]  ? __ksize+0x63/0x140
[  322.660233]  ? drmm_add_final_kfree+0x3e/0xa0 [drm]
[  322.660289]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[  322.660294]  ? lockdep_hardirqs_on+0x7d/0x100
[  322.660301]  ? __pfx_kunit_try_run_case+0x10/0x10 [kunit]
[  322.660310]  ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]
[  322.660319]  kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]
[  322.660328]  kthread+0x2e7/0x3c0
[  322.660334]  ? __pfx_kthread+0x10/0x10
[  322.660339]  ret_from_fork+0x2d/0x70
[  322.660345]  ? __pfx_kthread+0x10/0x10
[  322.660349]  ret_from_fork_asm+0x1b/0x30
[  322.660358]  </TASK>
[  322.660818]     ok 8 test_early_put

Cc: Christian König <christian.koenig@amd.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Danilo Krummrich <dakr@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Danilo Krummrich <dakr@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
wulf7 pushed a commit to wulf7/drm-kmod that referenced this issue Jul 21, 2024
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the address of the first
mutex of a given class locked in a sequence.
This has the odd consequence that if that first mutex is unlocked while
other mutexes of the same class remain locked and then its memory then
freed, the lock alloc tracking code will incorrectly assume that memory
is freed with a held lock in there.

For now, work around that for drm_exec by releasing the first grabbed
object lock last.

v2:
- Fix a typo (Danilo Krummrich)
- Reword the commit message a bit.
- Add a Fixes: tag

Related lock alloc tracking warning:
[  322.660067] =========================
[  322.660070] WARNING: held lock freed!
[  322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G     U           N
[  322.660078] -------------------------
[  322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there!
[  322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660104] 2 locks held by kunit_try_catch/4981:
[  322.660108]  #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test]
[  322.660123]  freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660135]
               stack backtrace:
[  322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G     U           N 6.5.0-rc7+ freebsd#155
[  322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[  322.660152] Call Trace:
[  322.660155]  <TASK>
[  322.660158]  dump_stack_lvl+0x57/0x90
[  322.660164]  debug_check_no_locks_freed+0x20b/0x2b0
[  322.660172]  slab_free_freelist_hook+0xa1/0x160
[  322.660179]  ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660186]  __kmem_cache_free+0xb2/0x290
[  322.660192]  drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660200]  drm_exec_fini+0xf/0x1c0 [drm_exec]
[  322.660206]  test_early_put+0x289/0x490 [drm_exec_test]
[  322.660215]  ? __pfx_test_early_put+0x10/0x10 [drm_exec_test]
[  322.660222]  ? __kasan_check_byte+0xf/0x40
[  322.660227]  ? __ksize+0x63/0x140
[  322.660233]  ? drmm_add_final_kfree+0x3e/0xa0 [drm]
[  322.660289]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[  322.660294]  ? lockdep_hardirqs_on+0x7d/0x100
[  322.660301]  ? __pfx_kunit_try_run_case+0x10/0x10 [kunit]
[  322.660310]  ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]
[  322.660319]  kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]
[  322.660328]  kthread+0x2e7/0x3c0
[  322.660334]  ? __pfx_kthread+0x10/0x10
[  322.660339]  ret_from_fork+0x2d/0x70
[  322.660345]  ? __pfx_kthread+0x10/0x10
[  322.660349]  ret_from_fork_asm+0x1b/0x30
[  322.660358]  </TASK>
[  322.660818]     ok 8 test_early_put

Cc: Christian König <christian.koenig@amd.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Danilo Krummrich <dakr@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Danilo Krummrich <dakr@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
emaste pushed a commit to emaste/drm-kmod that referenced this issue Oct 24, 2024
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the address of the first
mutex of a given class locked in a sequence.
This has the odd consequence that if that first mutex is unlocked while
other mutexes of the same class remain locked and then its memory then
freed, the lock alloc tracking code will incorrectly assume that memory
is freed with a held lock in there.

For now, work around that for drm_exec by releasing the first grabbed
object lock last.

v2:
- Fix a typo (Danilo Krummrich)
- Reword the commit message a bit.
- Add a Fixes: tag

Related lock alloc tracking warning:
[  322.660067] =========================
[  322.660070] WARNING: held lock freed!
[  322.660074] 6.5.0-rc7+ freebsd#155 Tainted: G     U           N
[  322.660078] -------------------------
[  322.660081] kunit_try_catch/4981 is freeing memory ffff888112adc000-ffff888112adc3ff, with a lock still held there!
[  322.660089] ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660104] 2 locks held by kunit_try_catch/4981:
[  322.660108]  #0: ffffc9000343fe18 (reservation_ww_class_acquire){+.+.}-{0:0}, at: test_early_put+0x22f/0x490 [drm_exec_test]
[  322.660123]  freebsd#1: ffff888112adc1a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x11a/0x600 [drm_exec]
[  322.660135]
               stack backtrace:
[  322.660139] CPU: 7 PID: 4981 Comm: kunit_try_catch Tainted: G     U           N 6.5.0-rc7+ freebsd#155
[  322.660146] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021
[  322.660152] Call Trace:
[  322.660155]  <TASK>
[  322.660158]  dump_stack_lvl+0x57/0x90
[  322.660164]  debug_check_no_locks_freed+0x20b/0x2b0
[  322.660172]  slab_free_freelist_hook+0xa1/0x160
[  322.660179]  ? drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660186]  __kmem_cache_free+0xb2/0x290
[  322.660192]  drm_exec_unlock_all+0x168/0x2a0 [drm_exec]
[  322.660200]  drm_exec_fini+0xf/0x1c0 [drm_exec]
[  322.660206]  test_early_put+0x289/0x490 [drm_exec_test]
[  322.660215]  ? __pfx_test_early_put+0x10/0x10 [drm_exec_test]
[  322.660222]  ? __kasan_check_byte+0xf/0x40
[  322.660227]  ? __ksize+0x63/0x140
[  322.660233]  ? drmm_add_final_kfree+0x3e/0xa0 [drm]
[  322.660289]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[  322.660294]  ? lockdep_hardirqs_on+0x7d/0x100
[  322.660301]  ? __pfx_kunit_try_run_case+0x10/0x10 [kunit]
[  322.660310]  ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]
[  322.660319]  kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]
[  322.660328]  kthread+0x2e7/0x3c0
[  322.660334]  ? __pfx_kthread+0x10/0x10
[  322.660339]  ret_from_fork+0x2d/0x70
[  322.660345]  ? __pfx_kthread+0x10/0x10
[  322.660349]  ret_from_fork_asm+0x1b/0x30
[  322.660358]  </TASK>
[  322.660818]     ok 8 test_early_put

Cc: Christian König <christian.koenig@amd.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Danilo Krummrich <dakr@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Danilo Krummrich <dakr@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906095039.3320-4-thomas.hellstrom@linux.intel.com
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants