[ath9k-devel] ath9k in wireless-testing won't work in AP mode

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

On Sat, Jan 30, 2010 at 12:46:51PM -0800, Felix Fietkau wrote:
> On 2010-01-30 9:37 PM, Pavel Roskin wrote:
> > On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote:
> >
> >> The workaround value of '64' is actually wrong. When I had trouble
> >> associating in 2.4 GHz in a case where the slot time was actually set
> >> correctly, I simply used it, because that's what was being set in the
> >> initvals. We shouldn't base the slot time on this though - the initvals
> >> don't do this either.
> >
> > I could reduce the minimal value of acktimeout from 64 to 20.  With 20,
> > I get a reliable communication every time.  With 19, it's doesn't work
> > ever.  The distance between STA and AP is about 1 meter.
> >
> >> The slottime == -1 thing is obviously a bug, and I'll send a patch to
> >> fix it later.
> >
> > It turns out that simply increasing the initial value to 54 is not
> > enough, as ah->slottime will be set to 9 from sc->beacon.slottime, so
> > acktimeout becomes 19.
> That's why my patch forces it to a minimum of 64 just before it gets set.
> 
> > But using the value of 10 instead of 9 for sc->beacon.slottime does the
> > trick.  That's the minimal patch that works for me.
> >
> > Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and
> > define it to 10.
> That value would still be wrong, though. According to the 802.11 docs,
> the slot time for 2.4 GHz has to be set to 9 usec, not 10.
> If this is a bug in the hardware, we need to know about the implications
> before we pick a value that just happened to work in our tests, but may
> not work in all cases.
> slottime=9, acktimeout=64 is what the initvals use, so that's tested by
> Atheros. If we continue to receive no comments from Atheros on this
> issue, we should probably use those values by default.
> By the way, 5 GHz seems to be unaffected by this issue, which makes this
> a little suspicious.
> I've Cc'd Luis, maybe he can forward this to the right people.

We have reviewed this. The 64 value came from interoperability
tests against another 802.11n device which had increased delayed BlockAcks
when CTS-to-self was enabled. Although this is a higher value than
what the standard says to use we recommend to just leave the value as-is
and actually use the values from the initvals as the minimum possible
value as those are the values that have been used for a large array
of tests, including WMM interop tests. We cannot gaurantee proper
functionality against other devices otherwise.

Since the issues so far are obaserved on AR9160 and AR9220
(and not AR9280) and AR9271 (sujith) this might be a bus issue
and the only way to zero in on the issue would be by getting full
register dumps to ensure every other register related to ACK Timeout
is programmed properly (AR_USEC_USEC I think is one) and
taking it from there. Testing different values are welcomed but
upstream we should just use what we have tested with until
we do WMM interop tests with different values and not sure if
we'll be doing that for a while.

  Luis