On Mon, 2010-10-04 at 13:55 -0700, Luis R. Rodriguez wrote: > > We don't need to go out of PS state to just TX, but we'd need to be > > careful to TX with asleep bit. > > I got what you meant here. > > > That said, we don't TX data frames then. > > But not here. Right now I am going to assume that we actually are > transmitting some frames for the delba when we try to tear down > the BA agreements with the old AP and the new AP are on the > same band, we just likely transmit it on the wrong channel. Yes, but delBA aren't data frames. The queue stop etc. doesn't pertain to them. > Ah and also we did call ieee80211_offchannel_stop_beaconing() prior > to processing work_work stuff so that should take care of stopping > beaconing but that also turns off all TX queues... so yeah you're > right. The race here was just within work items assuming they can > transmit on other channels than the wk->chan. Did any work item actually assume that? Except maybe for your patch 1 in this set? > > > Also this seems buggy, we do not take into consideration how much offchannel > > > work we are doing in consideration against the current AP's DTIM interval as > > > we do when going offchannel for scan work. We should merge that code for > > > this offchannel work_work loop. > > > > True, we don't do _any_ timing here. > > We can resolve that later, I'll add that to the TODO list. Come to think of it -- some p2p stuff in the supplicant might time out if we do this, I think we need to cut the drivers/mac80211 some more slack in the supplicant and not assume the remain-on-channel will start quickly. johannes -- 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
