More on ath10k_flush.

[Michal Kazior]

On 1 April 2014 02:24, Ben Greear <greearb at candelatech.com> wrote:
> So, I tried adding lots of debug to the ath10k_flush,
> and I think I might have found the issue.
>
> My test case is:  create 32 stations, start TCP on all of them,
> then reset (effectively ifdown;ifup) the station vifs.
>
> I get lots of spews because the ath10k_flush call thinks it is
> hanging.  But, based on the debug, I think the problem is that
> the tx logic is continuing to accept packets while the flush
> is trying to happen.
>
> If my debugging stats are correct, the NIC managed to send around 4000
> frames during the flush attempt, and the ath10k driver processed lots of
> tx completions as well.  But there are still lots of pkts
> pending tx and the tx queue was never empty.
>
> ath10k: failed to flush transmit queue (skip 0 ar-state 1 pending_tx 1009  pre-pending-tx: 1045): 0
> ath10k: pre: htc-send-tot: 3423  htt-tx 2545397  tx-compl 2544355  mgt-tx 0  mgt-compl 0
> ath10k: post: htc-send-tot: 3424  htt-tx 2630981  tx-compl 2630156  mgt-tx 0  mgt-compl 0
> ath10k: pre: hw-queued: 124395  hw-reaped: 124394
> ath10k: post: hw-queued: 128418  hw-reaped: 128417

What do these prints reflect exactly? What base upstream ath10k commit
are you on?


> Do we need to somehow shut down all tx logic during the ath10k_flush
> so that (other?) stations cannot transmit?

This seems strange. drv_flush() is called with all tx queues being
stopped in mac80211 with IEEE80211_QUEUE_STOP_REASON_FLUSH. I guess
you can still receive a few frames (due to SMP with many interfaces),
but that's it (at most num_cpus-1 I guess). You shouldn't be seeing
4000 frames being queued while you flush.


Michał