Solved drm-kmod: Black screen and freeze after update from FreeBSD 12.1 to 12.2

When it was time for the first reboot after running the FreeBSD update command, then the boot proces suddently went black and then the system freezed. Keyboard unresponsive. It goes so fast, that I had to use slow motion video to read the last written message as "Loading kernel modules". It is a desktop computer with GELI encryption, ZFS, DRM for Intel kernel module and Xorg. DRM, Xorg and other applications was installed by the default package manager utility. There are no error messages in the system log: The boot messages simply stop at the DRM kernel module load time. There are a few other related threads about this, but those seem like to be related to not having used the default package manager or other error messages.

What would the correct procedure be to fix or recover from this situation?
 
There is a problem with some packages (namely the 'kmod' or kernel module packages) when you upgrade from 12.1 to 12.2; for some reason, those kernel modules might not work as they should. That would be the drm-*-kmod packages that you are using. To fix the problem, you need to rebuild and install the module from ports instead of from packages.
(Yes, that are the official packages, installed with the official tool pkg. They should work, but they do not - see the other threads in the forums)

As for correct procedure, first you need to get your machine booting again, so you can work on it and fix the problem. It goes something like this:
- boot the machine from a usb stick containing FreeBSD (the FreeBSD install usb image is good for this)
- mount the root partition of your hard drive (the one you normally boot FreeBSD from)
- edit <mountpoint>/etc/rc.conf and comment out the line kld_list="..." (temporarily, while you work on the problem)
- if you start Xorg via a display manager (xdm / gdm / whatever) you need to disable that temporarily too
- now you can boot the machine, it will boot to a console (text) login

From here you can install ports etc by ssh'ing in from your other machine, and fix the problem.
HTH
 
I booted the machine by pressing Esc at the FreeBSD boot menu and then typing boot kernel.old and Enter. I logged in as normal, removed the old DRM packages, updated the ports tree and installed the DRM port. I noticed, that version from ports was 20201213, which indicated a newer than the package version, I had before. I confirmed, that the DRM port was enabled in /etc/rc.conf. I then rebooted, but the machine went black and freezed as before.

# portsnap auto
# more /usr/ports/UPDATING
# portmaster graphics/drm-fbsd12.0-kmod


Does it matter, that the machine rebooted on the kernel.old? Or are there other suggestions?
 
I also tried disabling DRM in /etc/rc.conf and then rebooting into the 12.2 kernel and then reinstalling the DRM port before enabling DRM again. This also does not work.
 
I noticed, that /usr/src seems to from 2019 even though the system is updated and patched. Not sure, if that is related to the compiling of kernel modules, or if it could break the system, if /usr/src manually updated.
 
If the machine is booted into kernel.old, then X and GNOME works fine. How is that even possible, when the DRM kernel module is reinstalled and not working in the current kernel?
 
Hello, i had the same problem with the module i915kms. i updated the source tree and the port tree, installed the drm-fsbd12.0-kmod port, next, i loaded the module with full name: /boot/modules/i915kms.ko (the installed module is not in kernel) and then put the full name in kld_list.
I also created a boot environment without the module.

Sel
 
#7: No. /usr/src/UPDATING shows 2019 and 12.1-RELEASE. I found that suspicious too, but was not sure, if I would brick the system, if I updated the source system. But #8 seems to have done it and solved the problem by recompiling the kernel module after that.

#8: A boot environment without the kernel module sounds brilliant as an alternative option. Is it quite easy to do?
 
#7: No. /usr/src/UPDATING shows 2019 and 12.1-RELEASE. I found that suspicious too, but was not sure, if I would brick the system, if I updated the source system. But #8 seems to have done it and solved the problem by recompiling the kernel module after that.

#8: A boot environment without the kernel module sounds brilliant as an alternative option. Is it quite easy to do?

#8. do you have ZFS on root? If yes, Michael Lucas's page may get you started.
 
Hello, i had the same problem with the module i915kms. i updated the source tree and the port tree, installed the drm-fsbd12.0-kmod port, next, i loaded the module with full name: /boot/modules/i915kms.ko (the installed module is not in kernel) and then put the full name in kld_list.
I also created a boot environment without the module.

Sel
Also upgraded one machine with Intel graphics, DRM and ZFS boot. Did not even expect the DRM to work after kernel and world upgrade (and in fact, when I tried this, it did dot work as expected). Rebuilt the DRM (graphics/drm-fbsd12.0-kmod) after kernel build and everything is fine. I do not know, how much this counts, but I use to remove the original DRM from kernel by inserting WITHOUT_MODULES=drm drm2 into /etc/make.conf before compiling the kernel. At least, this will remove the deprecation messages.

Everything I have done has worked for me and the machine boots OK and is stable.
 
#7: No. /usr/src/UPDATING shows 2019 and 12.1-RELEASE. I found that suspicious too, but was not sure, if I would brick the system, if I updated the source system. But #8 seems to have done it and solved the problem by recompiling the kernel module after that.

Then you have build the graphics/drm-fbsd12.0-kmod kernel modules against the wrong source (12.1 source).

