invalid vht params rate 1920 100kbps nss 2 mcs 9

Thu Jul 4 23:55:45 PDT 2024

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.

>> 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.

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