Kernel panic in "ath0 taskq" after binding OPTn to ath0_wlan2
-
Any news on the topic? I found several similar threads, but none of them concluded with a solution; this one seems to be the most recent.
pfSense Wireless Interfaces table indicates that it is not unusual for Atheros cards to support multi-hostap mode. Since my router machine uses a D-Link DWL-G520 (Atheros 5212) for WLAN operation, I decided to give it a try and create a secondary WLAN with less strict authentication. My steps were:
- Create the second wireless interface — ath0_wlan2.
- Create an additional network interface — OPT5, which was listed as bound to ath0 (because it is the first item in the list).
- Select ath0_wlan and press the Save button.
- pfSense immediately starts printing tons of text onto framebuffer console, then reboots (without beeping), and then suggests to submit crash report for further investigations — without giving me any clues on what exactly has just happened.
This is always reproducible, so I looked into the last dump and saw the following:```
.....
curthread = 0xc3ad8280: pid 0 "ath0 taskq"
.....
Tracing pid 0 tid 64028 td 0xc3ad8280
ieee80211_free_node(c5f3c000,9,ffffffff,0,0,...) at ieee80211_free_node+0x12
ath_newstate(c3cdb000,5,ffffffff,c3a99c54,e605bc9c,...) at ath_newstate+0x2b0
ieee80211_newstate_cb(c3cdb000,4,0,c12ce3fc,0,...) at ieee80211_newstate_cb+0xaa
taskqueue_run(c3ada440,c3ada458,0,c0edc643,0,...) at taskqueue_run+0x89
taskqueue_thread_loop(c3adc074,e605bd38,4,0,10000224,...) at taskqueue_thread_loop+0x45
fork_exit(c0a77de0,c3adc074,e605bd38) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe605bd38, ebp = 0 ---
.....
..... {skipped to line 1490 out of 3253}
.....
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc42d2008
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0b3f542
stack pointer = 0x28:0xe605bbec
frame pointer = 0x28:0xe605bc0c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (ath0 taskq)
Textdump complete.
..... -
I split this post off since it wasn't really related to the old thread (similar behavior but it's a different driver) and it wouldn't get much attention in an old thread.
This is probably because that specific card doesn't support multiple access points. Unfortunately there isn't a way to probe the cards to test support, only to try and fail (spectacularly in this case).
If there is any bug, it's a driver bug, and there isn't likely to be anything we can do for that. We are working on getting pfSense 2.1 out, and it will be based on FreeBSD 8.3, so there is some hope that it will be improved there.
That said, if it's just lack of support in the chip, it may still panic, and there may be nothing we can do for that.