The objective going through the building from ports procedure is to match the kernel modules to the 12.2-RELEASE kernel (for that you need the 12.2-RELEASE kernel source) because the package installed by the pkg(8) framework is build for the oldest supported 12 branch (12.1). 12.1 and 12.2 share the same package repositories but there are internal differences between the kernels, as a result of that the kernel modules build for 12.1 (against the 12.1 source) fail on the 12.2 kernel but work on 12.1 kernel.old.

Please follow these steps:
Code:
    # rm -rf /usr/src
    (Don't mind the error message, /usr/src/ will be be emptied)

Fetch 12.2-RELEASE system source.

    Option 1 (the fast method):

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

    Update source.
    Assuming you haven't changed /etc/freebsd-update.conf:
    .....
    # Components of the base system which should be kept updated.
    Components src world kernel
    .....

    # freebsd-update fetch install

    Option 2 (the slow method):

    # svnlite checkout svn://svn.freebsd.org/base/releng/12.2 /usr/src

Update ports tree:

    # portsnap auto

Build kernel modules:

    # pkg delete drm-fbsd12.0-kmod
    # make install clean -C /usr/ports/graphics/drm-fbsd12.0-kmod

Make sure the module is set in /etc/rc.conf:

    kld_list="/boot/modules/i915kms"

Reboot.

#8: A boot environment without the kernel module sounds brilliant as an alternative option. Is it quite easy to do?

Besides sysutils/beadm there is bectl(8), which comes with the base system.
 
Last edited:
svn info /usr/src to see which sources version you have installed on your system and then update it if necessary svn update /usr/src. Aftrer /src upgrade drm build won't fail and the "new" drm will be loaded after reboot without problems.
 
Then you have build the graphics/drm-fbsd12.0-kmod kernel modules against the wrong source (12.1 source).

The objective going through the building from ports procedure is to match the kernel modules to the 12.2-RELEASE kernel (for that you need the 12.2-RELEASE kernel source) because the package installed by the pkg(8) framework is build for the oldest supported 12 branch (12.1). 12.1 and 12.2 share the same package repositories but there are internal differences between the kernels, as a result of that the kernel modules build for 12.1 (against the 12.1 source) fail on the 12.2 kernel but work on 12.1 kernel.old.

Please follow these steps:
Code:
    # rm -rf /usr/src
    (Don't mind the error message, /usr/src/ will be be emptied)
Looks like this is the case here.

To preserve 12.1 source, I have even done something like this (assuming the ZFS is used):
Code:
zfs create mypool/usr/src.12.2
zfs set mountpoint=/usr/src.12.1 mypool/usr/src
zfs set mountpoint=/usr/src mypool/usr/src.12.2
cd /usr/src/
svn checkout https://svn.freebsd.org/base/release/12.2.0/ .
 
svn checkout https://svn.freebsd.org/base/release/12.2.0/ .

That branch (release/12.2.0) is not and won't be updated after it's release of the 12.2-RELEASE branch (note the dates, https://svnweb.freebsd.org for showing the dates, for real usage https://svn.freebsd.org):


The so called "Security Branch" of a RELEASE should be used to check out/update a local copy. From FreeBSD Security Information, Understanding FreeBSD security advisories:

Code:
Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names
like releng/10.1. The corresponding builds have names likeFreeBSD 10.1-RELEASE-p4.

Here the "Security Branch" of 12.2-RELEASE (releng/12.2, note the dates):

 
#12: I followed your instructions, but the procedure stops with errors and it seems, that the source is no longer installed. The system update tool also fails with "No such file or directory".

Code:
# rm -rf /usr/src
rm: /usr/src: Device busy
# fetch https://download.freebsd.org/ftp/releases/amd64/12.2-RELEASE/src.txz
src.txz
# freebsd-update fetch install
src component not installed, skipped
You have a partially completed upgrade pending
Run '/usr/sbin/freebsd-update install' first.
Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
# freebsd-update install
...
install: ///usr/src/sys/gnu/dts/arm/sun7i-a20-hummingbird.dts: No such file or directory
install: ///usr/src/sys/gnu/dts/arm/sun7i-a20-i12-tvbox.dts: No such file or directory
...

Does anyone know the correct procedure for upgrading the source from this broken stage?
 
#12: I also tested your second procedure. That also failed with an error about usage.

Code:
# svnlite svn://svn.freebsd.org/base/releng/12.2 /usr/src
Unknown subcommand: 'svn://svn.freebsd.org/base/releng/12.2'
Type 'svn help' for usage.
 
#18: That worked. Thanks. And also thanks to you for explaining the ports compiling relation to the source version. I wonder, why the source was not updated automatically. The component update configuration was default and included source. So, the correct procedure, for fixing the black screen after the update seems to be the following.

Code:
# zfs list | grep src
zroot/usr/src       1,40G   105G  1,40G  /usr/src
# cd /usr/src
# rm -rf *
# svnlite checkout https://svn.freebsd.org/base/releng/12.2
# more UPDATING
# pkg delete drm-fbsd12.0-kmod
# make install clean -C /usr/ports/graphics/drm-fbsd12.0-kmod
# grep kld_list /etc/rc.conf
kld_list="/boot/modules/i915kms.ko"
# reboot
 
Same error here.
I follow this guide, but I am still stuck with black screen.
And with the old kernel, I have a "no screen found" error when I try to launch xorg now...
I will post here if I made progress...
 
I have the same black screen issue
Option 2 (the slow method): # svnlite checkout svn://svn.freebsd.org/base/releng/12.2 /usr/src Update ports tree: # portsnap auto Build kernel modules: # pkg delete drm-fbsd12.0-kmod # make install clean -C /usr/ports/graphics/drm-fbsd12.0-kmod Make sure the module is set in /etc/rc.conf: kld_list="/boot/modules/i915kms" Reboot.
Thank you very much, I finally made it. It works on thinkpad T430 with a fresh installation of freebsd 12.2 + xfce. I thought I was not going to make it. Thank you very much.
 
Never thought I have to say "me 2"... my Laptop is a ThinkPad T450s. I let the UEFI system check incl. long memory check run through the night, no errors. I did the upgrade on a cloned boot environment. Everything was fine, I had to edit a few files, that's all. Upgrade was from 12.1-RELEASE-p13 with pkg upgrade done right before cloning, to 12.2-p3.
  • Strange behaviour of that genuine (downloaded with freebsd-update(8)) 12.2 kernel: sporadically, it kicks every user straight out again, right after login on the console (or vt). When booting into single user mode, init(8) starts the standard bourne sh(1) when I start typing which shell to use. It spits out messages about interrupts (rerouting?) on the console when I start to type. When I'm loged in then, these messages do not occur any more.
  • I have built the graphics/drm-fbsd12.0-kmod on 12.2, also the firmware module and x11-drivers/xf86-video-intel on that running system, but still I can't start X and definitely the vt text console is not in graphics mode. I get kernel: drmn0: <drmn> on vgapci0, but not those messages like on 12.1:
    Code:
    kernel: [drm] Connector eDP-1: get mode from tunables:
    ...
    kernel: [drm] Initialized i915 1.6.0 20171222 for drmn0 on minor 0
    kernel: VT: Replacing driver "efifb" with new "fb".
    I built those three from the quarterly branch of the ports(7) tree; I checked that the version in latest is the same.
  • dbus-daemon(1) dumps core on a segfault, and vnstatd(8) has a segmentation fault, too (no core dump).
I will now try with minimal {loader,rc,sysctl}.conf, and rebuild kernel & world with that new compiler. Nevertheless, I appreciate any hints how to to fix this mess.
 
The laptop of my SO (Pentium T2390 / 965G GPU) also acted up after latest updates and I couldn't get acceleration to work at all.

What confused me first was the fact that even when using the xf86-video-intel driver, the i915kms module is still loaded/needed and everytime shortly after the module was loaded the GPU hung (-> errors in Xorg log and messages) and the screen turned black.

It seems there have been some vital patches to the i915kms module regarding older GPUs, but they will only land in FreeBSD 13. So for now my solution was to build drm-fbsd12.0-kmod from ports (the one from pkg/base didn't work at all) and use the intel driver with Acceleration disabled via xorg.conf. This was the only combination/variant that worked without a hanging GPU and black screen. The system is only used for checking mails and some light browsing, so missing hardware acceleration is no big deal...
 
[...] What confused me first was the fact that even when using the xf86-video-intel driver, the i915kms module is still loaded/needed and everytime shortly after the module was loaded the GPU hung (-> errors in Xorg log and messages) and the screen turned black. [...]
Xorg's intel(4) is the userland's driver which needs to "talk" to the kernel driver from graphics/i915kms.

Update about my progress, which may also be useful for others who experience strange failures on an upgrade between FreeBSD releases:
  • A check with freebsd-update IDS on the new system showed a differing checksum for numerous binary executables (in /sbin, /bin, /usr/sbin, /usr/bin, /lib, /usr/lib, /libexec & /usr/libexec).
  • This means the upgrade failed, and has to be done again on a newly cloned BE from the previous BE. The failed BE can be deleted.
  • UPDATE: I did the upgrade again on a freshly cloned boot environment: bectl mount it, mount a devfs(5) & chroot(8) into it, & then do freebsd-update -r <x.y-BRANCH> upgrade inside the chroot(8). This time I checked it after all was done... ;) (naturally many configuration files differ, but no binaries).
Code:
freebsd-version; uname -U
12.2-RELEASE-p3
1202000
Writing this from the new release after building graphics/drm-fbsd12.0-kmod from quarterly ports(7). Why don't the maintainers provide a package named graphics/drm-fbsd12.2-kmod which supercedes the 12.0 version???
 
Last edited:
I get the GPU hung message occasionally when watching videos only workaround was to relogin and reload the session. I'm able to reproduce the same black screen if I ran cheese but is fine if I load the newer i915 kms, it doesn't support my old 965GM chipset as I can't get my native resolution to work.

Now I've enabled DRI 3 and see if there any other changes. I'll try to disable DRI & accel method if I'm getting the same problem then I'll add to disable triplebuffer after that.
 
Back
Top