07 Nov 2020 - tsp
Last update 03 Mar 2021
TL;DR: Reinstall the
graphics/drm-freebsd12.0-kmod from ports (i.e.
compiling it from source) to match the kernel version again.
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
i915 or the
amdgpu driver for example. There are five major
ports currently in use on FreeBSD 12.x:
Which one is required depends on the operating system and the graphics card
one is using. On 12.x systems one required the
port even if one’s running 12.2 for example.
So what happened? During setup of FreeBSD 12.0 I installed
as well as
x11-drivers/xf86-graphics-intel on an notebook using and
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
# Install FreeBSD update for current revision
# 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.
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:
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 (
tar -C / -xzf src.txz
This extracts the whole source tree to
To ensure that the source tree is in sync with ones binary package one can then
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
make clean install clean
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
metaport that might be used if one doesn’t know which one of the
ports one needs - this sometimes works, just be sure to deinstall all of them
in the first place.
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:
Dipl.-Ing. Thomas Spielauer, Wien (email@example.com)
This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/