# Upgrading to FreeBSD 12.1-RELEASE - resolving an issue with drm-fbsd12.0-kmod



## obsigna (Nov 4, 2019)

I just upgraded a desktop system from FreeBSD 12.0 to 12.1-RELEASE. Usually a minor upgrade does not require re-installation of 3rd-party software. This is an i7-7700 system and graphics/drm-kmod was installed and /boot/modules/i915kms.ko was activated. After said upgrade, the system did not boot anymore, but crashed when loading the i915kms.ko module.

In order to resolve the problem, I rebooted into single user mode, and reinstalled graphics/drm-kmod by building from the ports. After this the system booted fine and everything were back to normal. Reinstalling from packages did not work.


----------



## trev (Nov 4, 2019)

It is worth keeping an eye on the -STABLE mailing list. This was discussed a few days ago.


----------



## Phishfry (Nov 4, 2019)

Yes right here they discuss the DRM problems:


			12.1-RELEASE schedule update


----------



## xtaz (Nov 5, 2019)

It's in the errata: https://www.freebsd.org/releases/12.1R/errata.html#open-issues


----------



## obsigna (Nov 5, 2019)

Note, my message was not meant to be a moaning. I ran into a problem and I easily fixed it, and I thought it might be useful to others to tell how. Nonetheless, your comment's relevance is of philosophic nature of course, namely: _"Afterwards, we are always brighter." _


----------



## userxbw (Nov 5, 2019)

that clued me in... after the cat got away from the barking dog .. but still... it clued me in...


----------



## mittnickmini (Nov 5, 2019)

I have the same problem! I will try to rebuild drm-kmod from port.

Edit: Thank you very much obsigna! Recompile drm-kmod from ports works!


----------



## drozdowsky (Nov 8, 2019)

Same problem. Reinstalling drm-kmod did not do a thing.
Currently using kernel.old before this gets fixed :< (someone compiles it for 12.1)


----------



## SirDice (Nov 8, 2019)

Note that graphics/drm-kmod doesn't install anything of itself. It's simply a convenient package that installs other packages depending on the version of FreeBSD you have. Removing graphics/drm-kmod itself doesn't actually remove anything.

You should remove graphics/drm-fbsd12.0-kmod, this will also remove graphics/drm-kmod. Then rebuild graphics/drm-kmod.


----------



## drozdowsky (Nov 8, 2019)

Yes you are right..., I have done 'pkg clean -a && pkg upgrade -f' (I was googling for solutions and found that answer probably made by you  )


----------



## SirDice (Nov 8, 2019)

The "problem" right now is that the standard package repositories are still being built based on 12.0. For 99% of the packages this is not a problem but kernel modules are always tricky. This will change when 12.0 is EoL, then the default package repositories will be switched to 12.1.

If you want to keep using packages you can, temporarily, switch to the release_1 repository. Those are specifically built for 12.1. If you want to take that route, create a /usr/local/etc/pkg/repos/FreeBSD.conf:

```
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_1"
}
```

One thing to note though, release_1 is based on latest, there's no quarterly for it.


----------



## drozdowsky (Nov 8, 2019)

Created that file, pkg update && pkg clean -a && pkg remove drm-kmod && pkg autoremove && pkg install drm-kmod
Same boot loop, is it possible that no one build it for 12.1? Curious question: why is this not a default? If package is built on my version fetch it otherwise go for x.0, asking for more knowledge


----------



## blackhaz (Nov 8, 2019)

You have the latest ports tree, right? You did "portsnap fetch update"?


----------



## drozdowsky (Nov 9, 2019)

blackhaz said:


> You have the latest ports tree, right? You did "portsnap fetch update"?


Yes but how is that related?
I haven't built a port, I want to have it in package.


----------



## blackhaz (Nov 9, 2019)

Try building it from port. That's what worked for me (still with bugs though, as it appears either the drm-kmod or intel video driver is broken.) I think the 12.1 release has broken drm-kmod package.


----------



## userxbw (Nov 9, 2019)

Broken. How so? Not that I'd know how to fix it, Just curious. Because I just went to /usr/ports/graphics/drm-kmod sudo / or # make install clean then in the rc.conf added kld_list="/boot/modules/i915kms.ko"  reboot, no problems.

This was/is a fresh install not upgrade. this is a Broadwell generation chip I have. Intel® HD Graphics 5500

Is not the fbsd12.0-kmod a general purpose, and why wouldn't one find out what chip/card they got and curtail installing a driver for that only? Its nice to have if one does not know, but install, find out then add the specific one ???

the graphics/drm-fbsd12.0-kmod says,



> amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components. Currently corresponding to Linux 4.16 DRM. This version is for FreeBSD 12.0. amdgpu and radeonkms are known to fail with EFI boot.


----------



## hpc (Nov 9, 2019)

I can confirm that there is a regression somewhere  I've upgraded a laptop (from 12.0 to 12.1) which had the drm-fbsd problem.  I've tried every proposition from this thread:

