[ath9k-devel] AR5416 not fully working

[Luis R. Rodriguez <lrodriguez@atheros.com>]

On Wed, Oct 15, 2008 at 12:58:59PM -0700, Benoit PAPILLAULT wrote:
> I must admit I do not fully understand your reply (I've not read the
> 802.11n specs 

Neither have I but I've read a bit of it and a bit of code. I've tried
to summarize what I know so far here:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n

It would be great to get more people to contribute to that page to help
summarize 11n to help with development so its easier for people to catch
up.

> .... ). I got the same results with AR9160. The exact
> error message is:
> 
> BA request denied - queue unavailable for tid 0
> BA request denied - queue unavailable for tid 6
> BA request denied - queue unavailable for tid 7

BA stands for Black Ack, see the description in the wiki but the
important part is that BAs are useful for aggregation. Aggregation is
disabled right now in mac80211 becuase as I mentioned
ieee80211_ht_agg_queue_add() doesn't allow the usage of an
"ampdu_queue" right now, we simply return early right now.
We call this routine from ieee80211_start_tx_ba_session()
in ht.c as follows:

       ret = ieee80211_ht_agg_queue_add(local, sta, tid);

        /* case no queue is available to aggregation
         * don't switch to aggregation */
        if (ret) {
#ifdef CONFIG_MAC80211_HT_DEBUG
                printk(KERN_DEBUG "BA request denied - queue unavailable
for"
                                        " tid %d\n", tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
                goto err_unlock_queue;
        }


And that is why you see the printk error message. That is because
ieee80211_ht_agg_queue_add() right now returns early because
the new TX multiqueue changes requires a change in design
on the usage of skb->cb -- we just need to take into consideration
that when an skb enters a qdisc that skb->cb no longer will have
the same information it used to. This information is required
during ieee80211_requeue(), which anyway IMHO is also broken
when you pass the requeue==1 parameter (I think we requeue onto the same
queue!).

int ieee80211_ht_agg_queue_add(struct ieee80211_local *local,
                               struct sta_info *sta, u16 tid)
{
        int i;

        /* XXX: currently broken due to cb/requeue use */
        return -EPERM;
... etc

> However, this time, I got 27 Mbits, ie equivalent to 802.11g.

Is this with HT20 or HT40? If HT20, can you try HT40 on the AP?

> Are there some patches I can try?

You can try removing that EPERM and you will probably get
rtnl_lock() complaints. We fixed this and the skb->cb issue
in some temporary patches and you can see the idea and concept
here for wireless-testing:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/mac80211/aggrv9-wl.tar

These patches may no longer apply and when I did a quick test on it
they oopsed. Anyway the intent was to fix this for 2.6.27 and these
patches do work:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/mac80211/aggrv9-2.6.27.tar

> Could you give me more details in order to fix aggregation?

I'm working on fixing this a *correct* way now, by removing the usage
of ampdu_queue stuff for ath9k. This is an Intel'ism which we just
don't need. The reason Intel added it was that their firmware
schedules aggregates onto their harware queue and they put their
ampdu_queueing mechanism into mac80211. We do this in our driver
and so we simply don't need this.

If you would like to help fix this I can recommend to start reviewing
the above patches and then we can discuss this further. Hopefully by
then I'll have some temporary patches we can work together on.

  Luis