K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-14T16:03:26.233948Z
K 7
svn:log
V 1651
Begin to attempt to handle sending BAR frames. This doesn't work yet and will
panic the kernel.

BAR frames should be generated to resync the remote side with where the block-ack
window left edge is - eg, after some packet loss.

The problem here is that said BAR frames will be generated from:

* the TX packet completion handler; and
* via a timer callout if the BAR TX wasn't successful.

The former will occur with the hardware TXQ lock held, as that's currently
how I've implemented the locking (ie, the hardware TXQ protects the TXQ and
the TID state.) This results in lock recursion (as we're recursing back
through net80211 and then back into the driver via ic->ic_raw_xmit()) and
thus TX'ing a BAR frame will very much fail.

The problem here (among other things) is that TX'ing a BAR frame should
occur after all the hardware-queued frames for that AC, in case there's
some other packets (which may or may not be successfully transmitted
in the future), and in the same hardware queue. This means we can't just
use the normal software queue method, as the TID should be paused when
a BAR frame is TX'ed. Hence, the direct dispatch to hardware.

Anyway, this is all quite messy. I think I'm going to have to bite the
bullet and (re) introduce more fine-grained locking in a subsequent commit
before supporting this in a clean fashion is even possible.

(The other option is to modify the ieee80211_send_bar()) function to just
schedule a callback even and have the TX occur from there, rather than
recurse through the driver. I may end up doing that at a later date, but
I really need to fix the locking anyway. So, I'll just do that first.)

END