Updated a 2 month old FreeBSD-current to top-of-tree Oct 22, 2025. Went to rebuild drm-515-kmod, and was greeted with error message /wrkdirs/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.160_5/drivers/gpu/drm/drm_pci.c:75:35: error: too few arguments provided to function-like macro invocation 75 | pci_get_slot(dev->dev->bsddev), | ^ /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:1337:9: note: macro 'pci_get_slot' defined here 1337 | #define pci_get_slot(_pbus, _devfn) \ | ^ /wrkdirs/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.160_5/drivers/gpu/drm/drm_pci.c:99:43: error: too few arguments provided to function-like macro invocation 99 | info->dev = pci_get_slot(dev->dev->bsddev); | ^ /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:1337:9: note: macro 'pci_get_slot' defined here 1337 | #define pci_get_slot(_pbus, _devfn) \ | ^ /wrkdirs/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.160_5/drivers/gpu/drm/drm_pci.c:99:12: error: incompatible pointer to integer conversion assigning to 'uint8_t' (aka 'unsigned char') from 'uint8_t (device_t)' (aka 'unsigned char (struct _device *)') [-Wint-conversion] 99 | info->dev = pci_get_slot(dev->dev->bsddev); | ^ ~~~~~~~~~~~~ 3 errors generated. *** [drm_pci.o] Error code 1 make[1]: stopped making "all" in /wrkdirs/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.160_5/drm --- drm_plane_helper.o --- --- drm_plane.o --- make[1]: 1 error make[1]: stopped making "all" in /wrkdirs/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.160_5/drm OK, so, drm-515 is no longer supported. I built drm-61-kmod. Upon loading radeonkms.ko, the /usr was destroyed. After rebooting to single user mode, 'fsck -fy' moved 650MB of stuff into /usr/lost+found. Joys of current.
As an addendum, drm-66-kmod leads to endless reboot loop. % pciconf -vl ... vgapci0@pci0:1:0:0 class=0x030000 rev=0x00 vendor=0x1002 device=0x6779 subvendor=0x1092 subdevice=0x6450 Vendor = 'Advanced Micro Device, Inc. [AMD/ATI]' device = 'Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM'
Adding 'CFLAGS+=-DWANT_NATIVE_PCI_GET_SLOT' to the Makefile has gotten me passed the build failure. Now, let's see if we can get radeonkms.ko to load.
This diff fixes the build. Don't know if it's correct. ] git diff graphics/drm-515-kmod/ diff --git a/graphics/drm-515-kmod/Makefile b/graphics/drm-515-kmod/Makefile index 671c1726f40f..ecf113bb5c4e 100644 --- a/graphics/drm-515-kmod/Makefile +++ b/graphics/drm-515-kmod/Makefile @@ -52,6 +52,8 @@ PLIST_SUB+= AMDGPU="@comment " PLIST_SUB+= I915="@comment " .endif +CFLAGS+=-DWANT_NATIVE_PCI_GET_SLOT + MAKE_ENV+= MAKEOBJDIRPREFIX=${WRKSRC}/obj pre-build:
Sorry for the annoyance on current. I am testing and making sure things compile for what the drm-kmod port supports. The snarly comment I have, and I hope you don't get me wrong, if you do not find help or figure out what your issue is with newer drm-kmod you'll sooner or later not have graphics anymore. I have to admit it is a very painful process and after almost half a year I got an amdgpu working without fully knowing what caused it not to bring my laptop back to POST anymore. I am ware that there are some projects under way which would help the debugging immensely but I beleive sadly none of them is fully there yet (but I also have been on holiday and still have more to catch up). That all said, as a local workaround, you could probably fairly simply replay the commit which went into drm-kmod master and 6.6-lts and 6.1-lts to 5.15-lts as it seems to apply cleanly: % git cherry-pick 20829888caf411a4ac5a4349cbb013334e0b31de Auto-merging drivers/gpu/drm/drm_pci.c Auto-merging drivers/gpu/drm/drm_sysctl_freebsd.c [5.15-lts bd997db9f2] drm: use LinuxKPI PCI functions rather than bsd native Date: Thu Jul 31 07:31:38 2025 +0000 2 files changed, 15 insertions(+), 27 deletions(-) % git status On branch 5.15-lts Your branch is ahead of 'origin/5.15-lts' by 1 commit. (use "git push" to publish your local commits) ... But I believe we cannot do that unconditionally as the underlying LinuxKPI change is not in the branches (and releases) which would still require 5.15-lts (I'd have to go and check the full matrix).
So it's only drm-515-lts and only on 15/16 which fails if I digged myself through all three inboxes and online mailing list archives correctly? I assume once I would MFC wireless to stable/14 (which I have not as it's a different can of worms) that would fail too. We cannot adjust LinuxKPI in 14.3-R anymore so the only possible changes I currently see is to either make this conditional in the 5.15-lts tree by __FreeBSD_version or to add a conditional extra patch to the port. I would vote for the latter for now (you can likely use the git change as pointed out earlier) and once the MFCs to stable/14 happend we'll simply add the __FreeBSD_version check along to the 5.15-lts branch before tagging and updating the port and undo the local patch there then and then it's clean. Given the port is maintained by x11@ I'll add dumbbell for the moment to Cc: as he helped with the original changes to 6.x-lts and master. Maybe he can help with this too?
(In reply to Bjoern A. Zeeb from comment #4) > > The snarly comment I have, and I hope you don't get me wrong, if you do not > find help or figure out what your issue is with newer drm-kmod you'll sooner or > later not have graphics anymore. > I have tried drm-61 and drm-66. 'kldload radeonkms' results in instant reboots. No panic. No error message. Just a reboot. There is no hints as to where to even start to debug this. I also have a system with an AMD Ryzen 7 7700X with a Raphael GPU. Neither drm-61 nor drm-66 worked (when I tried setting up X) with the amdgpu.ko module. Lucky, one can use the scfb video driver to have graphics. -- steve
(In reply to Steve Kargl from comment #6) for amdgpu I had the same issue on main; kldload amdgpu, wait 5 seconds, see POST (no ddb or anything). I believe but have not validated that running GENERIC-NODEBUG fixed it for me (which is bad as a developer as it means I don't get a lot of other dogfood on my laptop anymore).
Created attachment 265299 [details] drm-515-kmod extra patch for LinuxKPI PCI breakage I am not a ports person but it seems to apply when tested make patch on a main machine and given the OS/VERSION checks are already there. Someone may want to LINT this, test it on stable/14 or 14.3-R as well before committing.
(In reply to Steve Kargl from comment #1) The reboot loop can be solved by copying gpu firmware .bin files installed by the package gpu-firmware-amd-kmod to /boot/firmware/amdgpu. Don't copy the .ko files. Extract the .bin files from the port's distfile and simply copy them. The amdgpu.ko is unable to load the firmware .ko files but will find the .bin files. You can discover this yourself with a boot -v. It will complain firmware files that cannot be found. It then reboots, wash, rinse, repeat.
(In reply to Cy Schubert from comment #9) WOW. Is there an open Issue for this anywhere? I have indeed also added copies of linux-firmware.git to /boot/firmware for wifi and with that also got amdgpu bin files there. Why is it not able to load .ko files? It should go through the same code paths that wifi and everyone uses... Definitively needs a dedicated issue to track this!
(In reply to Bjoern A. Zeeb from comment #10) See PR/289320.
(In reply to Bjoern A. Zeeb from comment #8) If this patch works please commit it.
(In reply to Emmanuel Vadot from comment #12) I don't know and I cannot build it on all branches so do not ask me if the ports logic is correct for 14.3...
I successfully built the port with the patch attached to this ticket. I did the build in a VM, so I didn't test runtime, but it at least compiles on with recent (updated earlier today) src and ports trees. I've switched all my laptops to the drm-66 family kmods, so I don't have any systems on which to perform a runtime test. Sorry for the incomplete dataset, but this does at least make the build happy.
(In reply to Shawn Webb from comment #14) Built on which version of FreeBSD? 14.3-R stable/14, stable/15, 15.0-BETA, main?
(In reply to Bjoern A. Zeeb from comment #15) src: FreeBSD main@4109cdf0f817162cf3032aa589dd180dfa910025 ports: FreeBSD main@d80dbada26acbfd47ccaf844157d193c19e8f9d7 HardenedBSD hardenedbsd/main@81b43b7d1ee5794ec54cbc8a12aed16910f0b753 HardenedBSD hardened/current/master@bdffcff9c37252e4444bbbede871132db1969d54 I should note that I tested the build on HardenedBSD. We don't have any changes that would impact stuff dealing with this bug. I included both the FreeBSD and HardenedBSD git commit hash above.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=26b48400ee94055021329765aaa0735bb55f6571 commit 26b48400ee94055021329765aaa0735bb55f6571 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2025-11-16 21:52:42 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2025-11-16 23:13:41 +0000 graphics/drm-515-kmod: add extra patch to unbreak on 15 and newer Conditionally apply a patch to avoid conflicts with an updated LinuxKPI. This should make this port both build and work again. The patch is conditional for the moment as 14.3-R and stable/14 do not have the LinuxKPI changes yet. stable/14 will likely get it before 14.4-R. At that point it might be easier to (a) have it conditional in the drm-kmod branch based on __FreeBSD_version or (b) have a backout patch here for 14.2-R and stable/14 before the LinuxKPI update. PR: 290432 Reported by: kargl graphics/drm-515-kmod/Makefile | 7 +- .../files/extra-patch-linuxkpi-pci (new) | 102 +++++++++++++++++++++ 2 files changed, 108 insertions(+), 1 deletion(-)
Thanks to a friendly help email from bapt I got a poudriere setup sorted and built this on 14.3-R, stable/14, stable/15, releng/15.0, and main without error and pushed it. I hope that will solve the problems (for now) and set me up tp deal with stable/14 once I'll MFC the LinuxKPI changes. I am also subscribed to x11 now so I may see fallout emails. Steve, if you can confirm that the updated version works for you too, can you please close the PR? Sorry again, that now one else picked this up. Back to wireless for me.
I rebuilt the port with an updated ports tree. The built completed and the installed radeonkms.ko was loaded without any issues. Thanks @bz for a better patch than one I initially posted. Closing.