Re: linuxkpi: Panic while loading old i915kms after kernel update

Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote on 2026-08-30 at 01:00:05:

> On Sat, 29 Aug 2026 13:51:27 +0200
> Fabian Keil <freebsd-listen@fabiankeil.de> wrote:
> 
> > After updating the kernel on an ElectroBSD system previously
> > based on stable/15 6840f9362f28 to a system based on 132e609c2ce5c
> > without rebuilding graphics/drm-61-kmod the system reproducibly
> > panics on boot while the modules from the port are loaded:
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 02
> > fault virtual address	= 0x28
> > fault code		= supervisor read data, page not present
> > instruction pointer	= 0x20:0xffffffff80a10d3c
> > stack pointer	        = 0x28:0xfffffe00be1eed00
> > frame pointer	        = 0x28:0xfffffe00be1eed20
> > processor eflags	= resume, IOPL = 0
> > current thread		= 12/100815 (intr/irq38: vgapci0)
> > rdi: 0000000000000000 rsi: 0000000000000003 rdx: 0000000000000000
> > rcx: fffff80033faf780  r8: 0000000002310000  r9: fffff8001908d000
> > rax: 0000000000000000 rbx: fffffe008a768520 rbp: fffffe00be1eed20
> > r10: 0000000000000000 r11: 0000000000002af8 r12: 0000000000000003
> > r13: 000000008cbc8585 r14: 0000000000000000 r15: 0000000000000003
> > panic: page fault
> > cpuid = 2
> > time = 1788002731
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x36/frame 0xfffffe00be1eea40
> > vpanic() at vpanic+0x149/frame 0xfffffe00be1eeb70
> > panic() at panic+0x43/frame 0xfffffe00be1eebd0
> > trap_pfault() at trap_pfault+0x3a8/frame 0xfffffe00be1eec30
> > calltrap() at calltrap+0x8/frame 0xfffffe00be1eec30
> > --- trap 0xc, rip = 0xffffffff80a10d3c, rsp = 0xfffffe00be1eed00, rbp = 0xfffffe00be1eed20 ---
> > autoremove_wake_function() at autoremove_wake_function+0x1c/frame 0xfffffe00be1eed20
> > linux_wake_up() at linux_wake_up+0xca/frame 0xfffffe00be1eed70
> > cpt_irq_handler() at cpt_irq_handler+0x94/frame 0xfffffe00be1eedb0
> > ilk_irq_handler() at ilk_irq_handler+0x435/frame 0xfffffe00be1eee40
> > lkpi_irq_handler() at lkpi_irq_handler+0x29/frame 0xfffffe00be1eee60
> > ithread_loop() at ithread_loop+0x239/frame 0xfffffe00be1eeef0
> > fork_exit() at fork_exit+0x7b/frame 0xfffffe00be1eef30
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00be1eef30
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > Uptime: 12s
> > Dumping 451 out of 8041 MB:..4%..11%..22%..32%..43%..54%..61%..71%..82%..93%
> > [...]
> > (kgdb) where
> > #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
> > #1  doadump (textdump=textdump@entry=1) at /usr/src/sys/kern/kern_shutdown.c:399
> > #2  0xffffffff8071a340 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:519
> > #3  0xffffffff8071a84d in vpanic (fmt=<optimized out>, ap=ap@entry=0xfffffe00be1eebb0) at /usr/src/sys/kern/kern_shutdown.c:974
> > #4  0xffffffff8071a693 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:887
> > #5  0xffffffff80b9a5f8 in trap_fatal (frame=<optimized out>, eva=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1031
> > #6  0xffffffff80b9a5f8 in trap_pfault (frame=0xfffffe00be1eec40, usermode=false, signo=<optimized out>, ucode=<optimized out>)
> > #7  <signal handler called>
> > #8  atomic_read (v=0x28) at /usr/src/sys/compat/linuxkpi/common/include/asm/atomic.h:90
> > #9  wake_up_task (task=0x0, state=3) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:123
> > #10 autoremove_wake_function (wq=0xfffffe008a768520, state=3, flags=<optimized out>, key=<optimized out>) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:191
> > #11 0xffffffff80a1120a in linux_wake_up (wqh=0xfffffe00bdacdb88, state=3, nr=0, locked=false) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:285
> > #12 0xffffffff82d55ed4 in cpt_irq_handler () from /boot/modules/i915kms.ko
> > #13 0xffffffff82d53e15 in ilk_irq_handler () from /boot/modules/i915kms.ko
> > #14 0x0000000000000000 in ?? ()
> > (kgdb) f 10
> > #10 autoremove_wake_function (wq=0xfffffe008a768520, state=3, flags=<optimized out>, key=<optimized out>) at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:191
> > 191		if ((ret = wake_up_task(task, state)) != 0)
> > (kgdb) l
> > 186	{
> > 187		struct task_struct *task;
> > 188		int ret;
> > 189	
> > 190		task = wq->private;
> > 191		if ((ret = wake_up_task(task, state)) != 0)
> > 192			list_del_init(&wq->task_list);
> > 193		return (ret);
> > 194	}
> > 195	
> > (kgdb) p *wq
> > $1 = {flags = 0, private = 0x0, func = 0xffffffff80a10d20 <autoremove_wake_function>, {task_list = {next = 0xfffffe00bdacdba8, prev = 0xfffffe00bdacdba8}, entry = {next = 0xfffffe00bdacdba8, prev = 0xfffffe00bdacdba8}}}
> > 
> > I suspect that rebuilding i915kms will work around the issue
> > but unless I miss something this shouldn't happen on a stable
> > branch.

Rebuilding the module worked around the issue as expected.

> If it shouldn't happen on stable, no LinuxKPI changes would be
> allowed, possibly including security fixes.
> 
> So anything depend on LinuxKPI should better rebuilt (including
> pre-built pkgs that are built against the exact same commit of
> kernel) to be safe. This applies to *-RELEASE-p*, too, if the patch
> releases contain fixes / new driver support helpers in LinuxKPI.
> 
> Or accept bloatedly sparse structs or any other data structure
> used for LinuxKPI (and strictly versioned symbols) to allow adding
> new entry without breaking backward compatibilities.
> 
> IIUC, official kmod pkg repo are prepared per minor RELEASEs.
> 
> So users of any supported stable branches, not only users of
> main branch, who uses kmods depending on LinuxKPI are strongly
> adviced to build the kmods locally using 100% in-sync /usr/src/sys
> with running kernel to be safest.

Thanks for the response.

I'm not saying that there should be no LinuxKPI changes in
stable branches but I'd expect a __FreeBSD_version bump when
incompatible changes are merged.

Fabian