Date: Sat, 4 Aug 2012 06:38:16 -0600 From: PseudoCylon <moonlightakkiy@yahoo.ca> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: freebsd-wireless@freebsd.org, Kim Culhan <w8hdkim@gmail.com> Subject: Re: ath lor Message-ID: <CAFZ_MYKmORxoA9utQujdZOHV=Kmfcw=JagSdBRQjBzbTR4bOGg@mail.gmail.com> In-Reply-To: <CAJ-VmonzuvnqE3MsuOac2QXYeamYbCysMhurBmCRsaCCTTpfnA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 4, 2012 at 4:03 AM, Adrian Chadd <adrian.chadd@gmail.com> wrote: > On 3 August 2012 22:11, PseudoCylon <moonlightakkiy@yahoo.ca> wrote: > >> I have added if_printf(), so we can track down the driver to blame. >> https://gitorious.org/ieee80211/net80211/commit/4dbc79c5f832b4cdffe9966dbbeba9b1b8fd24da > > Cool. > >> I also added functions to revert changes when overflow (maybe too much). >> https://gitorious.org/ieee80211/net80211/commit/dc1aa81ea1a9eeb7cf1a3a1c2b8a5a8cd85e687d >> >> >>> Does it fix some/all of the LORs for you? >>> >> >> So far, node/driver LOR in iv_key_delete() seems to be gone. > > 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 > 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 > 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. AK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFZ_MYKmORxoA9utQujdZOHV=Kmfcw=JagSdBRQjBzbTR4bOGg>