lkml.org 
[lkml]   [2021]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 5/5] ath10k: reduce invalid ht params rate message noise
    Date
    Shuah Khan <skhan@linuxfoundation.org> writes:

    > On 2/10/21 1:28 AM, Kalle Valo wrote:
    >> Wen Gong <wgong@codeaurora.org> writes:
    >>
    >>> On 2021-02-10 08:42, Shuah Khan wrote:
    >>>> ath10k_mac_get_rate_flags_ht() floods dmesg with the following
    >>>> messages,
    >>>> when it fails to find a match for mcs=7 and rate=1440.
    >>>>
    >>>> supported_ht_mcs_rate_nss2:
    >>>> {7, {1300, 2700, 1444, 3000} }
    >>>>
    >>>> ath10k_pci 0000:02:00.0: invalid ht params rate 1440 100kbps nss 2
    >>>> mcs 7
    >>>>
    >>>> dev_warn_ratelimited() isn't helping the noise. Use dev_warn_once()
    >>>> instead.
    >>>>
    >>>> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    >>>> ---
    >>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
    >>>> 1 file changed, 3 insertions(+), 2 deletions(-)
    >>>>
    >>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
    >>>> b/drivers/net/wireless/ath/ath10k/mac.c
    >>>> index 3545ce7dce0a..276321f0cfdd 100644
    >>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
    >>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
    >>>> @@ -8970,8 +8970,9 @@ static void ath10k_mac_get_rate_flags_ht(struct
    >>>> ath10k *ar, u32 rate, u8 nss, u8
    >>>> *bw |= RATE_INFO_BW_40;
    >>>> *flags |= RATE_INFO_FLAGS_SHORT_GI;
    >>>> } else {
    >>>> - ath10k_warn(ar, "invalid ht params rate %d 100kbps nss %d mcs %d",
    >>>> - rate, nss, mcs);
    >>>> + dev_warn_once(ar->dev,
    >>>> + "invalid ht params rate %d 100kbps nss %d mcs %d",
    >>>> + rate, nss, mcs);
    >>>> }
    >>>> }
    >>>
    >>> The {7, {1300, 2700, 1444, 3000} } is a correct value.
    >>> The 1440 is report from firmware, its a wrong value, it has fixed in
    >>> firmware.
    >>
    >> In what version?
    >>
    >
    > Here is the info:
    >
    > ath10k_pci 0000:02:00.0: qca6174 hw3.2 target 0x05030000 chip_id
    > 0x00340aff sub 17aa:0827
    >
    > ath10k_pci 0000:02:00.0: firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1
    > api 6 features wowlan,ignore-otp,mfp crc32 29eb8ca1
    >
    > ath10k_pci 0000:02:00.0: board_file api 2 bmi_id N/A crc32 4ac0889b
    >
    > ath10k_pci 0000:02:00.0: htt-ver 3.60 wmi-op 4 htt-op 3 cal otp
    > max-sta 32 raw 0 hwcrypto 1
    >
    >>> If change it to dev_warn_once, then it will have no chance to find the
    >>> other wrong values which report by firmware, and it indicate
    >>> a wrong value to mac80211/cfg80211 and lead "iw wlan0 station dump"
    >>> get a wrong bitrate.
    >>
    >
    > Agreed.
    >
    >> I agree, we should keep this warning. If the firmware still keeps
    >> sending invalid rates we should add a specific check to ignore the known
    >> invalid values, but not all of them.
    >>
    >
    > Would it be helpful to adjust the default rate limits and set the to
    > a higher value instead. It might be difficult to account all possible
    > invalid values?
    >
    > Something like, ath10k_warn_ratelimited() to adjust the
    >
    > DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST using
    > DEFINE_RATELIMIT_STATE
    >
    > Let me know if you like this idea. I can send a patch in to do this.
    > I will hang on to this firmware version for a little but longer, so
    > we have a test case. :)

    I would rather first try to fix the root cause, which is the firmware
    sending invalid rates. Wen, you mentioned there's a fix in firmware. Do
    you know which firmware version (and branch) has the fix?

    --
    https://patchwork.kernel.org/project/linux-wireless/list/

    https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

    \
     
     \ /
      Last update: 2021-02-11 12:51    [W:5.744 / U:0.672 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site