Question on 10.4 firmware and fetch-indication logic.
Michal Kazior
michal.kazior at tieto.com
Tue Nov 1 10:56:27 PDT 2016
On 1 November 2016 at 18:21, Ben Greear <greearb at candelatech.com> wrote:
> I am testing on modified 4.7 kernel and modified firmware with QCA9984 NIC
> and lots of virtual station vdevs.
>
> The issue I am looking at currently is that I am seeing floods of these
> messages
> in some cases:
>
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci 0000:05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci 0000:05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci 0000:05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
> Nov 01 09:43:38 ath-9984 kernel: ath10k_pci 0000:05:00.0: fetch-ind: failed
> to lookup txq for peer_id 56 tid 7
>
> From this code in htt_rx.c:
>
> static void ath10k_htt_rx_tx_fetch_ind(struct ath10k *ar, struct sk_buff
> *skb)
> ...
>
> /* It is okay to release the lock and use txq because RCU
> read
> * lock is held.
> */
>
> if (unlikely(!txq)) {
> if (net_ratelimit())
> ath10k_warn(ar, "fetch-ind: failed to lookup
> txq for peer_id %hu tid %hhu\n",
> peer_id, tid);
> continue;
> }
>
>
> I am getting these after the vdev in question (and its peers) have been
> removed. I guess these
> must be stale buffers that are finally transmitted or cleaned up by the
> firmware after
> vdev has been deleted?
>
> I am curious if anyone else sees something similar, and if this is expected
> behaviour.
Hmm, WMI and HTT do use independent CE ring buffers but peer_ids are
unmapped in response to HTT events so it should be properly serialized
by firmware itself.
Did you happen to not remove peers prior to deleting vdev? Perhaps
that's the cause that triggers the !txq condition.
Perhaps it would make sense to flush (i.e. put up a barrier) HTT rx
after stopping vdev.
Michał
More information about the ath10k
mailing list