From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Wed, 15 Oct 2008 06:33:59 -0700 Subject: [ath9k-devel] AR5416 not fully working In-Reply-To: <48F64B83.40206@free.fr> References: <48F58DBF.10903@free.fr> <20081015110254.GD6509@tesla> <48F64B83.40206@free.fr> Message-ID: <20081015133359.GI6509@tesla> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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