Date: Sat, 4 Aug 2012 14:12:21 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: PseudoCylon <moonlightakkiy@yahoo.ca> Cc: freebsd-wireless@freebsd.org, Kim Culhan <w8hdkim@gmail.com> Subject: Re: ath lor Message-ID: <CAJ-VmomLwcAkwKhP0YXykJLjobcuSa_=nA4dtdczN8bgixFSCw@mail.gmail.com> In-Reply-To: <CAFZ_MYKmORxoA9utQujdZOHV=Kmfcw=JagSdBRQjBzbTR4bOGg@mail.gmail.com> References: <CAFZ_MYKgUkryy4parts3QahAyPA7FY9xUqC98_E7oFW%2BzarA8A@mail.gmail.com> <CAFZ_MYKeOKxT3k7JWHjdH83vbieZ6JpXe0kbXTJy4neEd5Aqew@mail.gmail.com> <CAJ-VmomGBvgLwFEcXbEuYkAj=g%2By8zVo8cT2nSSMdydCk=OhYQ@mail.gmail.com> <CAFZ_MYJP97aO73zLpJF9%2B8MiQVqAHGNngmtOakYDcaikvyq7og@mail.gmail.com> <CAJ-VmomSTcTFVQovOaGB9_7kTh_R9Z2W4bypknHVrtykYz2SMg@mail.gmail.com> <CAFZ_MYKnKmM2M%2BpcifxWNcp-pXsJGhb2i7aRo94JK3jqUyaNrw@mail.gmail.com> <CAJ-VmokoURqGmD=U_=p0noeGbLBwTbW63fMfo8Teb7iw3U_W-g@mail.gmail.com> <CAFZ_MYL%2BBV0dPP_hxKw%2BWEz-zz2TxwOdYRTqipPuVa6ZEmvx9A@mail.gmail.com> <CAJ-Vmok-TFHyo0JkX_AucDwRj=JX1qwfc_s7nidFSBnrO_Y-jw@mail.gmail.com> <CAFZ_MYLsa1QHHe=U=9=rjFsoXCfv7DB0LMZLxiZekpACSB9nYg@mail.gmail.com> <CAJ-VmonzuvnqE3MsuOac2QXYeamYbCysMhurBmCRsaCCTTpfnA@mail.gmail.com> <CAFZ_MYKmORxoA9utQujdZOHV=Kmfcw=JagSdBRQjBzbTR4bOGg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 August 2012 05:38, PseudoCylon <moonlightakkiy@yahoo.ca> wrote: >> This is a bit odd. I've not seen that, but you're testing with USB, right? >> > > Yes with run(4). Most likely, it calls ieee80211_free_node() while > driver lock is held. > http://fxr.watson.org/fxr/source/dev/usb/wlan/if_run.c#L2705 Ok. I really, really should set up a -CURRENT laptop today/tonight. I've found it ok to compile -HEAD net80211/wifi drivers on -9, but trying to compile -9 USB drivers and stack on -HEAD is proving to be rather annoying/challenging. I've acquired a couple of run NICs (that do 11n, too!) so I'll be able to test that out very soon. What's the path through the stack -> driver that leads to run_tx_free() being called with the driver lock held? And on the flip side, what's the path through the driver -> stack that's called with the driver lock held? The comlock shouldn't be held when TX/RX'ing packets up to the stack. >> I just saw a LOR between a node lock and a tcpinp lock. i was doing >> some iperf to an AR5416 802.11n AP running iperf locally. I've not >> seen this before as I've not run a NIC in AP mode with local traffic >> termination; I've only had APs do bridging. >> > > It hasn't caused LOR with run(4), but if_start() is called with tcpinp > lock is held when bridging or with multiple vaps in AP mode. That > non-sleepable lock causes different problem with USB devices. > http://fxr.watson.org/fxr/source/dev/usb/wlan/if_run.c#L3089 Odd. I saw that happen with no bridge interface configured. Hm. I'll gather some more data soon. I'm trying to fix some TX descriptor buffer issues that creep up if the air is congested and TX stalls for a bit. I've not seen it occur on 5GHz as the air wasn't ever really congested. >> Thanks for chasing this down. Let me know if you see the node/power or >> node/scan LORs? > > Not so far, only scan/com LOR, the same one I mentioned before. Hm, maybe we should start a wiki page with all of the net80211/wifi driver LORs. Do you have wiki.freebsd.org access? If not, create an account and tell me what username you choose. If you do, create a page under http://wiki.freebsd.org/WiFi and let's start documenting the LORs that we see. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomLwcAkwKhP0YXykJLjobcuSa_=nA4dtdczN8bgixFSCw>