Date: Sun, 5 Aug 2012 10:24:46 -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-VmomXVKYodo9Q5Nt1mvWPsOtSHjh5R9RqKcqtrGfrYjh9AA@mail.gmail.com> In-Reply-To: <CAFZ_MY%2BD4XptiR6OaLiENo0iU1gG49abXPJ_JksK4_GuHU47Sw@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> <CAFZ_MY%2BD4XptiR6OaLiENo0iU1gG49abXPJ_JksK4_GuHU47Sw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 August 2012 06:37, PseudoCylon <moonlightakkiy@yahoo.ca> wrote: >> 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. Ah. Hm, does the USB stack need to hold any locks held? That seems like a recipe for disaster for drivers in general, not just wifi. >> 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. Cool. >> 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. Yes. Please, let's start a wiki page with all the wifi stack / driver related LORs that you find. I really want to find/fix/document/squish them as soon as possible. Also, would you please push a patch to the mailing list for your current ieee80211_iterate_nodes() work, so Kim and I can try it out? That way we can provide testing and feedback (respectively.) Thanks for your work with this! I'm glad to have someone else working on improving things. (Ray, Bernard and Monthadar included as well. :-) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomXVKYodo9Q5Nt1mvWPsOtSHjh5R9RqKcqtrGfrYjh9AA>