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

On 9/2/26 02:43, Fabian Keil wrote:
> 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.

Quoting Konstantin Belousov when he corrected me after stating something
that at least implied such about __FreeBSD_version use:

QUOTE (dev-commits-src-main@freebsd.org 2024-Oct-06)
Anyway, __FreeBSD_version is not about compatibility between specific
snapshot of kernel and user sources.  It de-facto provides two technical
measures:
1. kernel refuses to load modules built against headers set with higher
  __FreeBSD_version than kernel
2. Some values of __FreeBSD_version are used by userspace to
  detect if specific change is present in kernel.  See sys/param.h
  P_OSREL_ list.
END QUOTE

(Note: If you go looking at the related messages, kib accidentally
stated something backwards earlier in the exchange. Read to the end of
the exchange to be sure to see the correction related notes.)

> 
> Fabian
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com