Project

General

Profile

Actions

Regression #16237

open

Drivers that load firmware can cause a kernel panic.

Added by Steve Wheeler about 1 month ago. Updated 17 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
25.11
Release Notes:
Default
Affected Version:
2.8.0
Affected Architecture:
All

Description

In recent FreeBSD 15 builds drivers have been moving firmware out of the code to load it when it attaches. This affects drivers in 2.8 and 25.03.

If the firmware is not present and cannot be loaded it can cause a kernel panic.

Confirmed so far: iwlwifi(4), iwm(4), isp(4).

Drivers failing to attach should not cause a kernel panic.

See: https://forum.netgate.com/topic/197485/kernel-panic-when-upgrading-to-2-8-0-beta

Actions #1

Updated by Steve Wheeler about 1 month ago

If you are hitting this issue note the affected device if it's not listed above.

To work around it you can:
  • Remove or disable the device in the BIOS.
  • Disable it in pfSense using a loader hint.
    Create the file /boot/loader.conf.local. Add the appropriate line, for example: hint.iwm.0.disabled="1"
  • Interrupt the boot process to reach the loader prompt and set the hint there:
    set hint.iwm.0.disabled="1"
    boot
Actions #2

Updated by Steve Wheeler about 1 month ago

iwm0: <Intel(R) Dual Band Wireless AC 8265> mem 0xc1620000-0xc1621fff irq 21 at device 16.0 on pci6
iwm8265fw: could not load firmware image, error 6

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address    = 0x4
fault code        = supervisor read data, page not present
instruction pointer    = 0x20:0xffffffff80dc7ce4
stack pointer            = 0x28:0xfffffe004a60e9b0
frame pointer            = 0x28:0xfffffe004a60ea70
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 0 (firmware taskq)
rdi: 0000000000000001 rsi: fffffe004a60ed00 rdx: fffffe004a60ed00
rcx: fffffe004a60ed80  r8: fffffe004a60ed00  r9: 000000000000000f
rax: 0000000000000000 rbx: fffffe004a60ed00 rbp: fffffe004a60ea70
r10: fffff8000112c130 r11: 0000000000000c00 r12: fffffe004a60ea8c
r13: 0000000000000400 r14: fffffe004a60ed70 r15: fffffe004a60edb8
trap number        = 12
panic: page fault
cpuid = 0
time = 2
KDB: enter: panic
[ thread pid 0 tid 100030 ]
Stopped at      kdb_enter+0x33: movq    $0,0x1d76cd2(%rip)
db> bt
Tracing pid 0 tid 100030 td 0xfffff8000266d000
kdb_enter() at kdb_enter+0x33/frame 0xfffffe004a60e7d0
panic() at panic+0x43/frame 0xfffffe004a60e830
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe004a60e890
trap_pfault() at trap_pfault+0x46/frame 0xfffffe004a60e8e0
calltrap() at calltrap+0x8/frame 0xfffffe004a60e8e0
--- trap 0xc, rip = 0xffffffff80dc7ce4, rsp = 0xfffffe004a60e9b0, rbp = 0xfffffe004a60ea70 ---
cache_fplookup() at cache_fplookup+0x204/frame 0xfffffe004a60ea70
namei() at namei+0x104/frame 0xfffffe004a60ead0
vn_open_cred() at vn_open_cred+0x4ba/frame 0xfffffe004a60ec40
loadimage() at loadimage+0x23f/frame 0xfffffe004a60ee40
taskqueue_run_locked() at taskqueue_run_locked+0x182/frame 0xfffffe004a60eec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xc2/frame 0xfffffe004a60eef0
fork_exit() at fork_exit+0x7b/frame 0xfffffe004a60ef30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004a60ef30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Actions #3

Updated by Steve Wheeler about 1 month ago

  • Status changed from New to Confirmed

It's this bug in the upstream firmware API: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283285

Actions #4

Updated by Jim Pingle 17 days ago

  • Plus Target Version changed from 25.07 to 25.11
Actions

Also available in: Atom PDF