radeonkms Causing Kernel Panic after 13.2-->13.3 Upgrade

After upgrading a workstation from 13.2 to 13.3-RELEASE via freebsd-update(8), I found upon reboot that the kernel would panic when attempting to load kernel modules. Here is a transcription of the error messages:

Code:
stack pointer                                    = <large hex value>
frame pointer                                    = <large hex value>
code segment                                     = base 0x0, limit 0xffffff, type 0x1b
                                                 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags                                 = interrupt enabled, resume IOPL = 0
current process                                  = 68038 (kldload)
trap number                                      = 12
panic: page fault
cpuid = 1
time = <boot time in epoch>
KBD: stack backtrace:
#0 <large hex value> at kdb_backtrace+0x65
#1 <large hex value> at vpanic+0x152
#2 <large hex value> at panic+0x43
#3 <large hex value> at trap_fatal+0x38d
#4 <large hex value> at trap_pfault+0x4f
#5 <large hex value> at calltrap+0x8
#6 <large hex value> at ttm_bo_validate+0xc8
#7 <large hex value> at ttm_bo_init_reserved+0x338
#8 <large hex value> at ttm_bo_init+0x5b
#9 <large hex value> at radeon_bo_create+0x194
#10 <large hex value> at radeon_ttm_init+0x3f
#11 <large hex value> at rv770_init+0x1a2
#12 <large hex value> at radeon_device_init+0xa60
#13 <large hex value> at radeon_device_driver_load_kms+0x139
#14 <large hex value> at drm_dev_register+0x148
#15 <large hex value> at radeon_pci_probe+0x283
#16 <large hex value> at linux_pci_attach_device+0x3d9
#17 <large hex value> at device_attach+0x3b5

I found a similar problem to mine described in Thread 92667. In that case, the OP was having trouble with the amdgpu kernel module provided by the drm-kmod package. I confirmed that the radeonkms module from that same package is the cause of my problem by doing the following:

0. Reboot the machine into the boot environment created when I ran freebsd-update.
1. Upgrade drm-kmod.
2. Reboot the machine, attempting to boot 13.3. Get stuck with the same kernel panic.
3. Reboot the machine in single user mode, disable kldlist="radeonkms" in /etc/rc.conf
4. Bring the machine up under 13.3-RELEASE. I take this as confirmation that radeonkms is the problem.

At this point, I finished the upgrade of base with the second freebsd-update install as the OP did, and then upgraded drm-kmod. At this point, the OP's problem was solved. In my case, though, even after upgrading drm-kmod, then all packages on the system, then re-installing all packages on the system, I still can't get the system to boot when loading radeonkms. The system is configured to fetch packages from the latest repo with this URL in the repo config file:

pkg+http://pkg.freebsd.org/${ABI}/latest

Question
=========

In thread Thread 92667, checkpoint said that he had the same problem as the OP, and that it was solved by recompiling the drm-kmod package. The only ways I know to do that on FreeBSD are to either (a) stand up my own package repo running 13.3-RELEASE to compile and package the port, or (b) start installing from ports on the workstation in question.

Both have drawbacks: (a) is more effort, and (b) forces me to re-tool. Are there any other options?

Thanks!
 
You can also wait until the official packages be compiled under 13.3, then and only then, do the minor version upgrade. I do that in general.

Another option is to have another machine and compile this port. Once done, you transfer the package to the computer that needs it.

What you saw for the drm-kmod software can be the same for all the 3rd party kernel modules you use. It's really annoying and catch people at each minor upgrade.
 
Thanks very much for confirming my options, Emrion. I've run FreeBSD on servers for a long while, but I can't remember ever having run third-party kernel modules from the FreeBSD Ports Collection. Is there a way to tell what OS a package was built on, or do you just wait until the minor release you're on has just left support? Running pkg search -f drm-kmod, I see it prints some metadata about the conditions under which the package was built, but not the version on which it was built. On the package's entry page on Freshports, I see discussion of which releases are supported, but it's up to the committer to include that information.
 
… other options? …

I use poudriere, locally, and allow it to download packages for as much as possible.

ports-mgmt/poudriere-devel allows further simplification: pkgbase as a method for creation of jails. Should be good during the 14.1 transition period.
 
Back
Top