Solved Warning: Latest 15 stable update breaks drm-*-kmod

fahrenheit

fahrenheit

This is just an heads-up for users for base_latest of FreeBSD 15.

The update from yesterday broke drm-*-kmod (even using FreeBSD-ports-kmods set to latest).

TL;DR; Wait for updated packages on FreeBSD-ports-kmods (drm-66-kmod-6.6.25.1500508_9, drm-61-kmod-6.1.128.1500508_9,
drm-515-kmod-5.15.160.1500507_10, drm-latest-kmod-6.9.1500508_2 and maybe drm-latest-kmod-6.11.1500508) or build from source.

It is possible that this only affects amdgpu, but my suggestion for users of base_latest who are affected is to switch to base_weekly until this is solved.

quick resolution howto of the kernel panic that will happen:
  • boot as single user
  • run fsck (if necessary)
  • mount root as rw (# mount -u /)
  • start networking if necessary (# service netif restart && service routing restart)
  • edit /etc/rc.conf and, temporarily, remove amdgpu (or the relevant driver) from kldlist and disable the lightdm service (or similar if in use)
  • edit /etc/pkg/FreeBSD.conf and make the necessary changes
  • update package database (# pkg update -f)
  • reinstall of packages for base (# pkg upgrade -f -r FreeBSD-base)
  • reboot
  • Assuming multi user boot worked, try to load amdgpu (# kldload amdgpu) if there is no kernel panic, revert rc.conf changes and reboot (or start services)
Updated: to indicate that it's drm-latest-kmod that is breaking.
 
Is this really news though? No offense intended (!), but STABLE, just like CURRENT, are essentially developer snapshots and although this is less bleeding edge there are still no guarantees that things will continue working. IMO you should always expect issues when you run either of these branches.

On that note: did you already try to relay this info back to the developers? I'm convinced they'd be interested in getting feedback about issues.
 
ShelLuser, yes, I'm perfectly aware that stable occasionally breaks, that's the reason for the warning.

And no, this is my daily driver, if it's still broken by the weekend I can do it then.
 
Which version of graphics/drm-*-kmod?
An user (rbranco here?) is reporting crash of graphics/drm-latest-kmod on FreeBSD-kernel-generic-15.snap20260422212203 at freebsd-stable ML with i915kms driver.

Note that I'm running graphics/nvidia-drm-66-kmod-devel, which borrows parts of codes from graphics/drm-66-kmod, without crash on stable/15 at commit d1c800badec7750194ba19a225d364377b74362b. This is AFTER the introduction of DRM 6.11. So I think the issue is in GPU specific part and possibly affecting only graphics/drm-latest-kmod.
 
Note that nvidia-drm.ko from graphics/nvidia-drm-*-kmod* pulls in drm.ko and dmabuf.ko installed by corresponding graphics/nvidia-drm-*-kmod automatically on load. So if graphics/drm-66-kmod is also affected, the issue would be in any or all of amdgpu.ko, i915kms.ko and ttm.ko or firmwares (graphics/gpu-firmware*-kmod).

Or something required specifically by amdgpu.ko, i915kms.ko and/or ttm.ko is dropped from merge into LinuxKPI.
 
fahrenheit said:
T-Aoki, good point, forgot to mention that, it's drm-latest-kmod. The specific package is: drm-latest-kmod-6.9.1500507_1
Click to expand...
If I'm not overlooking something, I've never seen any complaints about the crash on freebsd-current ML nor dev-commits-src-main ML with LinuxKPI updated to DRM 6.11. But maybe users of graphics/drm-latest-kmod (or graphics/nvidia-drm-latest-kmod*) would be quite limited.
 
Okay, did some quick tests back on stable_latest:
  • drm-66-kmod (from repo), black screen on kldload amdgpu, with automatic reboot after the panic timeout
  • drm-latest-kmod (i.e. 6.9, from repo), panic but not black screen on kldload
  • drm-latest-kmod built against the 6.11 tag of drm-kmod, working
The LinuxKPI merge was done yesterday to stable so that matches the behaviour that I'm having.
 
If you use ZFS you can also do a rollback to the latest snapshot (assuming you take snapshots before upgrading):

Code: 
mount -u /
zfs rollback -r $(zfs list -t snapshot | tail -1 | awk '{ print $1 }')
 
fahrenheit said:
Okay, did some quick tests back on stable_latest:
  • drm-66-kmod (from repo), black screen on kldload amdgpu, with automatic reboot after the panic timeout
  • drm-latest-kmod (i.e. 6.9, from repo), panic but not black screen on kldload
  • drm-latest-kmod built against the 6.11 tag of drm-kmod, working
The LinuxKPI merge was done yesterday to stable so that matches the behaviour that I'm having.
Click to expand...
Ah, you've used official pkg?
I've not using offical pkg, building locally. And I'm forcibly rebuilding all kmod ports after installworld / etcupdate but before reboots from single user mode.

And currently
Code: 
# pkg search -r FreeBSD-ports-kmods drm
drm-515-kmod-5.15.160.1500507_9 Direct Rendering Manager GPU drivers
drm-61-kmod-6.1.128.1500507_8  Direct Rendering Manager GPU drivers
drm-66-kmod-6.6.25.1500507_8   Direct Rendering Manager GPU drivers
drm-latest-kmod-6.9.1500507_1  DRM drivers modules
means that official kmod builder for stable/15 is NOT yet updated to __FreeBSD_version (= ${OSVERSION} on ports framework) 1500508 that was bumped for DRM 6.11. So official pkg should be problematic for now and wait updates of builders.

And FreeBSD-ports repo is built on 15.0 now (oldest supported minor version per every supported major versions), thus, DRM kmods there shouldn't work for stable/15.
 
T-Aoki, confirmed that drm-66-kmod if built from source (i.e. revision 9 of the current package) works with the latest stable.

So, the FreeBSD-ports-kmods on the latest branch is not in sync with FreeBSD-base if using the latest branch (i.e. stable), which IMO is a governance issue. It doesn't affect headless deployments but is a pain for "desktop" usage.
 
rbranco said:
I dunno why these LinuxKPI commits were committed to the main & stable/15 branches the same day. Should have been tested in -CURRENT fist.
Click to expand...
It was on current for a while now (there weren't any major issues from what I've read apart for Xe users which will be handled with drn 6.12), it was added to stable/15 yesterday.

And will probably break again soon if 6.12 drm is also to be added for the 15.1 release as is the plan.
 
fahrenheit said:
T-Aoki, confirmed that drm-66-kmod if built from source (i.e. revision 9 of the current package) works with the latest stable.

So, the FreeBSD-ports-kmods on the latest branch is not in sync with FreeBSD-base if using the latest branch (i.e. stable), which IMO is a governance issue. It doesn't affect headless deployments but is a pain for "desktop" usage.
Click to expand...
It's simply impossible with current form of infrastructure.

If I understand correctly, there are 2 git servers for now, one for committers only (master server) and another for publicly available (main repos) that is always in sync with master server. The main server is mirrored to mirror servers all over the world and also used for distribution/pkg building.

What you want can be achieved only if (considering safety of master repo):
  1. Both src and ports git repo has 2 independent main repos (not sync in real-time).
  2. One set of newly added src and ports git server are always in sync with the master server and base distributions (include snapshot distributions) and pkgs are built against it.
  3. Once all builds for per-branch distributions and pkgs finishes sanely in sync, sync git repo and pkg repo are sync'ed to publicly available main server and send mail to dev-commits-* MLs about sync'ed commits.
But this clearly has almost fatal downside.
Non-committer developers / maintainers like me cannot know when the specific accepted (on Phabricator, Bugzilla or pull requests) updates become available until public server gets updates, unless any of committers privately notifies about affecting updates. This could significantly delay developments. So I object it.

What I think better (cannot be best, though, and already proposed before kmod pkg repo starts working) is to force all kmod ports to be built locally (their pkgs include triggers to local builds [and part of ports tree needed if full /usr/ports are not installed] only, and /usr/src/sys is always forcibly installed and kept in sync with installed kernel even if the computer doesn't have git, gitup nor got installed).
 
T-Aoki, taking into account what you said and discarding my ideia of "staging" area for packages (wouldn't also work for the same reasons as you mentioned), what you propose obviously works, and has already been tested extensively on Linux (and probably other OSes) with DKMS.

Whether or not it's best I don't know, but clearly the current solution is also not "best".
 
The best would be that even on mimimalistic IoT devices has terabytes of memories, exabites of storage, CPU power that can compile www/chromium in 1 second including fetching all needed distfiles (enough bandwidth of network!) or below from scratch, for "current (now Apr. 24, 2026 in Japan) scale of softwares". It would hide the oddities behind.🤣
 
T-Aoki said:
The best would be that even on mimimalistic IoT devices has terabytes of memories, exabites of storage, CPU power that can compile www/chromium in 1 second including fetching all needed distfiles (enough bandwidth of network!) or below from scratch, for "current (now Apr. 24, 2026 in Japan) scale of softwares". It would hide the oddities behind.🤣
Click to expand...
Well, excluding current browsers mostly, we are there now. I remember doing linux from scratch installations and trying gentoo in the start of the 2000's and it was not a fun experience..
 
I was on 15.1-PRE yesterday, ran pkg update from a script, ignored a mismatch version warning and updated a bunch of stuff (thought it was from pkg32 wine 😅), rebooted and froze at next boot. I was testing filesystem stuff too and figured that was related so I booted a Linux LiveUSB, backed stuff up, and installed 15.0-R :D

I didn't check if it was drm-kmod, but thought that quarterly/latest kmod thing was resolved a while back (ran into it 14.2 or .3 right before the repos were released).
 
fahrenheit said:
Well, excluding current browsers mostly, we are there now. I remember doing linux from scratch installations and trying gentoo in the start of the 2000's and it was not a fun experience..
Click to expand...
What I wanted to say was that building kmod ports locally (if automated as installing via pre-built pkg) can be no (ignorable) pain if any lowest-end computers like smartwatches has sufficient capacity and performance to keep src and ports (including distfiles and resulted locally built pkgs) locally. 😁

Chromium is just an example for "exisiting huge monster to build locally".

Yes, I know it's just a dream at least currently.
 
Espionage724 said:
I was on 15.1-PRE yesterday, ran pkg update from a script, ignored a mismatch version warning and updated a bunch of stuff (thought it was from pkg32 wine 😅), rebooted and froze at next boot. I was testing filesystem stuff too and figured that was related so I booted a Linux LiveUSB, backed stuff up, and installed 15.0-R :D

I didn't check if it was drm-kmod, but thought that quarterly/latest kmod thing was resolved a while back (ran into it 14.2 or .3 right before the repos were released).
Click to expand...
Confirming with dry-run before actual run to confirm safety (and be patient to wait for pkg repo is really up-to-date, in-sync) would be a good habit.
 
You must log in or register to reply here.
Back
Top