On Tue, Jul 27, 2010 at 2:22 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > On Tue, Jul 27, 2010 at 1:27 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: >> On Tue, Jul 27, 2010 at 1:04 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: >>> On Fri, Jun 18, 2010 at 3:32 AM, Johannes Berg >>> <johannes@xxxxxxxxxxxxxxxx> wrote: >>>> From: Johannes Berg <johannes.berg@xxxxxxxxx> >>>> >>>> Currently, detection in hwsim and ath9k can >>>> detect that two sw scans are in flight at the >>>> same time, which isn't really true. It is >>>> caused by a race condition, because the scan >>>> complete callback is called too late, after >>>> the lock has been dropped, so that a new scan >>>> can be started before it is called. >>>> >>>> It is also called too early semantically, as >>>> it is currently called _after_ the return to >>>> the operating channel -- it should be before >>>> so that drivers know this is the operating >>>> channel again. >>>> >>>> Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx> >>>> --- >>>> net/mac80211/scan.c | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> --- wireless-testing.orig/net/mac80211/scan.c 2010-06-18 12:22:56.000000000 +0200 >>>> +++ wireless-testing/net/mac80211/scan.c 2010-06-18 12:23:25.000000000 +0200 >>>> @@ -287,6 +287,8 @@ void ieee80211_scan_completed(struct iee >>>> local->scanning = 0; >>>> local->scan_channel = NULL; >>>> >>>> + drv_sw_scan_complete(local); >>>> + >>>> /* we only have to protect scan_req and hw/sw scan */ >>>> mutex_unlock(&local->scan_mtx); >>>> >>>> @@ -296,8 +298,6 @@ void ieee80211_scan_completed(struct iee >>>> >>>> ieee80211_configure_filter(local); >>>> >>>> - drv_sw_scan_complete(local); >>>> - >>>> ieee80211_offchannel_return(local, true); >>>> >>>> done: >>> >>> Leaving the entire patch in the e-mail reply as the patch is small to >>> help with context. >>> >>> Turns out this patch broke ath9k in the sense that right after a scan >>> we get disconnected from the AP. I just bisected wireless-testing by >>> master-tag dates and found 2010-06-18 to be where we hit poo in. I >>> reverted this patch and its cured. I'm going to test a recent >>> wireless-testing now and then just try reverting this to see if its OK >>> even on a recent wireless-testing, and then see if we can fix this >>> properly on ath9k or whatever. >> >> Yeap, reverting this patch alone today on wireless-testing makes me >> ath9k happy once again. > > So after some though and review in order to fix this we need a little > more time and thought. The above patch changes the order in which we > configure hardware upon a scan complete. It used to be we would > configure the hardware, configure the filter and then scan complete. > By then we'd be on the home channel and the filters would be set > correctly. ath9k's scan complete routine does a few things which > depend on the channel and will make hardware poo otherwise or do > stupid things: > > * start TX poll routine, due to the new latency introduced to > configure hardware and configure the RX filter the TX polll routine > now has some extra work done by hardware before it actually starts > TXing. I don't suspect this could introduce a huge regression but it > is worth noting. > * ANI gets started, and the wrong channel is used if we're not yet > on the home channel. A simple patch to test if this may be causing the > disconnect issue I am seeing I just tried was to increase the delay > before starting ANI, this did indeed help. Oh and having the right filters set up for ANI processing is important too. At first I thought trying to detect upon hw config the home channel would be a good place to move the ani start, but then we'd also need to move the beacon config and test that.. at this point there are just too many unknowns on possible regressions introduced by this. > * ath_beacon_config() which I suspect means that if we now scan in > AP mode/IBSS mode we could potentially be leaking beacons on the last > channel of a scan, prior to sending them on the actual desired home > channel. > > To address and review all this I need more time and instead I think > its easier to ask for revert of this patch. I think we should more > carefully address these issues acanll together in one patch to avoid > these regressions. Right now ath9k is just completely useless with > this. It disconnects upon every scan, so for network manager users > this is every 60 seconds. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
