Date: Wed, 22 Sep 2010 23:48:14 +0100 From: Rui Paulo <rpaulo@FreeBSD.org> To: PseudoCylon <moonlightakkiy@yahoo.ca> Cc: Bernhard Schmidt <bschmidt@techwires.net>, Adrian Chadd <adrian@freebsd.org>, freebsd-current@freebsd.org Subject: Re: RFT: if_ath HAL refactoring Message-ID: <5484FA31-E77C-47CE-9CE6-67FCAEA5535D@FreeBSD.org> In-Reply-To: <129192.25720.qm@web51807.mail.re2.yahoo.com> References: <20100919120012.A77371065674@hub.freebsd.org> <AANLkTim84b-O7XegYbT7V7NwWezBp1pLe2w6sHo2Xnnt@mail.gmail.com> <367708.1588.qm@web51805.mail.re2.yahoo.com> <201009220809.36641.bschmidt@techwires.net> <129192.25720.qm@web51807.mail.re2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Sep 2010, at 23:42, PseudoCylon wrote: >=20 >=20 >=20 >=20 > ----- Original Message ---- >> From: Bernhard Schmidt <bschmidt@techwires.net> >> To: freebsd-current@freebsd.org >> Cc: PseudoCylon <moonlightakkiy@yahoo.ca>; Adrian Chadd = <adrian@freebsd.org> >> Sent: Wed, September 22, 2010 12:09:36 AM >> Subject: Re: RFT: if_ath HAL refactoring >>=20 >> On Wednesday, September 22, 2010 06:04:49 PseudoCylon wrote: >>> ----- Original Message ---- >>>=20 >>>> From: Adrian Chadd <adrian@freebsd.org> >>>> To: PseudoCylon <moonlightakkiy@yahoo.ca> >>>> Cc: freebsd-current@freebsd.org >>>> Sent: Tue, September 21, 2010 7:04:37 AM >>>> Subject: Re: RFT: if_ath HAL refactoring >>>>=20 >>>> On 21 September 2010 11:58, PseudoCylon <moonlightakkiy@yahoo.ca> = =20 > wrote: >>>>> Just in case anyone wonders, I've added 11n support to run(4) = (USB >>>>> NIC). http://gitorious.org/run/run/trees/11n_beta2 >>>>>=20 >>>>> It still has some issues, >>>>>=20 >>>>> * doesn't work well with atheros chips >>>>>=20 >>>>> * HT + AP + bridge =3D Tx may stall (seems OK with nat) >>>>>=20 >>>>> So, use it at your own discretion. >>>>=20 >>>> Want to put together a patch? >>>=20 >>> sure! >>>=20 >>>> Does it introduce issues in the non-11n case? >>>=20 >>> No, only in 11n mode. >>>=20 >>> 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? >>=20 >> Are your sure that this is based on the actual MAC addresses? = Atheros drivers=20 >=20 >> tend to announce additional capabilities in beacons and probe = responses. >=20 > It is based on the actual MAC, but it is Broadcom's oui (00904c). = sorry. >=20 >>=20 >>> Has node lock in ieee80211_node_timeout() cased dead lock in HT + = AP + >>> bridge? >>=20 >> I'm not aware of any issues there, though, I'm not very familiar = with HT use=20 >> cases. >=20 > I attached witness messages. Those 2 LORs always happen together = before=20 > deadlock. I hooked iv_input() and unlock/lock node lock to avoid = deadlock. (I=20 > don't know if it's safe.) >=20 > I wonder if this is run(4) specific problem. >=20 >=20 > AK >=20 >=20 > lock order reversal: > 1st 0xffffff8000a267d0 run0_node_lock (run0_node_lock) @=20 > /usr/src/sys/net80211/ieee80211_node.c:1360 > 2nd 0xffffff0001716818 if_bridge (if_bridge) @=20 > /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 =3D 0, rsp =3D 0xffffff8000052d30, rbp =3D 0 --- >=20 > lock order reversal: > 1st 0xffffff8000a267d0 run0_node_lock (run0_node_lock) @=20 > /usr/src/sys/net80211/ieee80211_node.c:1360 > 2nd 0xffffffff80a186c8 tcp (tcp) @ = /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 =3D 0, rsp =3D 0xffffff8000052d30, rbp =3D 0 ---=20 Can you explain why the run0_node_lock is locked ? I don't have the code = at hand.. Regards, -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5484FA31-E77C-47CE-9CE6-67FCAEA5535D>