| Message ID | 76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.skhan@linuxfoundation.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | ath10k fixes for warns | expand |
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. 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.
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? > 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. 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.
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. :) thanks, -- Shuah
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?
On 2/11/21 4:24 AM, Kalle Valo wrote: > 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? > Picking this back up. Wen, which firmware version has this fix? I can test this on my system and get rid of the noisy messages. :) thanks, -- Shuah
On 2/26/21 10:01 AM, Shuah Khan wrote: > On 2/11/21 4:24 AM, Kalle Valo wrote: >> 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? >> > > Picking this back up. Wen, which firmware version has this fix? I can > test this on my system and get rid of the noisy messages. :) > > thanks, > -- Shuah I know its been years, but reading through this Wen mentioned there is a fix in the firmware? I haven't tried all of the firmware binaries in Kalle's tree but the most recent definitely still spam the logs with this message. Is there a specific version I can use to get rid of these? One thing to note is the older "firmware-4.bin" did not have this problem, but was met with worse problems like driver/firmware crashes. Thanks, James > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k >
(just a resend with Wen's current e-mail address, no further comments) On 9/20/2023 11:27 AM, James Prestwood wrote: > On 2/26/21 10:01 AM, Shuah Khan wrote: >> On 2/11/21 4:24 AM, Kalle Valo wrote: >>> 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? >>> >> >> Picking this back up. Wen, which firmware version has this fix? I can >> test this on my system and get rid of the noisy messages. :) >> >> thanks, >> -- Shuah > > I know its been years, but reading through this Wen mentioned there is a > fix in the firmware? I haven't tried all of the firmware binaries in > Kalle's tree but the most recent definitely still spam the logs with > this message. Is there a specific version I can use to get rid of these? > > One thing to note is the older "firmware-4.bin" did not have this > problem, but was met with worse problems like driver/firmware crashes.
On 9/20/23 12:23 PM, Jeff Johnson wrote: > (just a resend with Wen's current e-mail address, no further comments) > On 9/20/2023 11:27 AM, James Prestwood wrote: >> On 2/26/21 10:01 AM, Shuah Khan wrote: >>> On 2/11/21 4:24 AM, Kalle Valo wrote: >>>> 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? >>>> >>> >>> Picking this back up. Wen, which firmware version has this fix? I can >>> test this on my system and get rid of the noisy messages. :) >>> >>> thanks, >>> -- Shuah >> >> I know its been years, but reading through this Wen mentioned there >> is a fix in the firmware? I haven't tried all of the firmware >> binaries in Kalle's tree but the most recent definitely still spam >> the logs with this message. Is there a specific version I can use to >> get rid of these? >> >> One thing to note is the older "firmware-4.bin" did not have this >> problem, but was met with worse problems like driver/firmware crashes. I hate to keep bringing this up, and if its a "won't fix" type of issue you don't have to tell me twice and I can deal with it out of tree. Any answer would be greatly appreciated so I know how to proceed, and if its something I can wait for on upstream or handle on my own. Since its apparently a firmware bug its not something I can fix, or I would try to myself. (sorry, my last inquiry was mistakenly from a different email address). Thanks, James
On 11/14/2023 11:31 AM, James Prestwood wrote: > I hate to keep bringing this up, and if its a "won't fix" type of issue > you don't have to tell me twice and I can deal with it out of tree. Any > answer would be greatly appreciated so I know how to proceed, and if its > something I can wait for on upstream or handle on my own. Since its > apparently a firmware bug its not something I can fix, or I would try to > myself. I've asked the development team for an update. /jeff
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); } }
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(-)