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. 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