Bug 214422 - FreeBSD panic when you try to load if_iwm.ko via loader.conf
Summary: FreeBSD panic when you try to load if_iwm.ko via loader.conf
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-wireless mailing list
Depends on:
Reported: 2016-11-11 15:09 UTC by subbsd
Modified: 2016-11-18 08:20 UTC (History)
1 user (show)

See Also:

r308577 (447 bytes, patch)
2016-11-13 10:37 UTC, Andriy Voskoboinyk
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description subbsd 2016-11-11 15:09:23 UTC
uname -a:

FreeBSD test.my.domain 12.0-CURRENT FreeBSD 12.0-CURRENT #1 f16dfbd(drm-next-4.7)-dirty: Fri Nov 11 15:26:29 MSK 2016     root@test.my.domain:/usr/obj/usr/src/sys/GENERIC  amd64 

If module loaded via loader.conf ( if_iwm_load="YES" ) ,
FreeBSD panic:
iwm0: iwm_start_fw: failed 35
iwm0: failed to load init firmware

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x64
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80ab7f75
stack pointer = 0x20:0xffffffff824ee930
frame pointer = 0x20:0xffffffff824ee930
code segment = base rx0, limit 0xfffff, type 0x1b
                      = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
[ thread pid 0 tid 100000 ]
Stopped at taskqueue_drain+0x16: cmpl $0, 0x64(%r14)

May be missed some dependencies on this stage? When loading via kldload from multiuser mode - all fine. On my host, after kldload if_iwm, also iwm8000Cfw.ko has been loaded automatically
Comment 1 Andriy Voskoboinyk freebsd_committer 2016-11-13 10:37:27 UTC
Created attachment 176949 [details]

I think it was fixed in

You can try to apply the patch to your copy of drm-next branch -
as I can see it is not updated to this revision yet.
Comment 2 subbsd 2016-11-18 08:20:36 UTC
(In reply to Andriy Voskoboinyk from comment #1)

I confirm this. After applying path boot as usual. Thank!