drm-515-kmod kernel panic on alder lake

Hello,

On a fresh install of 14.0-ALPHA3 on a ThinkPad T16 with Alder Lake
i7-1255U, the i915kms module, or more specific the alder lake firmware
(i915_adlp_dmc_bin.ko), causes a kernel panic/crash when it is loaded.

With debug.debugger_on_panic=1 the system hangs forever and needs to be
shut down forcefully; with =0 it reboots and I get the following log
entry:

Aug 29 10:12:00 hal9000 kernel: Fatal trap 12: page fault while in
kernel mode Aug 29 10:12:00 hal9000 kernel: cpuid = 1; apic id = 01
Aug 29 10:12:00 hal9000 kernel: fault virtual address   =
0xffffffff84166ed0 Aug 29 10:12:00 hal9000 kernel: fault code
   = supervisor read instruction, protection violation Aug 29 10:12:00
hal9000 kernel: instruction pointer     = 0x20:0xffffffff84166ed0 Aug
29 10:12:00 hal9000 kernel: stack pointer           =
0x28:0xfffffe00c4954ac8 Aug 29 10:12:00 hal9000 kernel: frame pointer
        = 0x28:0xfffffe00c4954dc0 Aug 29 10:12:00 hal9000 kernel: code
segment            = base 0x0, limit 0xfffff, type 0x1b Aug 29 10:12:00
hal9000 kernel:                         = DPL 0, pres 1, long 1, def32
0, gran 1 Aug 29 10:12:00 hal9000 kernel: processor eflags        =
interrupt enabled, resume, IOPL = 0 Aug 29 10:12:00 hal9000 kernel:
current process         = 0 (firmware taskq) Aug 29 10:12:00 hal9000
kernel: rdi: 0000000300000001 rsi: ffffffff84166e78 rdx:
0000000000000000 Aug 29 10:12:00 hal9000 kernel: rcx: 0000000003100000
r8: 0000000000000004  r9: ffffffff814f3d80 Aug 29 10:12:00 hal9000
kernel: rax: ffffffff84166f20 rbx: fffff8029ba94780 rbp:
fffffe00c4954dc0 Aug 29 10:12:00 hal9000 kernel: r10: ffffffff8415b023
r11: ff8899a091969da0 r12: ffffffff816d7c68 Aug 29 10:12:00 hal9000
kernel: r13: fffffe00c4954e10 r14: fffffe001f93be40 r15:
ffffffff84166f18 Aug 29 10:12:00 hal9000 kernel: trap number
 = 12 Aug 29 10:12:00 hal9000 kernel: panic: page fault Aug 29 10:12:00
hal9000 kernel: cpuid = 1 Aug 29 10:12:00 hal9000 kernel: time =
1693296652 Aug 29 10:12:00 hal9000 kernel: KDB: stack backtrace: Aug 29
10:12:00 hal9000 kernel: #0 0xffffffff80b8fbfd at kdb_backtrace+0x5d
Aug 29 10:12:00 hal9000 kernel: #1 0xffffffff80b42d02 at vpanic+0x132
Aug 29 10:12:00 hal9000 kernel: #2 0xffffffff80b42bc3 at panic+0x43 Aug
29 10:12:00 hal9000 kernel: #3 0xffffffff8100b81c at trap_fatal+0x40c
Aug 29 10:12:00 hal9000 kernel: #4 0xffffffff8100b86f at
trap_pfault+0x4f Aug 29 10:12:00 hal9000 kernel: #5 0xffffffff80fe1f58
at calltrap+0x8 Aug 29 10:12:00 hal9000 kernel: #6 0xffffffff80b0dde3
at linker_reference_module+0xe3 Aug 29 10:12:00 hal9000 kernel: #7
0xffffffff80b8ba4f at loadimage+0x1f Aug 29 10:12:00 hal9000 kernel: #8
0xffffffff80ba54f2 at taskqueue_run_locked+0x182 Aug 29 10:12:00
hal9000 kernel: #9 0xffffffff80ba6782 at taskqueue_thread_loop+0xc2 Aug
29 10:12:00 hal9000 kernel: #10 0xffffffff80afd46f at fork_exit+0x7f
Aug 29 10:12:00 hal9000 kernel: #11 0xffffffff80fe2fbe at
fork_trampoline+0xe


I already saw the thread on freebsd-current about a similar problem on
kabylake, where I found the hint to disabling debug.debugger_on_panic.
The modules/ports (graphics/gpu-firmware-intel-kmod@alderlake and
graphics/drm-515-kmod) have been built via poudriere last night from a
freshly cloned 'latest' ports tree. I also tried the packages from the
officiall repositories with the same result.

# uname -a
FreeBSD hal9000 14.0-ALPHA3 FreeBSD 14.0-ALPHA3 amd64 1400097 #0
stable/14-n265022-2af9390e54ed: Fri Aug 25 05:45:56 UTC 2023
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

# freebsd-version -urk
14.0-ALPHA3
14.0-ALPHA3
14.0-ALPHA3


Thanks,
Sebastian