ath lor

[PseudoCylon]

On Sat, Aug 4, 2012 at 3:12 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> On 4 August 2012 05:38, PseudoCylon <moonlightakkiy at 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