FreeBSD 12.x binary upgrade and graphics card problems (drm-fbsd12.0-kmod, drm-kmod)

TL;DR: Reinstall the graphics/drm-freebsd12.0-kmod from ports (i.e. compiling it from source) to match the kernel version again.

The problem

Whenever one does a revision upgrade on FreeBSD the kernel interface might change and might be incompatible for older kernel modules. To counter that kernel modules target a specific revision of the FreeBSD operating system (this does not affect patch levels). Currently many graphics drivers are fetched from the Linux source tree and thus have to be built as a separate kernel module due to licensing restrictions. This is still done because documentation for graphics hardware is totally missing from some vendors and is lacking crucial information from other vendors - for some vendors their open drivers are just a collection of chaotic source files so no one can really reprogram a cleanroom implementation of a driver for their cards. Since FreeBSD is not that common on desktop systems most vendors also don’t care about FreeBSD support either.

The main problem when using the Linux drivers though is that FreeBSD just is not a Linux distribution of course so it does offer an entirely different kernel interface. This is solved by the graphics/drm-kmod packages that build kernel modules required by most graphics drivers such as x11-drivers/xf86-video-intel for the i915 or the amdgpu driver for example. There are five major ports currently in use on FreeBSD 12.x:

• graphics/drm-freebsd11.2-kmod
• graphics/drm-freebsd12.0-kmod
• graphics/drm-legacy-kmod
• graphics/drm-current-kmod
• graphics/drm-devel-kmod

Which one is required depends on the operating system and the graphics card one is using. On 12.x systems one required the drm-freebsd12.0-kmod port even if one’s running 12.2 for example.

So what happened? During setup of FreeBSD 12.0 I installed graphics/drm-freebsd12-0-kmod as well as x11-drivers/xf86-graphics-intel on an notebook using and i915 Intel GPU. It turned out to work great of course. During each update to 12.1 and 12.2 using freebsd-udpate going the binary route by executing

# Bring packages up to date
pkg update
pkg upgrade
# Install FreeBSD update for current revision
freebsd-update fetch
freebsd-update install
# Follow instructions by freebsd-update including pkg update and pkg upgrade

and then doing the revision change:

freebsd-update upgrade -r 12.2-RELEASE

and then again following the instructions of freebsd-update which works pretty stable everything turns out to work great - except graphics drivers being broken after each minor revision change - just to mention again this does not affect upgrading between patch levels which is totally unproblematic in any way.

At the end do not forget to execute pkg update and pkg upgrade again.

The solution

This is caused by the simple fact that the publicly available binary package repository - and also my own local repository - is built from the ports tree as if one would build them locally on a specific version of FreeBSD - in many cases it’s done on an older minor revision than one has upgrade though. This is totally unproblematic for any userland software and turns out to work great there but kernel modules have to match the version of the installed kernel. The only real solution is to either wait till one’s own kernel matches the kernel used by the package builder or to simply build the package oneself. The backdraw of doing the build oneself is that one has to do this for every major upgrade and one has to have the src component installed.

If one doesn’t have the src component installed one can do this either from source:

cd /usr/src
svnlite co https://svn.FreeBSD.org/base/release/12.2.0 .

or fetch it from the binary archive that’s also used during installation which is way faster and less load for the FreeBSD servers (so it’s the recommended way) - just be sure that you use the correct architecture (amd64 in this example) and the correction revision (12.2-RELEASE here):

fetch https://download.freebsd.org/ftp/releases/amd64/12.2-RELEASE/src.txz
tar -C / -xzf src.txz

This extracts the whole source tree to /usr/src

To ensure that the source tree is in sync with ones binary package one can then use freebsd-update again:

freebsd-update fetch install

Now one is simply capable of rebuilding the required kernel module after removing them manually:

pkg delete drm-freebsd12.0-kmod
pkg delete xf86-video-intel
cd /usr/ports/graphics/drm-fbsd12.0-kmod/
make clean install clean
cd /usr/ports/x11-drivers/xf86-video-intel/
make clean install clean

Side note: Why do I run clean before the install target? Just to ensure that there is no old build lingering around that’s technically matching the file timestamps of the fetched source but not matching the correct kernel.

After that everything should work out again. There is also a graphics/drm-kmod metaport that might be used if one doesn’t know which one of the graphics/drm-*-kmod ports one needs - this sometimes works, just be sure to deinstall all of them in the first place.

Conclusion

So just as a short conclusion: The source of the problem is pretty clear, the source of the real problem - the hardware manufacturers not providing clean documentation for their hardware which is a known problem since ages (not only on the desktop but also on mobile platforms even more) is pretty well known. There is simply not enough pressure on hardware vendors to open up documentation because there is simply no company manufacturing current state of the art graphics cards that’s opening up their documentation to developers (why? They’re afraid that one might catch them for patent infringement - no that’s not a joke that’s the only reason) so no company really cares. This is also the root cause of bad graphics support on open operating systems - vendors only concentrate on MS Windows in this case and have some buggy implementation for Linux that the community is building their customization’s on most of the times or there are drivers that are built around reverse engineered information where the only usable documentation is the source code - which is the same as no existing documentation at all. There won’t be a fix for this problem unfortunately but you can complain to your graphics card vendors as often as possible though and request them to provide all information required to develop an open source driver for their current hardware from scratch, maybe someday this will change.

This article is tagged:

• Administration
• Computer
• FreeBSD