On 2010-01-30 8:39 PM, Pavel Roskin wrote: > On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote: > >> Please try this patch and see if it helps. > > Yes, it worked perfectly!!! > > I added some debug printks, and it turns out that ah->slottime is > negative. The card is Ubiquiti SR71-12, 2 GHz only. > > phy1: Atheros AR9280 Rev:2 mem=0xffffc900107c0000, irq=19 > mac80211: debugfs: failed to rename debugfs dir to netdev:wlan0 > udev: renamed network interface wlan0 to wlan13 > ah->slottime = -1, ah->coverage_class = 0, sifstime = 10 > acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0 > ah->slottime = -1, ah->coverage_class = 0, sifstime = 10 > acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0 > ah->slottime = -1, ah->coverage_class = 0, sifstime = 10 > acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0 > ah->slottime = -1, ah->coverage_class = 0, sifstime = 10 > acktimeout = 9, conf->channel = ffffffffa01c25d4, conf->channel->band = 0 > ah->slottime = 9, ah->coverage_class = 0, sifstime = 10 > acktimeout = 19, conf->channel = ffffffffa01c25d4, conf->channel->band = 0 > phy1: Allocated STA 00:19:e3:05:25:10 > phy1: Inserted STA 00:19:e3:05:25:10 > > I see that ah->slottime is initialized to -1 in > ath9k_hw_init_defaults(). Maybe we want a number that is large, but > doesn't overflow? Or we could start with 54, which would give 64 in the > first iteration. 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. The slottime == -1 thing is obviously a bug, and I'll send a patch to fix it later.
- Felix _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
