On Mon, Oct 04, 2010 at 09:39:52AM -0700, Johannes Berg wrote: > On Mon, 2010-10-04 at 09:36 -0700, Luis R. Rodriguez wrote: > > > > > +wait: > > > > wk->timeout = jiffies + IEEE80211_ASSOC_TIMEOUT; > > > > run_again(local, wk->timeout); > > > > > > But you'll be staying off-channel for the wait period, so what does this > > > really help? > > > > I totally missed this what locks us offchannel here, I though we just re-arm > > the timer, and come back offchannel at a later time. What is it that locks > > us offchannel until the timer runs again? > > I believe we stay off-channel as long as the work item is active, after > it has been activated, no? Well I don't see that, the problem here was the assumption that within a work item we can try to transmit a frame for our home channel without changing it. If that is desired we must move back to the home channel as I did, but I can see how we'd need more work than what I did, we'd need to start the queues, get out of PS state with the AP and then TX... unless TX already handles that for us. ieee80211_work_work() just iterates over all work items, and then bails out. The work loop is protected against local->mtx, and if we call work_work when we either add new work, purge work, or hit a timer. We *try* to prevent frames from being sent on the home channel by calling ieee80211_offchannel_stop_station() but notice how we only stop the queues for NL80211_IFTYPE_STATION interfaces. 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. 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
