Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Sep 2011 18:02:19 +0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        freebsd-wireless@freebsd.org
Subject:   Fixes in the latest if_ath_tx branch
Message-ID:  <CAJ-VmoktnsWDi7=FuM2Qw17F46k12TqiYrqCcaP1Knzf2QHdkA@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hi all,

I've found a few interesting bugs in the ath driver and HAL which,
when fixed, have dramatically improved the stability of hostap mode on
the AR9220 (and I bet AR9280 too.)

The little one:

When configuring the beacon queue, use an AIFS of 1, not 0.

The bigger one:

The AR5212/AR5416 code was defaulting to a hard-coded beacon interval
of 100TU but not updating this if staggered beacons were enabled
(which they are by default on AR5212/AR5416/later NICs) or the beacon
interval was reduced.
The ath driver didn't specify any override parameters when setting up
the CAB queue (content after beacon), and so the HAL would use this
hard-coded beacon interval for the CABQ readytime config - ie, how
long the CABQ could assume the air belonged to it.

Unfortunately this meant that the cabq readytime was set to 4 x the
beacon interval (which because of staggered beacons, defaults to
100TU/4, for the 4 VAP slots; so 25TU.)

The AR5212 seemed to be ok with this, the AR5416/AR9160 seemed not too
unhappy, but the AR9220 would just get pissed off and the CAB/Beacon
queues would remain "stuck".

I've changed the HAL to:

* when setting the beacon timers, update the HAL copy of the beacon interval
* when setting the CAB readytime default value, set it to the 70% of
the beacon interval, minus the SWBA/DBA intervals (software beacon
alert and DMA beacon alert.)

The AR9220 is now completely stable in hostap mode with no stuck
beacons. All of the conditions that would before cause the AR9160 and
AR9220 in hostap mode to get upset when running together are now
resolved.
I've also fixed it in my tree for the AR5212 series NICs too. The
AR9280 STA -> AR9220 hostap now passed ~ 130Mbit/sec for an entire day
with no stuck beacons or TX watchdog timeouts.

I'd like to merge this into -HEAD but I don't want to break anything,
so I'd appreciate some third party testing. Berislav has reported that
his 11n hostap stuff is more stable, but I think I'd like to wait for
a day or two more to find out if that truely is the case. :-)

So please, would people please test this? Pretty please? :-)

Thanks,


Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmoktnsWDi7=FuM2Qw17F46k12TqiYrqCcaP1Knzf2QHdkA>