Re: about Mac80211 scan issue

[Stanislaw Gruszka <sgruszka@redhat.com>]

On Wed, Feb 09, 2011 at 09:58:46AM +0800, 李朝明 wrote:
> 	recently, I found some issues on mac80211 scan about null packet.
> 	
> 	Before we switch channel in scanning, we will send null packet to AP
> to indicate that we will sleep.
> 	but at the same time there maybe lots of packets in HW tx buffer
> witch are all ready to tx but with out 
> 	power save flag set to 1. if we send this null packet after these
> tx buffer packets in a low priority,

We have ieee80211_ops->flush() method to send all pending tx frames from
hw before sending null frame. I see rtlwifi does not have it.

> this will 
> 	cause follwing null packets fail because follwing check in
> __ieee80211_tx:
> 		if (local->queue_stop_reasons[q] ||
> 		    (!txpending && !skb_queue_empty(&local->pending[q])))
> 			ret = IEEE80211_TX_PENDING;
> 
> 	But if we send these null before there tx buffer packets packets in
> a high priority, these packets will 
> 	be send after this null before switch channel. and switch channel
> will cause RX packet from AP fail abruptly,
> 	this abruptly fail will cause DELETE BA for some AP like Belkin-8233
> 11N mode or dis-associate by some AP like Dir855 5G 11N mode
> 	when we  to test Throughput use chariot
> 
> 	And I found that after power save  null packet have been sent, there
> are lots packet send to driver from mac80211,
> 	should we stop all queues after we send power save  null packet  and
> recover all queues after we send awake null packet.
> 
> 	So, I don't kown if it's a mac80211's issue, Could you give some
> help?

I'm not sure if I understand problem you described. Anyway, maybe is
enaugh to implement ->flush() in rtlwifi to solve the problem?

Stanislaw