On my ThinkPad X201 (i915kms, i5 integrated) and ThinkPad x120e (radeonkms, Wrestler Radeon HD 6310), loading the ports drm modules via kld_list in rc.conf causes a panic during boot.
Legacy modules in /boot/kernel works fine.
This is a regression in 12.2-RC1. Using kld_list worked fine on both machines with 12.1-RELEASE.
Can you show us the kld_list lines you have in each instance of /etc/rc.conf please?
What happens if you build the modules locally?
(In reply to Niclas Zeising from comment #2)
Both work fine with kmods built from source. Do we have a KBI compatibility issue from 12.1 to 12.2? If not, why don't the binary packages work on 12.2-RC1?
(In reply to Jason W. Bacon from comment #4)
I can confirm that this also happens on my Core-2 Quad system, with a Radeon HD-6450 based graphics card.
When using the drm-fbsd12.0-kmod-4.16.g20200221 package on 12.1-RELEASE-p10 everything works as usual. After upgrading to 12.2-RC3 the system panics immediately on loading radeonkms.ko. I still get a stacktrace, but it is followed by a hard hangup, so no core dump is made.
It does not matter whether I put
in /etc/rc.conf or run
directly from the shell.
When I build drm-fbsd12.0-kmod-4.16.g20200221 locally from ports, the problem does not occur and the systems functions normally.
I wonder what an end user gets to see when installing 12.2-RELEASE once it is available and then attempts to use the package.
I think I ruled out a discrepancy in "pkg" vs "make install" behavior by generating and installing my own package:
pkg remove drm-kmod
pkg install /usr/ports/packages/all/drm-kmod*
Works fine with my package and I have no tweaks in my build env.
So it seems likely that the 12.1 package is incompatible with 12.2 and we're going to have a problem until bulk builds switch over to 12.2 unless this is corrected. That would mean 3 months that 12.2 users can't install drm-kmod via pkg or freebsd-update.
Has something been done to correct this? I just did a fresh 12.2-RELEASE install on a MacBook with both integrated Intel graphics and Radeon. The binary drm-kmod packages work fine with either GPU.
This is a well known problem. While the system ABI is fixed for the life of a major release, the KBI is not guaranteed stable. Specifically, there was a significant change in the lkpi code used for graphics drivers and, as a result, drm-*-kmod packages for 12.1 will not work on 12.2. Full stop!
The only solution is to build a package on a 12.2 system with the full sources for/usr/src/sys. (cd /usr/ports/graphics/drm-fbsd12.0-kmod && make package) Once that package is built (in /usr/ports/packages/All), it may be copied to other 12.2-RELEASE systems with the same arch with "pkg add".
This may apply to other ports that build kmods and the same issue hit virtualbox-ose-kmod in 11.something. I'm pretty sure I was bitten by one other case, but I don't recall when.
It seems like a trivial solution is to make a set of trusted packages of every kmod port for each minor release after .0, sign them, and make them available. I am still baffled why this has not happened.
(In reply to Jason W. Bacon from comment #7)
I have to retract the claim that the binary drm-kmod packages were working on my MacBook. I'm sure I was using modesetting successfully after the fresh install, but I did not confirm that it was using drm-kmod from ports. It may have failed to load it and later auto-loaded the legacy modules in /boot/kernel.
Since running freebsd-update, neither driver is working and it's falling back on scfb.
When trying to use the ati driver, there's a lot of chatter about Radeon in Xorg.0.log, but it ultimately fails and falls back to scfb. This may have been the case before the upgrade as well.
Loading i915kms built from source causes the console to freeze during boot. The system is still operational and tapping the power button shuts down gracefully.
At any rate, the scfb driver performs fine for my purposes.
I also wondered if we should generate packages for a new point release, just for special cases like this. Most of the 12.1 packages are fine on 12.2, but maybe we could tag ports like drm-kmod* to build separately on new point releases during the overlap period. I'm not sure we have the means to guarantee issues like this won't happen again in the future, so it would seem prudent to have processes in-place to mitigate it.