invalid vht params rate 1920 100kbps nss 2 mcs 9

Fri Jul 5 03:51:47 PDT 2024


On 7/5/2024 2:55 PM, Paul Menzel wrote:
> Dear Baochen,
> 
> 
> Am 05.07.24 um 04:47 schrieb Baochen Qiang:
> 
>> On 6/26/2024 5:12 PM, Paul Menzel wrote:
> 
>>> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>>>
>>>> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>>>>> + baochen
>>>>>
>>>>> James Prestwood <prestwoj at gmail.com> writes:
>>>
>>>>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>>>>> James Prestwood writes:
>>>
>>>>>>>> On 6/16/24 6:10 AM, Paul Menzel wrote:
> 
>>>>>>>>> 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.
>>> This is the issue from 2021, correct?
>>>
>>>> 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.
>>> Looking through the logs since May 2024, I have four different logs:
>>>
>>> 1.  invalid vht params rate 878 100kbps nss 3 mcs 2
>>
>> which chip are you using when you hit this nss 3 issue? QCA6174
>> firmware does not support NSS 3 so really weird.
> 
> This is all from the same device Dell XPS 13 9360 with QCA6174 and firmware 288.
> 
> ```
> Mai 20 12:07:09 abreu kernel: Linux version 6.9.0-09705-g08b269af52c0 (build at bohemianrhapsody.molgen.mpg.de) (gcc (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for Debian) 2.
> 42) #147 SMP PREEMPT_DYNAMIC Mon May 20 07:33:23 CEST 2024
> […]
> Mai 20 12:07:11 abreu kernel: ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp crc32 bf907c7c
> […]
> Mai 20 15:37:55 abreu wpa_supplicant[613]: wlp58s0: Trying to associate with e2:b3:70:83:01:af (SSID='public' freq=5500 MHz)
> […]
> Mai 20 15:37:55 abreu kernel: wlp58s0: authenticate with e2:b3:70:83:01:af (local address=9c:b6:d0:d1:6a:b1)
> Mai 20 15:37:55 abreu kernel: wlp58s0: send auth to e2:b3:70:83:01:af (try 1/3)
> Mai 20 15:37:55 abreu kernel: wlp58s0: authenticated
> Mai 20 15:37:55 abreu kernel: wlp58s0: associate with e2:b3:70:83:01:af (try 1/3)
> Mai 20 15:37:55 abreu kernel: wlp58s0: RX AssocResp from e2:b3:70:83:01:af (capab=0x1501 status=0 aid=4)
> […]
> Mai 20 15:39:29 abreu wpa_supplicant[613]: wlp58s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-55 noise=-97 txrate=300000
> […]
> Mai 20 15:54:44 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht params rate 878 100kbps nss 3 mcs 2
> ```
> 
> It was some public WiFi in some restaurant. No idea, what hardware they use. Maybe you can deduce this from the MAC address.
Then it is QCA6174 definitely.

Checked with firmware team and just know that, the TX rate info is generated by firmware directly but for RX rate it is from phy side. From firmware TX rate generation code seems NSS 3 is an impossible value, so it might be an RX rate generated by phy side. But I could not tell for now since the log is not complete. Paul, could you enable full ath10k log and try to reproduce? With full log we can check whether it is a RX rate issue,
> 
>>> 2.  invalid vht params rate 960 100kbps nss 1 mcs 9
>>> 3.  invalid vht params rate 1730 100kbps nss 2 mcs 9
>>> 4.  invalid vht params rate 1920 100kbps nss 2 mcs 9
>>
>> OK, these are due to mismatch between host and QCA6174 firmware, we
>> can update host to fix them.
Kalle, the root cause to these three warnings are clear now and if you agree I can submit patches to fix them. Or I can also wait until the NSS 3 issue is clear.

> 
> Nice. If there would be a test framework to test this, so I do not have to search for a Cisco network, that’d be great.
> 
>>> I believe it’s only happening with Cisco networks. I am happy to test a patch.
> 
> […]
> 
> 
> Kind regards,
> 
> Paul