ath lor

[PseudoCylon]

On Sat, Aug 4, 2012 at 4:03 AM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> On 3 August 2012 22:11, PseudoCylon <moonlightakkiy at 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