Date: Sun, 5 Aug 2012 07:37:59 -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_MY%2BD4XptiR6OaLiENo0iU1gG49abXPJ_JksK4_GuHU47Sw@mail.gmail.com> In-Reply-To: <CAJ-VmomLwcAkwKhP0YXykJLjobcuSa_=nA4dtdczN8bgixFSCw@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> <CAJ-VmomLwcAkwKhP0YXykJLjobcuSa_=nA4dtdczN8bgixFSCw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 4, 2012 at 3:12 PM, Adrian Chadd <adrian.chadd@gmail.com> wrote: > 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? This one was easy to spot. USB stack calls run_bulk_tx_callbackN() with driver lock held, ->run_tx_free() ->ieee80211_free_node() then locks node lock. > > 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 have not found it yet. I've been stuck here, but I'll keep looking for this. Then I can patch usb/150189. > >>> 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. This hasn't caused LOR, just sleeping issue. Maybe some change in upper layer fixed it. The code was first written for 8.0. > >>> 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. run(4) calls ieee80211_runtask() because thread is non-sleepable or avoid LOR. I think I can still track back LOR. Also, I saved LOR outputs I saw long time ago. See if I can find them on old hard drive. AK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFZ_MY%2BD4XptiR6OaLiENo0iU1gG49abXPJ_JksK4_GuHU47Sw>