FreeBSD 15.0 upgrade: dealing with a broken amdgpu

I recently upgraded my machine from FreeBSD 14.3 to 15.0-RELEASE. The upgrade itself went smoothly enough, but when I rebooted into the new system, I was greeted with a kernel panic. The culprit: amdgpu.

My machine is a Lenovo T14s with an AMD Ryzen 7 PRO 7840U — Phoenix architecture, Zen 4, with an integrated Radeon 780M (RDNA 3, GFX 11.0.1). It worked fine with ghostBSD (FreeBSD 14.3), but on 15.0 the module simply panics the kernel on load, whether at boot or manually with kldload amdgpu.

I tried drm-61-kmod as an alternative (which replaces drm-66-kmod), making sure all the required firmware packages were present. Same result — a kernel panic with this backtrace:

#5  unregister_fictitious_range+0xc
#6  amdgpu_device_fini_hw+0x190
#7  amdgpu_driver_load_kms+0x84
#8  amdgpu_pci_probe+0x290
#9  linux_pci_attach_device+0x5ac

This is apparently same type of issue as drm-kmod #343. The crash happens inside vm_phys_fictitious_unreg_range, a kernel memory mapping function — it's not a missing firmware problem, it's a kernel API incompatibility. None of the currently available drm-kmod packages (drm-515, drm-61, drm-66) work with the Radeon 780M on FreeBSD 15.0-RELEASE. Apparently, the fix requires drm-610-kmod, which at the time of writing only targets FreeBSD-CURRENT. So for now, amdgpu is simply not an option on this hardware.

The fix: scfb and the UEFI framebuffer

Since the machine boots via UEFI, FreeBSD already has access to a basic framebuffer through vt(4). The scfb Xorg driver can use that to give a working graphical desktop — no GPU acceleration, but everything else works fine.

First, I removed amdgpu from /etc/rc.conf and /boot/loader.conf, then installed the scfb driver:

pkg install xf86-video-scfb

Then I created /usr/local/etc/X11/xorg.conf.d/20-driver.conf:

Section "Device"
    Identifier "Card0"
    Driver "scfb"
EndSection

I also made sure this sysctl was set in /etc/sysctl.conf:

kern.evdev.rcpt_mask=12

In my case that was enough for keyboard and mouse to work without any additional input configuration. That said, if you find input isn't working, it's worth installing xf86-input-libinput and adding an explicit InputClass config for keyboard and pointer — some setups seem to need it.

You should add a file like this 30-input.conf in /usr/local/etc/X11/xorg.conf.d/:

Section "InputClass"
    Identifier "libinput keyboard"
    MatchIsKeyboard "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
EndSection

Section "InputClass"
    Identifier "libinput pointer"
    MatchIsPointer "on"
    MatchDevicePath "/dev/input/event*"
    Driver "libinput"
EndSection

One more thing: Picom

I use pekwm with Picom as my compositor, and it turned out to be the last piece of the puzzle. Its default glx backend requires OpenGL, which you obviously don't have without a GPU driver. The fix is straightforward — switch it to xrender in ~/.config/picom.conf:

backend = "xrender";
vsync = false;

With that, Picom works just as before. No blur or GPU-accelerated effects, but shadows and transparency are fine.

Where things stand

The end result is a fully usable desktop: window manager, compositor, keyboard, mouse — all working. The only real missing piece is GPU acceleration, which matters mostly for 3D applications and hardware video decoding.

Once drm-610-kmod lands properly for FreeBSD 15 STABLE, getting acceleration back should just be a matter of installing the new module, re-enabling amdgpu, and switching Picom back to glx. Until then, this setup does the job.

Comparison

When I compare, on the same laptop, FreeBSD 15 with frame buffer and GhostBSD 14.3 with amdgpu, I do not see impacts when looking at youtube video:

On FreeBSD 15 frame buffer:

• Firefox has 2 processes with an occupation of 37% and 27%
• Picom has 1 process with a bit more than 2% usage
• Xorg has 1 process with a bit more than 27% usage

After +5 minutes of video, when the battery state was at 43%, apm informs that the remaining battery time is 52 minutes

On GhostBSD with amdgpu:

• Firefox has 2 processes with an occupation of 18% and 14%
• Picom has 1 process with a bit more than 2% usage
• Xorg has 1 process with a bit more than 2% usage

After +5 minutes of video, when the battery state was at 43%, apm informs that the remaining battery time is 1h12.

This is not scientific and accurate, but I never had freeze or troubles looking at video in both cases. As expected the battery drains a bit faster with frame buffers.