On Tue, Jul 27, 2010 at 2:30 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > 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. I'm also a bit surprised there are no other drivers with issues due to this too. 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
