Hi, Here's take four of the TX serialisation.
http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff This patch increases the lock "reach" so it locks the encap path for both data and management frames, so the path between sequence number allocation and driver queuing is held. There are some drivers that directly access ni_txseqs (ie, iwn and ath) and I'll have to think about this a little more. Sometimes it'll be called with the VAP TX lock held (ie, if it's called from driver if_transmit / driver if_start / ic_raw_xmit) but sometimes the TX path is called from the addba response callback, the TX completion methods, a software frame taskqueue. None of these grab the VAP TX lock at any point. I'd like to avoid making the VAP TX lock a reentrant lock (ew.) I'm open to ideas/suggestions. Thanks, Adrian _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"