On Tue, Feb 15, 2011 at 6:14 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2011-02-08 at 15:43 +0530, Vivek Natarajan wrote: > >> > Maybe the subif queues should be stopped, then flush, then tx nullfunc, >> > then stop all queues to configure the HW or something like that? >> >> I tried this sequence: >> the subif queues stopped, then flush, then tx nullfunc, and wake subif >> queues,(we cannot have the queues stopped till we receive tx_status >> because nullfunc might have failed during tx path itself and mac80211 >> will not receive tx_status) > > I've recently been thinking about this -- I'm thinking that maybe we > should change this behaviour. Right now the tx() routine basically > always returns OK (except in at76) and I suppose instead it could return > whether the frame was queued up successfully... > >> After some time interval, once again stop queues on receiving ack for >> nullfunc, configure the hw and then wake up queues. So, during the >> above time interval, there is a race of queuing a frame to the hw. I >> have tested this and the issue is quickly reproducible. > > Right. The code that sends the nullfunc -- I think it can probably > sleep? If so, instead of starting the queue for the TX it could just > flush TX again after sending the nullfunc -- after that either it had > status for the frame, or the frame was dropped, no? So, this requires changing all the drivers to return the status for tx() routine. And this is how I understand this: stop queues, then send nullfunc, then do a flush to get the status and wake queues again irrespective of acked or not(but set the ACK_STATUS correspondingly). If tx() routine of nullfunc fails, then also wake the queues. I have sent another version with PS_PENDING and stop/wake queues combined. That addresses the race that you had mentioned earlier. Do we need that? Thanks, Vivek. -- 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
