Bug #5453
closed
Wifi card using the ath driver running in hostap mode causes a panic when a client joins.
Added by Steve Wheeler about 9 years ago. Updated over 8 years ago.
0%
Description
I'm running 2.3alpha on an APU with the ath wifi card as an access point. Whenever I join the wifi network the APU crashes and reboots. After that I am able to use the wifi successfully though.
Testing using an Android tablet which is replicable.
I have many crash reports from this but in only one case did it actually show the ath driver as the current process.
Files
| apu_crash5.txt (386 KB) apu_crash5.txt | Steve Wheeler, 11/15/2015 10:35 AM |
Updated by Jim Thompson about 9 years ago
- Assignee set to Chris Buechler
crash dump actually shows that it's unrelated to ath
db:0:kdb.enter.default> bt
Tracing pid 12 tid 100030 td 0xfffff8000350e000
ether_nh_input() at ether_nh_input+0x84/frame 0xfffffe0043bbf9f0
netisr_dispatch_src() at netisr_dispatch_src+0x62/frame 0xfffffe0043bbfa60
re_rxeof() at re_rxeof+0x4ce/frame 0xfffffe0043bbfae0
re_intr_msi() at re_intr_msi+0x10b/frame 0xfffffe0043bbfb20
intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame 0xfffffe0043bbfb60
ithread_loop() at ithread_loop+0x96/frame 0xfffffe0043bbfbb0
Updated by Jim Pingle about 9 years ago
I turned on the ath interface in my APU and managed to replicate the crash multiple times as well. Same backtrace and panic string. Also an Android client but it's all I had handy at the moment (a phone, though)
Updated by Jim Pingle about 9 years ago
Got a slightly different one today -- same scenario: Panic on client association:
db:0:kdb.enter.default> bt Tracing pid 0 tid 100032 td 0xfffff8000348b4a0 ieee80211_find_rxnode_withkey() at ieee80211_find_rxnode_withkey+0xa2/frame 0xfffffe0034804a20 ath_rx_pkt() at ath_rx_pkt+0x387/frame 0xfffffe0034804a90 ath_rx_proc() at ath_rx_proc+0x2a6/frame 0xfffffe0034804b30 taskqueue_run_locked() at taskqueue_run_locked+0xe5/frame 0xfffffe0034804b80 taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfffffe0034804bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0034804bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0034804bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Tail end of the message buffer:
ath0_wlan0: discard frame w/o packet header
re1: discard frame w/o packet header
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0xffffffff80c0bef2
stack pointer = 0x28:0xfffffe00348049e0
frame pointer = 0x28:0xfffffe0034804a20
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 (ath0 taskq)
Updated by Chris Buechler about 9 years ago
- Status changed from New to Confirmed
It's not just client association, it has to actually try to send some traffic destined to the host. Doesn't have to be passed traffic though, blocking everything inbound on ath still results in the crash.
The one I seem to always get is:
db:0:kdb.enter.default> bt Tracing pid 0 tid 100032 td 0xfffff80003bf24a0 ieee80211_find_rxnode_withkey() at ieee80211_find_rxnode_withkey+0x7e/frame 0xfffffe0120443a20 ath_rx_pkt() at ath_rx_pkt+0x387/frame 0xfffffe0120443a90 ath_rx_proc() at ath_rx_proc+0x2a6/frame 0xfffffe0120443b30 taskqueue_run_locked() at taskqueue_run_locked+0xe5/frame 0xfffffe0120443b80 taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfffffe0120443bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0120443bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0120443bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Updated by Chris Buechler about 9 years ago
here's a couple diff new ones.
db:0:kdb.enter.default> bt Tracing pid 0 tid 100032 td 0xfffff80003bf24a0 m_tag_delete_chain() at m_tag_delete_chain+0x1f/frame 0xfffffe0120443980 mb_dtor_pack() at mb_dtor_pack+0x11/frame 0xfffffe0120443990 uma_zfree_arg() at uma_zfree_arg+0x3e/frame 0xfffffe0120443a00 m_freem() at m_freem+0x18/frame 0xfffffe0120443a20 ath_rx_pkt() at ath_rx_pkt+0x4ec/frame 0xfffffe0120443a90 ath_rx_proc() at ath_rx_proc+0x2a6/frame 0xfffffe0120443b30 taskqueue_run_locked() at taskqueue_run_locked+0xe5/frame 0xfffffe0120443b80 taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfffffe0120443bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0120443bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0120443bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db:0:kdb.enter.default> bt Tracing pid 0 tid 100032 td 0xfffff80003bf24a0 ath_tx_calc_duration() at ath_tx_calc_duration+0x2d/frame 0xfffffe01204439d0 ath_tx_tid_hw_queue_aggr() at ath_tx_tid_hw_queue_aggr+0x18e/frame 0xfffffe0120443ab0 ath_txq_sched() at ath_txq_sched+0xe8/frame 0xfffffe0120443af0 ath_txq_sched_tasklet() at ath_txq_sched_tasklet+0x16b/frame 0xfffffe0120443b30 taskqueue_run_locked() at taskqueue_run_locked+0xe5/frame 0xfffffe0120443b80 taskqueue_thread_loop() at taskqueue_thread_loop+0xa8/frame 0xfffffe0120443bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe0120443bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0120443bf0
Updated by Jim Thompson about 9 years ago
Do I dare suggest that we attempt to re-import net80211 and friends here?
Renato grabbed the last import a day after Adrian went nuts and backed out a ton of Gleb's changes.
Updated by Chris Buechler about 9 years ago
- Assignee changed from Chris Buechler to Renato Botelho
Jim Thompson wrote:
Do I dare suggest that we attempt to re-import net80211 and friends here?
Renato grabbed the last import a day after Adrian went nuts and backed out a ton of Gleb's changes.
Yeah let's go for it. There are a bunch of ways to crash things as it stands now.
Updated by Jim Thompson almost 9 years ago
Bump for Renato to re-engage on this.
Updated by Renato Botelho almost 9 years ago
- Status changed from Confirmed to Feedback
We reverted the FreeBSD 11 wireless import and decided to keep stock FreeBSD stable/10 wireless stack in place for now
Updated by Jim Pingle over 8 years ago
- Status changed from Feedback to Resolved
This appears solid now. Confirmed the panic on a previous snap, then updated and now a client can join and pass data without issue, the panic no longer happens.