This patch is working for at least iwldvm. It exposes what seems to
be an existing iwldvm driver bug, though. Driver and card continues
to work, making that a minor side show for now. (I started to look into
that a bit, maybe more about that in another mail later.)
Initial tests are indicating comparable speeds in my setup for iwldvm,
maybe trending to be a bit slower.
For now I'm interested what I may have missed or what should be done
differently, so we dare to merge it. I'll planning to run some more
tests and use iwldvm with this patch on my main workstation for some
days at least.
I followed up on the iwldvm driver issue.
The problem is, that the push API drivers are expecting that tx
immediately stops after calling ieee80211_stop_queue(). And this patch
breaks that.
For iwldvm this happens:
- the HW queues are getting full, iwldvm calls ieee80211_stop_queue()
- the (patched) mac80211 stops the queue but is not aborting the running
wake_tx_queue() tasklet. Which goes on to hand over skbs to the driver
- The driver runs out of the "internal reserve" hw buffers and starts to
add the new skbs to the overflow queue
- some hw buffers are reclaimed and the driver tries to process the skbs
in the overflow q
- For that it releases the internal lock for tx, assuming mac80211
stopped handing over skbs
- the still running wake_tx_queue() function from mac80211 hands over
the next skb, grapping the slot(s) intended to be used for the skbs in
the driver overflow queue.
- which breaks an iwlwifi internal rule how sequence numbers are mapped
to hw queue slots, causing the warning I got.
I'll fix that and send a new patch.
Alexander
