Bug 230785 - Page fault when if_ath module is unloaded
Summary: Page fault when if_ath module is unloaded
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
Keywords: panic
Depends on:
Reported: 2018-08-20 21:02 UTC by Ali Abdallah
Modified: 2020-06-11 20:14 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ali Abdallah 2018-08-20 21:02:32 UTC
When compiling if_ath as a module. kldload if_ath followed by kldunload if_ath causes a page fault. The chip is AR9380.

[ath] unloaded
[ar5210] unloaded
[ar5211] unloaded
[ar5416] unloaded
[ar5212] unloaded
[ar9300] unloaded
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex ath0 (ath0) r = 0 (0xfffffe004eea0190) locked @ /usr/src/sys/dev/ath/if_ath.c:1423
stack backtrace:
#0 0xffffffff8044a2b3 at witness_debugger+0x73
#1 0xffffffff8044b691 at witness_warn+0x461
#2 0xffffffff806ce093 at trap_pfault+0x53
#3 0xffffffff806cd6aa at trap+0x2ba
#4 0xffffffff806a84a5 at calltrap+0x8
#5 0xffffffff81d4c745 at ath_pci_detach+0x95
#6 0xffffffff80416d27 at device_detach+0x167
#7 0xffffffff8041629f at devclass_driver_deleted+0x4f
#8 0xffffffff804161ad at devclass_delete_driver+0x8d
#9 0xffffffff8041bc9f at driver_module_handler+0x10f
#10 0xffffffff803c3c52 at module_unload+0x32
#11 0xffffffff803b65cb at linker_file_unload+0x23b
#12 0xffffffff803b695c at linker_file_unload+0x5cc
#13 0xffffffff803b782d at kern_kldunload+0xcd
#14 0xffffffff806ce9c1 at amd64_syscall+0x281
#15 0xffffffff806a8d8d at fast_syscall_common+0x101

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0xffffffff81cb3180
fault code		= supervisor read instruction, page not present
instruction pointer	= 0x20:0xffffffff81cb3180
stack pointer	        = 0x28:0xfffffe004e249708
frame pointer	        = 0x28:0xfffffe004e249730
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		= 701 (kldunload)
Comment 1 Ali Abdallah 2020-06-11 19:55:55 UTC
I had a closer look into the issue I'm having. The detaching order of the various if_ath* and ath* modules is broken.

#0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:234
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0xffffffff802f5a4b in db_dump (dummy=<optimized out>, dummy2=<optimized out>, dummy3=<unavailable>, dummy4=<unavailable>) at /usr/src/sys/ddb/db_command.c:574
#3  0xffffffff802f5819 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=1) at /usr/src/sys/ddb/db_command.c:481
#4  0xffffffff802f5594 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534
#5  0xffffffff802f87ef in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:252
#6  0xffffffff80431e2a in kdb_trap (type=3, code=0, tf=0xfffffe003d985100) at /usr/src/sys/kern/subr_kdb.c:693
#7  0xffffffff806d59dc in trap (frame=0xfffffe003d985100) at /usr/src/sys/amd64/amd64/trap.c:621
#8  <signal handler called>
#9  kdb_enter (why=0xffffffff8079127e "panic", msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:479
#10 0xffffffff803e586a in vpanic (fmt=<optimized out>, ap=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:866
#11 0xffffffff803e56a3 in panic (fmt=0xffffffff80865248 <vt_conswindow+16> "m\201y\200\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:804
#12 0xffffffff8067fae7 in vm_fault_hold (map=0xfffff80002001000, vaddr=<optimized out>, fault_type=4 '\004', fault_flags=<optimized out>, m_hold=0x0)
    at /usr/src/sys/vm/vm_fault.c:614
#13 0xffffffff8067d4b0 in vm_fault (map=0xfffff80002001000, vaddr=<optimized out>, fault_type=4 '\004', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:562
#14 0xffffffff806d5ff4 in trap_pfault (frame=0xfffffe003d985590, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:846
#15 0xffffffff806d54cf in trap (frame=0xfffffe003d985590) at /usr/src/sys/amd64/amd64/trap.c:443
#16 <signal handler called>
#17 0xffffffff811bf0c0 in ?? ()
#18 0xffffffff810b157a in ath_intr (arg=0xfffffe00003e4000) at /usr/src/sys/dev/ath/if_ath.c:2106
#19 0xffffffff803af284 in intr_event_execute_handlers (p=<optimized out>, ie=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1129
#20 ithread_execute_handlers (p=<optimized out>, ie=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1142
#21 ithread_loop (arg=<optimized out>) at /usr/src/sys/kern/kern_intr.c:1222
#22 0xffffffff803abdc3 in fork_exit (callout=0xffffffff803af0b0 <ithread_loop>, arg=0xfffff800027e94c0, frame=0xfffffe003d985ac0) at /usr/src/sys/kern/kern_fork.c:1065
#23 <signal handler called>

(kgdb) frame 18
#18 0xffffffff810b157a in ath_intr (arg=0xfffffe00003e4000) at /usr/src/sys/dev/ath/if_ath.c:2106
2106		if (!ath_hal_intrpend(ah)) {		/* shared irq, not for us */

(kgdb) print ah->ah_isInterruptPending
$1 = (HAL_BOOL (*)(struct ath_hal *)) 0xffffffff811bf0c0

# kldstat 
Id Refs Address                Size Name
 1   79 0xffffffff80200000   e81700 kernel
 4   11 0xffffffff81089000    1c890 ath_hal.ko
 5    3 0xffffffff810a6000    60c40 ath_main.ko
 6    3 0xffffffff81107000     1c20 ath_dfs.ko
 7    9 0xffffffff81109000    aea68 wlan.ko
 8    3 0xffffffff811b8000     6688 ath_rate.ko
 9    2 0xffffffff811bf000    8ad98 ath_hal_ar9300.ko
10    2 0xffffffff8124a000    52058 ath_hal_ar5416.ko
11    3 0xffffffff8129d000    39578 ath_hal_ar5212.ko
12    2 0xffffffff812d7000    15d38 ath_hal_ar5211.ko
13    2 0xffffffff812ed000    10938 ath_hal_ar5210.ko

The 0xffffffff811bf0c0 (ar9300_is_interrupt_pending) belongs to the module (ath_hal_ar9300) that has been just unloaded.
Comment 2 Adrian Chadd freebsd_committer 2020-06-11 20:14:45 UTC
yeah I noticed this again recently. I think I messed up when I did the initial transition thing with the if_ath modules.

Lemme go see if there's an easy way to fix this or not..