archive mirror
 help / color / mirror / Atom feed
From: Sebastian Gottschall <>
Subject: Re: [PATCH] ath10k: remove TX lock from ath10k_htt_tx_inc_pending
Date: Thu, 6 May 2021 05:20:05 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Am 17.09.2019 um 09:12 schrieb Kalle Valo:
> Erik Stromdahl <> wrote:
>> This commit removes the call to ath10k_mac_tx_lock() from
>> ath10k_htt_tx_inc_pending() in case the high water mark is reached.
>> ath10k_mac_tx_lock() calls ieee80211_stop_queues() in order to stop
>> mac80211 from pushing more TX data to the driver (this is the TX lock).
>> If a driver is trying to fetch an skb from a queue while the queue is
>> stopped, ieee80211_tx_dequeue() will return NULL.
>> So, in ath10k_mac_tx_push_txq(), there is a risk that the call to
>> ath10k_htt_tx_inc_pending() results in a stop of the mac80211 TX queues
>> just before the skb is fetched.
>> This will cause ieee80211_tx_dequeue() to return NULL and
>> ath10k_mac_tx_push_txq() to exit prematurely and return -ENOENT.
>> Before the function returns ath10k_htt_tx_dec_pending() will be called.
>> This call will re-enable the TX queues through ath10k_mac_tx_unlock().
>> When ath10k_mac_tx_push_txq() has returned, the TX queue will be
>> returned back to mac80211 with ieee80211_return_txq() without the skb
>> being properly consumed.
>> Since the TX queues were re-enabled in the error exit path of
>> ath10k_mac_tx_push_txq(), mac80211 can continue pushing data to the
>> driver. If the hardware does not consume the data, the above mentioned
>> case will be repeated over and over.
>> A case when the hardware is not able to transmit the data from the host
>> is when a STA has been dis-associated from an AP and has not yet been
>> able to re-associate. In this case there will be no TX_COMPL_INDs from
>> the hardware, resulting in the TX counter not be decremented.
>> This phenomenon has been observed in both a real and a test setup.
>> In order to fix this, the actual TX locking (the call to
>> ath10k_mac_tx_lock()) was removed from ath10k_htt_tx_inc_pending().
>> Instead, ath10k_mac_tx_lock() is called separately after the skb has
>> been fetched (after the call to ieee80211_tx_dequeue()). At this point
>> it is OK to stop the queues.
>> Signed-off-by: Erik Stromdahl <>
> What hardware and firmware versions did you test this? Please always add that
> to the commit log.
> As Erik mostly works on SDIO I assume PCI is not that well tested. Has anyone
> else tried this?
i can tell you that we observed the same issue on 10.2 qca988x pcie 
chipsets. see my patch from yesterday.
but we are testing now if this patch here provides the same solution.


ath10k mailing list

      reply	other threads:[~2021-05-06  3:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-24 13:48 Erik Stromdahl
2019-08-26  2:44 ` Wen Gong
2019-08-26 16:55   ` Erik Stromdahl
2019-09-17  7:12 ` Kalle Valo
2021-05-06  3:20   ` Sebastian Gottschall [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: [PATCH] ath10k: remove TX lock from ath10k_htt_tx_inc_pending' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).