From Newsgroup: muc.lists.freebsd.stable

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.

Fabian


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

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.

Fabian

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.

Regards.
--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Wed, 2 Sep 2026 11:43:03 +0200
Fabian Keil <freebsd-listen@fabiankeil.de> 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.

Fabian

Exactly.

But IIRC, I've heared that any changes requiring __FreeBSD_version
bump should be avoided on point releases (*-p*).
And it doesn't matter for stable/*, so bumps sometime happenes.
Currently, stable/15 got 2 bumps after post-branch updates
wrt releng/15.1.

Note that, when a set of commits are planned for specific area
(i.e., LinuxKPI), bump could be delayed until planned last commit
is done. And sometimes forgotton. So there can be time window
that a bump is wanted but not yet done.

Regards.
--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2