From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Sat, 30 Jan 2010 21:10:20 +0100 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <1264880367.26739.25.camel@mj> References: <1264806315.23248.22.camel@mj> <4B63709F.2010805@openwrt.org> <1264880367.26739.25.camel@mj> Message-ID: <4B64922C.1090809@openwrt.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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