building from ports (with an uptodate port tree)
install from release_1 repository (pkg update && pkg clean -a && pkg remove drm-kmod && pkg autoremove && pkg install drm-kmod
None works. As soon as the module load, the system reboot.

My workaround is to use xf86-video-scfb instead.

I can live with that, except for the hdmi output which is no more recognized.

For the record (extracted from lspci -lv)
vgapci0@pci0:0:2:0: class=0x030000 card=0x51081558 chip=0x22b18086 rev=0x21 hdr=0x00
vendor = 'Intel Corporation'
device = 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller'
class = display
subclass = VGA


----------



## blackhaz (Nov 9, 2019)

userxbw, after upgrading to FreeBSD 12.1 I am experiencing occasional atomic update failure messages in the log, as well as unusually high CPU load - even when I am simply moving the mouse pointer around the screen. Sometimes the scrolling doesn't work in some applications and requires a reboot to fix - occurs sporadically. I've tried building drm-kmod and xf86-video-intel from ports, different X settings - with no luck. There were no issues like these on FreeBSD 11.2, so it must be something either with drm-kmod or xf86-video-intel. I have Thinkpad X1 Yoga 1st Gen -  Intel(R) HD Graphics 520 (Skylake GT2).

I keep finding threads online (Linux-related as well) with people complaining about similar issues, but no answers so far, e.g.:





						105537 – [CI] [SKL only] igt@*@* - dmesg-warn - *ERROR* Potential atomic update failure on pipe A
					






					bugs.freedesktop.org
				




SOLUTION: Just figured a solution. It turns out that I have had an old /usr/local/etc/X11/xorg.conf.d/xorg.conf which used xf86-video-intel driver. Apparently, this configuration was running fine on 11.2 but I guess caused some kind of a "race condition" with drm-kmod under 12.1. I have removed xorg.conf from the system. Next, I did pkg remove xf86-video-intel, so only drm-kmod will handle the graphics. So far so good: CPU usage is normal, all Chromium rendering artefacts are gone, acceleration seems to work.


----------



## Polka2019 (Nov 17, 2019)

I especially made an account to ask about this issue... With this thread I already managed to solve the issue, but I will share my experience nonetheless.

My system is an Intel NUC8i3BEK, with an i3 8109u and Intel Iris Plus 655 graphics. Following this explanation on Intel integrated graphics I used drm-next-kmod from ports. After upgrading to 12.1 I was unable to compile this module. Strangely enough drm-kmod did compile and also worked. My system is functioning properly again!


----------



## dkh (Nov 23, 2019)

I got bit by this as well. 

I appreciate that it was in the errata but give the nature of the problem it seems like maybe this should have been a much more prominent warning or perhaps even worthy of delaying the release. This wasn't fringe use case, I assume there are a healthy percentage of installs that  rely on these.


----------



## Polka2019 (Nov 26, 2019)

Last Saturday I updated a few packages (not paying too much attention to which ones) and things broke again. Eventually I have been able to block loading the kernel module. The system boots again, but this is rather frustrating. Now I lack the opportunity to start the KDE environment and I don't feel comfortable in investing time to solve the issue. Not sure when things will break again if I manage to fix things.. 

To be complete: I tried compiling the module again, but this didn't work out.


----------



## golpemortal (Nov 27, 2019)

I used drm-kmod that I compile from port and after a pkg upgrade it installed drm-fbsd12.0-kmod-4.16.g20191120 and after rebooting it caused my laptop to loop into a reboot... I log into single user and remove drm-kmod and drm-fbsd12.0-kmod-4.16.g20191120 and then rebuild drm-kmod and then I locked the package drm-fbsd12.0-kmod-4.16.g20191120 to prevent it from installing again.

#pkg lock drm-fbsd12.0-kmod-4.16.g20191120

now I can run pkg upgrade on my laptop and now my ThinkPad T550 is running great. Hope this will help others.


----------



## SirDice (Nov 27, 2019)

This misery will all be over soon. When 12.0 is EoL'ed the package repositories will be built based on 12.1. This will probably happen some time early January.


----------



## MathieuV (Nov 28, 2019)

Ive wasted a few hours on this one til I come here. compiling and installing from port fixed it.


----------



## obsigna (Nov 28, 2019)

This is an excellent example on why „Dual mode maintenance of port and binary packages“ actually does work and does even work better, and that despite the notorious warnings that it is dangerous. On my FreeBSD 12.1-RELEASE desktop machines, I upgrade the vast majority of software and among this the real big bummers from binary packages, and only some hand selected software by the way of building from the ports. Since my initial post in this thread, it was clear to me, that in the foreseeable future drm-kmod needs to be maintained by compiling from the ports, and therefore, I added this to my upgrade script. Needless to say, that the last week’s update of drm-fbsd12.0-kmod did not adversely affect my systems:

```
#!/bin/sh

### the list of the ports that shall be updated from sources
portslist="\
security/cyrus-sasl2 \
devel/subversion \
devel/git \
graphics/drm-fbsd12.0-kmod \
net/netatalk3 \
net/samba48 \
www/closure-compiler \
www/yuicompressor \
"

### fetching FreeBSD system updates
/usr/bin/printf "Fetching FreeBSD system updates...\n"
PAGER=/bin/cat
/usr/sbin/freebsd-update fetch

### fetching updates of the FreeBSD ports tree
/usr/bin/printf "\nFetching updates of the FreeBSD ports tree...\n"
/usr/sbin/portsnap fetch update
/usr/sbin/pkg version -v
/usr/sbin/pkg updating -d `date -v-2w +%Y%m%d`

### ask and in case of y|Y run the updating processes
/usr/bin/printf "\nDo you want to continue (y/n)? "
save_stty_state=$(stty -g); stty raw -echo; answer=$(head -c 1); stty $save_stty_state
if echo "$answer" | grep -iq "^y" ; then
   /usr/bin/printf "\n\n"
   /usr/sbin/pkg update

   portmake=""
   pkgslist="`/usr/sbin/pkg query %o`"
   for port in $portslist ; do
      for pkg in $pkgslist ; do
         if [ "$pkg" == "$port" ] ; then
            continue 2
         fi
      done

      portmake="$portmake $port"
   done

   pkgslist=""
   outdated=`/usr/sbin/pkg version -l\< | /usr/bin/cut -f1 -w`
   for outd in $outdated ; do
      for port in $portslist ; do
         if [ "$port" == "`/usr/sbin/pkg query %o $outd`" ] ; then
            portmake="$portmake $port"
            continue 2
         fi
      done

      pkgslist="$pkgslist `/usr/sbin/pkg query %n $outd`"
   done

   pkgupgrd=""
   outdated=`/usr/sbin/pkg version -RU -l\< | /usr/bin/cut -f1 -w`
   for outd in $outdated ; do
      outd=`/usr/sbin/pkg query %n $outd`
      for pkg in $pkgslist ; do
         if [ "$pkg" == "$outd" ] ; then
            pkgupgrd="$pkgupgrd $outd"
            continue 2
         fi
      done
   done

   /usr/bin/printf "\nUpdating binary packages...\n"
   if [ "$pkgupgrd" != "" ] ; then
      /usr/sbin/pkg upgrade -U $pkgupgrd
   else
      echo "All installed packages are up-to-date."
   fi

   /usr/bin/printf "\nUpdating ports...\n"
   if [ "$portmake" != "" ] ; then
      for port in $portmake ; do
         echo "$port"
      done

      ### ask and in case of y|Y run the updating processes
      /usr/bin/printf "\nDo you want to continue (y/n)? "
      save_stty_state=$(stty -g); stty raw -echo; answer=$(head -c 1); stty $save_stty_state
      /usr/bin/printf "\n\n"
      if echo "$answer" | grep -iq "^y" ; then
         cwd=$PWD
         py="py36-"

         for port in $portmake ; do
            cd "/usr/ports/$port"
            /usr/bin/make deinstall clean
            if [ "${port#$py}" != "$port" ]; then
               /usr/bin/make FLAVOR=py36 install clean
            else
               /usr/bin/make install clean
            fi
         done

         cd "$cwd"
      fi
   else
      echo "All installed ports are up-to-date."
   fi

   /usr/bin/printf "\nCleaning up...\n"
   /usr/sbin/pkg clean -ay

   /usr/bin/find /usr/ports/distfiles -type f -mtime +4w -delete
   /usr/bin/find /usr/ports/distfiles -type d -depth +0 -and -empty -delete

else

   /usr/bin/printf "\n\n"

fi
```


----------



## justinnoor (Dec 23, 2019)

So on a clean install of 12.1 onwards graphics/drm-kmod is good to go?


----------



## SirDice (Dec 24, 2019)

The official packages are still being built for 12.0. If you build it from ports you should be fine.


----------



## MasterOne (Jan 6, 2020)

Hopefully this specific situation is unique and will not repeat itself. I mean it's kind of awkward seeing such an issue with a FreeBSD Release. Consistency is one of the points that made me come over from the Linux world.

I have been hit by the very same problem during my first current FreeBSD installation on my laptop, not knowing about it because not having looked at the errata or mailing list (of course my bad, these are things I just have to get used to).

12.0R will be EOL at the beginning of February 2020, so another month to go with building graphics/drm-fbsd12.0-kmod from ports, which was no problem at all and immediately fixed the issue.

obsigna nice upgrade script btw! I really have to get into scripting again.


----------



## blackhaz (Jan 6, 2020)

"Only the penitent men will pass..." 

I wonder how many brave souls FreeBSD is putting off at the moment. It literally ships with broken "GUI experience" for multiple months. I, honestly, don't understand this decision to wait until the EOL of 12.0. Sometimes we boast about it being a very dependable and reliable system, sometimes we prefer to pretend FreeBSD has nothing to do with the ports collection, or, at least, it may appear so to the newcomers.


----------

