invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 6/28/2024 2:25 AM, Kalle Valo wrote:
> James Prestwood <prestwoj at gmail.com> writes:
> 
>> HI Baochen,
>>
>> On 6/26/24 1:53 AM, Baochen Qiang wrote:
>>>
>>> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>>>> + baochen
>>>>
>>>> James Prestwood <prestwoj at gmail.com> writes:
>>>>
>>>>> Hi Kalle,
>>>>>
>>>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>>>> James Prestwood <prestwoj at gmail.com> writes:
>>>>>>
>>>>>>> Hi Paul,
>>>>>>>
>>>>>>> On 6/16/24 6:10 AM, Paul Menzel wrote:
>>>>>>>> Dear Linux folks,
>>>>>>>>
>>>>>>>>
>>>>>>>> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
>>>>>>>> connecting to a public WiFi:
>>>>>>>>
>>>>>>>>       ath10k_pci 0000:3a:00.0: invalid vht params rate 1920 100kbps
>>>>>>>> nss 2 mcs 9
>>>>>>> This has been reported/discussed [1]. It was hinted that there was a
>>>>>>> firmware fix for this, but none that I tried got rid of it. I got fed
>>>>>>> up enough with the logs filling up with this I patched our kernel to
>>>>>>> remove the warning. AFAICT it appears benign (?). Removing the warning
>>>>>>> was purely "cosmetic" so other devs stopped complaining about it :)
>>>>>>>
>>>>>>> [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
>>>>>> More reliable link to the discussion:
>>>>>>
>>>>>> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.skhan@linuxfoundation.org/
>>>>>>
>>>>>> I think we should add this workaround I mentioned in 2021:
>>>>>>
>>>>>>      "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."
>>>>>>
>>>>>>      https://lore.kernel.org/ath10k/87h7mktjgi.fsf@codeaurora.org/
>>>>>>
>>>>>> I guess that would be mcs == 7 and rate == 1440?
>>>>> I think its more than this combination (Paul's are different).
>>>> Good point.
>>>>
>>>>> So how many combinations are we willing to add here? Seems like that
>>>>> could get out of hand if there are more than a few invalid
>>>>> combinations.
>>>> Yeah, but there haven't been that many different values reported yet,
>>>> right? And I expect that ath10k user base will just get smaller in the
>>>> future so the chances are that we will get less reports.
>>>>
>>>>> Would we also want to restrict the workaround to specific
>>>>> hardware/firmware?
>>>> Good idea, limiting per hardware would be simple to implement using
>>>> hw_params. Of course we could even limit this per firmware version using
>>>> enum ath10k_fw_features, but not sure if that's worth all the extra work.
>>>>
>>>> Baochen, do you know more about this firmware bug? Any suggestions?
>>>
>>> OK, there are two issues here:
>>>
>>> 1. invalid HT rate: "ath10k_pci 0000:02:00.0: invalid ht params rate
>>> 1440 100kbps nss 2 mcs 7".
>>>
>>> As commented by Wen quite some time ago, this has been fixed from
>>> firmware side, and firmware newer than [ver:241] has the fix
>>> included.
>>
>> Thanks for pointing this out, I guess I didn't look close enough at
>> the log and missed "ht" vs "vht" when I brought it up on that older
>> thread. I thought i was seeing the same problem even with newer
>> firmware.
>>>
>>> 2. invaid VHT rate: "ath10k_pci 0000:3a:00.0: invalid vht params
>>> rate 1920 100kbps nss 2 mcs 9".
>>>
>>> After checking with firmware team, I thought this is because there
>>> is a mismatch in rate definition between host and firmware: In host,
>>> the rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
>>> supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
>>> {1730, 1920}. So seems we can update host definition to avoid this
>>> issue.
>>
>> That would be great!
> 
> Indeed! Baochen, can you work on a patch for ath10k to fix this?
Sure, Kalle.

>