From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Wed, 15 Oct 2008 04:02:54 -0700 Subject: [ath9k-devel] AR5416 not fully working In-Reply-To: <48F58DBF.10903@free.fr> References: <48F58DBF.10903@free.fr> Message-ID: <20081015110254.GD6509@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 Tue, Oct 14, 2008 at 11:29:19PM -0700, Benoit PAPILLAULT wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 Hey Bonoit! > Hi there, > > I'm currently testing an AR5416 minipci card in a laptop (using 1, 2 or > 3 antennas does not make any difference). My configuration is: > > - - laptop with the minipci card in STA mode > - - Linksys WRT350N in AP mode > - - another laptop wired to the Linksys AP > - - doing iperf between the 2 laptops > > I'm using wireless-testing tree + the ath9k driver. Here are the problem > i'm facing: > > 1/ Association using wpa_suplicant (WPA2-PSK) is OK Yay. > 2/ DHCP is always failing (I never got an IP) Thanks, this should not fail and it does not fail in my own setup. Can you provide the log messages during this? > 3/ Using a fixed IP, I'm not able to ping for some time (at least for 80s) This needs to be fixed too, can you provide log messages during this? I haven't seen this anymore, it used to happen but I no longer see it. > 4/ When ping is working, throughout is like 15 Mbits at its maximum. You will only get MCS rates but without aggregation. It also depends on the noise on the location of where you are testing. More on this below. > 5/ During all the test, tcpdump show that the RX side is OK > > dmesg shows lots of "BA request denied", but apparently that might not > be a problem. Out of these I take it you mean the second one: ht.c: printk(KERN_DEBUG "BA request denied - session is not " ht.c: printk(KERN_DEBUG "BA request denied - queue unavailable for" ht.c: printk(KERN_DEBUG "BA request denied - HW unavailable for" If so I find it strange as aggregation is disabled right now in mac80211 -- see ieee80211_ht_agg_queue_add(). But keep in mind ath9k ampdu_queues = 1 on ath9k right now and what I've seen so far is ath9k sends frames on two tids during a session to an AP some initial data on tid 0 and some data frames on tid 6. I think this a bug. Anyway you can temporarilly fix this by increasing the number of ampdu_queues ath9k declares. This whole ampdu_queues is bogus and just needs to be removed to fix aggregation properly in mac80211. > Is that a known bug? Did i miss something in my setup? How to debug? For now please consider aggregation disabled and broken in mac80211 due to two facts: 1. Its current design on relying ampdu_queue notion (tid_to_tx_q stuff). 2. TX MQ changes require changes in order to deal with overwriting of skb->cb upon having the skb enter the qdisc. Our initial work on aggregation addresses the second issue and we tried to get it in for 2.6.27 as a temporary solution without having to rm -rf ampdu_queue notion yet. This patch didn't make it upstream, however, due to the more amount of changes required and some other hacks I saw on the way. Its now time to simply fix aggregation properly by dealing with these two issues. For now please consider aggregation disabled. > I will redo the very same test with an AR9160 minipci card as well. I suspect you will get similar results. But regardless the issues we have to definitely address are your latency on ping/dhcp. Then we can move on to throughput concerns but they may very well be related. Luis