Project

General

Profile

Bug #5453

Wifi card using the ath driver running in hostap mode causes a panic when a client joins.

Added by Steve Wheeler over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Wireless
Target version:
Start date:
11/15/2015
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.3
Affected Architecture:

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.

apu_crash5.txt (386 KB) apu_crash5.txt Steve Wheeler, 11/15/2015 10:35 AM

History

#1 Updated by Jim Thompson over 3 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

#2 Updated by Jim Pingle over 3 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)

#3 Updated by Jim Thompson over 3 years ago

what panic string? seems blank.

#4 Updated by Jim Pingle over 3 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)

#5 Updated by Chris Buechler over 3 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 ---

#6 Updated by Chris Buechler over 3 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

#7 Updated by Jim Thompson over 3 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.

#8 Updated by Chris Buechler over 3 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.

#9 Updated by Jim Thompson over 3 years ago

Bump for Renato to re-engage on this.

#10 Updated by Renato Botelho about 3 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

#11 Updated by Jim Pingle about 3 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.

Also available in: Atom PDF