On Mon, 2011-02-21 at 12:51 +0530, Vivek Natarajan wrote: > On Sat, Feb 19, 2011 at 2:44 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Sat, 2011-02-19 at 11:42 +0530, Rajkumar Manoharan wrote: > > > >> > I know we currently don't allow powersave when there's more than one > >> > interface, but we still allow it while there are monitor interfaces and > >> > a monitor interface could be sending packets, which would violate the > >> > flush() contract with the driver -- the driver may expect not to get any > >> > packets during flush. > > > >> AFIK we also are not stopping tx queue of monitor iface on offchannel. > >> Doing so could help flush(). > > > > Hrm, indeed. And we can't even stop the queues there. We can pause them > > for the flush though. In fact, why don't we just stop device queues for > > flush and bypass this problem. > > If the device queues are stopped, we have to find some other fix for > this power save issue since null func frame will be queued to pending > frames as I mentioned earlier. Can we have this patch merged and fix > the monitor vif issue for this case and the scanning case later? I > have also sent a RFC patch earlier with stopping device queues and a > new PS_PENDING flag for this > (http://marc.info/?l=linux-wireless&m=129775059910372&w=3) That patch > also addresses this race. I think for a first solution we can probably get away not worrying about monitor injection frames, since typically they'd be used by P2P things that disable powersave anyway. Right? And we already have the monitor vs. flush problem anyway. 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
