AR9280 and noisy environments, please test

[Adrian Chadd]

Hi all,

I've added some local hacks to my if_ath_tx branch which hopefully
will help us nail down what's going on with AR9280 and noisy
environments.

The theory: AR9220/AR9280 noise floor sampling is not picking up the
bursty traffic that's going on in the air. so it's reporting a low NF
but as the air spends most of its time with _some_ signal above what
it thinks the NF is, it constantly thinks the channel isn't clear to
TX. I saw this with AR9160 last year but it turned out to be issues
with the AP power supply enclosure generating 2.4ghz spurs. I doubt
we're seeing this here. :)

The changes:

* I've updated the ANI code a bit more, so it does some more "stuff"
in hostap mode;
* I've disabled OFDM weak detection by default in hostap mode, but I
haven't (yet) disabled CCK weak threshold setting;
* I've added some very rudimentary support to log how busy the channel
is, so we can see what the difference is between different 11n NICs;
* I've added a knob to allow the noise floor threshold (and thus the
CCA threshold) to be manually set, rather than relying on sampling by
the baseband.

What I'd like you guys to try:

* update if_ath_tx!
* run the ar9280 in hostap or STA mode, it doesn't matter what, but
enable NF and ANI debugging:
  # sysctl dev.ath.X.hal.debug=0x28
* let it run for a couple of minutes, so it gets a couple of NF
calibrations (which occur every 30 seconds) and then report that to
me.

What you'll likely see is:

* ANI goes bezerk with OFDM/CCK errors, and tries bumping up some
things (spur immunity, firstep);
* the NF values calibrated are either crazy looking (higher than -80),
or chain 0 / chain 1 values are wildly mismatching;

Then, try changing the longcal value from 30 to 1, and email me two or
so minutes of logging output.

Finally, set the CCA threshold to something manual, and rerun tests
for a couple minutes:

# sysctl dev.ath.X.config.cca=-85

Thanks,


Adrian