K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-03T09:32:57.684428Z
K 7
svn:log
V 944
Revert the previous commit - it meant a LOR was unavoidable between the
TXQ lock and the IEEE80211_NODE_LOCK.

Eg:

 1st 0xc086c6cc ath1_node_lock (ath1_node_lock) @ /data/freebsd/mips/if_ath_tx/src/sys/net80211/ieee80211_node.c:1702
 2nd 0x80a02738 ath1_txq1 (ath1_txq1) @ /data/freebsd/mips/if_ath_tx/src/sys/dev/ath/if_ath_tx.c:1631
 1st 0x80a027c8 ath1_txq3 (ath1_txq3) @ /data/freebsd/mips/if_ath_tx/src/sys/dev/ath/if_ath.c:4147
 2nd 0xc086c6cc ath1_node_lock (ath1_node_lock) @ /data/freebsd/mips/if_ath_tx/src/sys/net80211/ieee80211_node.c:1702

I'm going to do some digging to see whether this is a false LOR - ie, whether
it's possible for the LOR to involve the same node AND TXQ.

For now, this means completion functions need to do their own TXQ locking
if they're going to fiddle with TID state. This introduces a few potential
race conditions - which is why I'd like to hold this lock across the
completion function if possible.

END