K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-06T10:12:59.515950Z
K 7
svn:log
V 1251
Introduce some rather annoying work arounds to make the TID->AC map consistent.

The introduction of BAW tracking and blocking have shown short-comings in my
code. Specifically, I assumed that the TID->AC mapping would be consistent.

I've found a few things that get that wrong, specifically:

* frames with no QOS bit set were being dumped into TID=0, regardless of the
  access category;
* That resulted in raw management frames with no TID getting TID=0 instead of
  TID=16 (IEEE80211_NONQOS_TID), but with AC's that could vary;
* So frames were being scheduled in the wrong TID, then unscheduling them
  ended up selecting the wrong AC and thus hardware queue, and the lock assertions
  would trigger.

The workarounds:

* store the per-TID AC in ath_tid, just as a short-cut;
* make TID 16 map to AC WME_AC_BE (best effort);
* override the priority/TID that net80211 gives us, so frames that don't have the QOS
  bit set will end up being shovelled into WME_AC_BE and TID 16;
* direct-dispatch multicast frames to the multicast software queue.

This still hasn't resolved the BAW issues I've begun seeing. I'll investigate those
shortly. It does however fix all the lock assertions from incorrect/inconsistent
hardware queue / AC / TID mapping.

END