On Thu, May 7, 2009 at 5:23 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > When a software scan starts, it first sets sw_scanning, but > leaves the scan_channel "unset" (it currently actually gets > initialised to a default). Now, when something else tries > to (re)configure the hardware in the window between these two > events (after sw_scanning = true, but before scan_channel is > set), the current code switches to the (unset!) scan_channel. > This causes trouble, especially when switching bands and > sending frames on the wrong channel. > > To work around this, leave scan_channel initialised to NULL > and use it to determine whether or not a switch to a different > channel should occur (and also use the same condition to check > whether to adjust power for scan or not). > > Additionally, avoid reconfiguring the hardware completely when > recalculating idle resulted in no changes, this was the problem > that originally led us to discover the race condition in the > first place, which was helpfully bisected by Pavel. This part > of the patch should not be necessary with the other fixes, but > not calling the ieee80211_hw_config function when we know it to > be unnecessary is certainly a correct thing to do. > > Unfortunately, this patch cannot and does not fix the race > condition completely, but due to the way the scan code is > structured it makes the particular problem Pavel discovered > (race while changing channel at the same time as transmitting > frames) go away. To fix it completely, more work especially > with locking configuration is needed. > > Bisected-by: Pavel Roskin <proski@xxxxxxx> > Signed-off-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> I've tested this on a dual band card and in fact as I expected it cured the oops we were seeing with ath9k. 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
