Re: RFT: if_ath HAL refactoring

From: PseudoCylon <moonlightakkiy_at_yahoo.ca>
Date: Wed, 22 Sep 2010 15:42:21 -0700 (PDT)
----- Original Message ----
> From: Bernhard Schmidt <bschmidt_at_techwires.net>
> To: freebsd-current_at_freebsd.org
> Cc: PseudoCylon <moonlightakkiy_at_yahoo.ca>; Adrian Chadd <adrian_at_freebsd.org>
> Sent: Wed, September 22, 2010 12:09:36 AM
> Subject: Re: RFT: if_ath HAL refactoring
> 
> On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote:
> > -----  Original Message ----
> > 
> > > From: Adrian Chadd <adrian_at_freebsd.org>
> > > To:  PseudoCylon <moonlightakkiy_at_yahoo.ca>
> >  > Cc: freebsd-current_at_freebsd.org
> >  > Sent: Tue, September 21, 2010 7:04:37 AM
> > > Subject: Re: RFT:  if_ath HAL refactoring
> > > 
> > > On 21 September 2010 11:58,  PseudoCylon <moonlightakkiy_at_yahoo.ca>   
wrote:
> > > > Just in case anyone wonders, I've added 11n support to  run(4)  (USB
> > > > NIC). http://gitorious.org/run/run/trees/11n_beta2
> > > > 
> >  > >  It still has some issues,
> > > > 
> > > > *  doesn't work well with atheros chips
> > > > 
> > > >   * HT + AP + bridge = Tx may stall (seems OK with nat)
> > > > 
> >  > > So, use it at your  own discretion.
> > > 
> > >  Want to put together a patch?
> > 
> > sure!
> > 
> > > Does  it introduce  issues in the non-11n case?
> > 
> > No, only in 11n  mode.
> > 
> > What I have found so far is that Ralink's driver checks  MAC address of
> > other end and identify atheros chip by oui. Then, sets  special prot mode
> > for it. Does this ring a bell?
> 
> Are your sure  that this is based on the actual MAC addresses? Atheros drivers 

> tend to  announce additional capabilities in beacons and probe responses.

It is based on the actual MAC, but it is Broadcom's oui (00904c). sorry.

> 
> > Has  node lock in ieee80211_node_timeout() cased dead lock in HT + AP +
> >  bridge?
> 
> I'm not aware of any issues there, though, I'm not very familiar  with HT use 
> cases.

I attached witness messages. Those 2 LORs always happen together before 
deadlock. I hooked iv_input() and unlock/lock node lock to avoid deadlock. (I 
don't know if it's safe.)

I wonder if this is run(4) specific problem.


AK


lock order reversal:
 1st 0xffffff8000a267d0 run0_node_lock (run0_node_lock) _at_ 
/usr/src/sys/net80211/ieee80211_node.c:1360
 2nd 0xffffff0001716818 if_bridge (if_bridge) _at_ 
/usr/src/sys/net/if_bridge.c:2184
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
bridge_input() at bridge_input+0x7e
ether_input() at ether_input+0x143
hostap_input() at hostap_input+0x4ea
ampdu_rx_flush() at ampdu_rx_flush+0x5e
ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b
ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc
softclock() at softclock+0x2a0
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff8000052d30, rbp = 0 ---

lock order reversal:
 1st 0xffffff8000a267d0 run0_node_lock (run0_node_lock) _at_ 
/usr/src/sys/net80211/ieee80211_node.c:1360
 2nd 0xffffffff80a186c8 tcp (tcp) _at_ /usr/src/sys/netinet/tcp_input.c:498
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_rw_rlock() at _rw_rlock+0x5f
tcp_input() at tcp_input+0xa58
ip_input() at ip_input+0xbc
netisr_dispatch_src() at netisr_dispatch_src+0xb8
ether_demux() at ether_demux+0x17d
ether_input() at ether_input+0x175
hostap_input() at hostap_input+0x4ea
ampdu_rx_flush() at ampdu_rx_flush+0x5e
ieee80211_ht_node_age() at ieee80211_ht_node_age+0x7b
ieee80211_node_timeout() at ieee80211_node_timeout+0x2dc
softclock() at softclock+0x2a0
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffff8000052d30, rbp = 0 --- 
Received on Wed Sep 22 2010 - 20:42:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC