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? 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
