From: Ben Greear <greearb@candelatech.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: More on ath10k_flush.
Date: Tue, 01 Apr 2014 06:12:00 -0700 [thread overview]
Message-ID: <533ABB20.3000407@candelatech.com> (raw)
In-Reply-To: <CA+BoTQm8YEaz7B0jF1GDQrfczEA3tToJPTMx0oS-oZpH25Rkrw@mail.gmail.com>
On 03/31/2014 10:44 PM, Michal Kazior wrote:
> On 1 April 2014 02:24, Ben Greear <greearb@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.
Subsequent debugging makes me think the extra packets are not coming
from the upper stack. Possibly there are ath10k<->firmware management messages
being queued or something like that?
I'm out of office today, will post the debug patch when I get a chance.
Thanks,
Ben
>
>
> Michał
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2014-04-01 13:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 0:24 More on ath10k_flush Ben Greear
2014-04-01 5:44 ` Michal Kazior
2014-04-01 13:12 ` Ben Greear [this message]
2014-04-02 5:00 ` Michal Kazior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533ABB20.3000407@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=michal.kazior@tieto.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox