invalid vht params rate 1920 100kbps nss 2 mcs 9

invalid vht params rate 1920 100kbps nss 2 mcs 9

[Paul Menzel]

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


Kind regards,

Paul


```
Jun 16 11:38:15 abreu kernel: Linux version 
6.10.0-rc3-00174-ga3e18a540541 (build@bohemianrhapsody.molgen.mpg.de) 
(gcc (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) 
#196 SMP PREEMPT_DYNAMIC Sun Jun 16 06:02:29 CEST 2024
[…]
Jun 16 11:38:15 abreu kernel: DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 
2.21.0 06/02/2022
[…]
Jun 16 11:38:33 abreu kernel: ath10k_pci 0000:3a:00.0: enabling device 
(0000 -> 0002)
Jun 16 11:38:33 abreu kernel: ath10k_pci 0000:3a:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: qca6174 hw3.2 
target 0x05030000 chip_id 0x00340aff sub 1a56:1535
Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: kconfig debug 0 
debugfs 0 tracing 0 dfs 0 testmode 0
Jun 16 11:38:34 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
Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: board_file api 2 
bmi_id N/A crc32 d2863f91
Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: htt-ver 3.87 
wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
Jun 16 11:38:34 abreu kernel: ath: EEPROM regdomain: 0x6c
Jun 16 11:38:34 abreu kernel: ath: EEPROM indicates we should expect a 
direct regpair map
Jun 16 11:38:34 abreu kernel: ath: Country alpha2 being used: 00
Jun 16 11:38:34 abreu kernel: ath: Regpair used: 0x6c
[…]
Jun 16 11:39:20 abreu kernel: wlp58s0: authenticate with 
70:18:a7:0e:f7:cb (local address=9c:b6:d0:d1:6a:b1)
Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
(try 1/3)
Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
(try 2/3)
Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
(try 3/3)
Jun 16 11:39:20 abreu kernel: wlp58s0: authentication with 
70:18:a7:0e:f7:cb timed out
Jun 16 11:39:22 abreu kernel: wlp58s0: authenticate with 
4c:bc:48:39:16:ab (local address=9c:b6:d0:d1:6a:b1)
Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
(try 1/3)
Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
(try 2/3)
Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
(try 3/3)
Jun 16 11:39:22 abreu kernel: wlp58s0: authentication with 
4c:bc:48:39:16:ab timed out
Jun 16 11:39:24 abreu kernel: wlp58s0: authenticate with 
4c:bc:48:38:d8:4b (local address=9c:b6:d0:d1:6a:b1)
Jun 16 11:39:24 abreu kernel: wlp58s0: send auth to 4c:bc:48:38:d8:4b 
(try 1/3)
Jun 16 11:39:24 abreu kernel: wlp58s0: authenticated
Jun 16 11:39:24 abreu kernel: wlp58s0: associate with 4c:bc:48:38:d8:4b 
(try 1/3)
Jun 16 11:39:24 abreu kernel: wlp58s0: RX AssocResp from 
4c:bc:48:38:d8:4b (capab=0x1101 status=0 aid=30)
Jun 16 11:39:24 abreu kernel: wlp58s0: associated
Jun 16 11:39:24 abreu kernel: wlp58s0: Limiting TX power to 20 (23 - 3) 
dBm as advertised by 4c:bc:48:38:d8:4b
Jun 16 11:39:50 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:39:56 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:02 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:08 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:20 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:26 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:32 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:38 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:43 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:40:49 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:41:01 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:41:13 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:41:19 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
params rate 1920 100kbps nss 2 mcs 9
Jun 16 11:41:21 abreu kernel: wlp58s0: deauthenticating from 
4c:bc:48:38:d8:4b by local choice (Reason: 3=DEAUTH_LEAVING)

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[James Prestwood]

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

>
>
> Kind regards,
>
> Paul
>
>
> ```
> Jun 16 11:38:15 abreu kernel: Linux version 
> 6.10.0-rc3-00174-ga3e18a540541 (build@bohemianrhapsody.molgen.mpg.de) 
> (gcc (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) 
> #196 SMP PREEMPT_DYNAMIC Sun Jun 16 06:02:29 CEST 2024
> […]
> Jun 16 11:38:15 abreu kernel: DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 
> 2.21.0 06/02/2022
> […]
> Jun 16 11:38:33 abreu kernel: ath10k_pci 0000:3a:00.0: enabling device 
> (0000 -> 0002)
> Jun 16 11:38:33 abreu kernel: ath10k_pci 0000:3a:00.0: pci irq msi 
> oper_irq_mode 2 irq_mode 0 reset_mode 0
> Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: qca6174 hw3.2 
> target 0x05030000 chip_id 0x00340aff sub 1a56:1535
> Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: kconfig debug 0 
> debugfs 0 tracing 0 dfs 0 testmode 0
> Jun 16 11:38:34 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
> Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: board_file api 
> 2 bmi_id N/A crc32 d2863f91
> Jun 16 11:38:34 abreu kernel: ath10k_pci 0000:3a:00.0: htt-ver 3.87 
> wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
> Jun 16 11:38:34 abreu kernel: ath: EEPROM regdomain: 0x6c
> Jun 16 11:38:34 abreu kernel: ath: EEPROM indicates we should expect a 
> direct regpair map
> Jun 16 11:38:34 abreu kernel: ath: Country alpha2 being used: 00
> Jun 16 11:38:34 abreu kernel: ath: Regpair used: 0x6c
> […]
> Jun 16 11:39:20 abreu kernel: wlp58s0: authenticate with 
> 70:18:a7:0e:f7:cb (local address=9c:b6:d0:d1:6a:b1)
> Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
> (try 1/3)
> Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
> (try 2/3)
> Jun 16 11:39:20 abreu kernel: wlp58s0: send auth to 70:18:a7:0e:f7:cb 
> (try 3/3)
> Jun 16 11:39:20 abreu kernel: wlp58s0: authentication with 
> 70:18:a7:0e:f7:cb timed out
> Jun 16 11:39:22 abreu kernel: wlp58s0: authenticate with 
> 4c:bc:48:39:16:ab (local address=9c:b6:d0:d1:6a:b1)
> Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
> (try 1/3)
> Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
> (try 2/3)
> Jun 16 11:39:22 abreu kernel: wlp58s0: send auth to 4c:bc:48:39:16:ab 
> (try 3/3)
> Jun 16 11:39:22 abreu kernel: wlp58s0: authentication with 
> 4c:bc:48:39:16:ab timed out
> Jun 16 11:39:24 abreu kernel: wlp58s0: authenticate with 
> 4c:bc:48:38:d8:4b (local address=9c:b6:d0:d1:6a:b1)
> Jun 16 11:39:24 abreu kernel: wlp58s0: send auth to 4c:bc:48:38:d8:4b 
> (try 1/3)
> Jun 16 11:39:24 abreu kernel: wlp58s0: authenticated
> Jun 16 11:39:24 abreu kernel: wlp58s0: associate with 
> 4c:bc:48:38:d8:4b (try 1/3)
> Jun 16 11:39:24 abreu kernel: wlp58s0: RX AssocResp from 
> 4c:bc:48:38:d8:4b (capab=0x1101 status=0 aid=30)
> Jun 16 11:39:24 abreu kernel: wlp58s0: associated
> Jun 16 11:39:24 abreu kernel: wlp58s0: Limiting TX power to 20 (23 - 
> 3) dBm as advertised by 4c:bc:48:38:d8:4b
> Jun 16 11:39:50 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:39:56 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:02 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:08 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:20 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:26 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:32 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:38 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:43 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:40:49 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:41:01 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:41:13 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:41:19 abreu kernel: ath10k_pci 0000:3a:00.0: invalid vht 
> params rate 1920 100kbps nss 2 mcs 9
> Jun 16 11:41:21 abreu kernel: wlp58s0: deauthenticating from 
> 4c:bc:48:38:d8:4b by local choice (Reason: 3=DEAUTH_LEAVING)
>

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

James Prestwood <prestwoj@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?

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[James Prestwood]

Hi Kalle,

On 6/17/24 8:27 AM, Kalle Valo wrote:
> James Prestwood <prestwoj@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). 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. Would we 
also want to restrict the workaround to specific hardware/firmware?
>

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

+ baochen

James Prestwood <prestwoj@gmail.com> writes:

> Hi Kalle,
>
> On 6/17/24 8:27 AM, Kalle Valo wrote:
>> James Prestwood <prestwoj@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?

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 6/18/2024 6:33 PM, Kalle Valo wrote:
> + baochen
> 
> James Prestwood <prestwoj@gmail.com> writes:
> 
>> Hi Kalle,
>>
>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>> James Prestwood <prestwoj@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?
will check with firmware team first.

> 

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 6/18/2024 6:33 PM, Kalle Valo wrote:
> + baochen
> 
> James Prestwood <prestwoj@gmail.com> writes:
> 
>> Hi Kalle,
>>
>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>> James Prestwood <prestwoj@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.

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.


> 

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Paul Menzel]

Dear Baochen,


Thank you for your reply.

Am 26.06.24 um 10:53 schrieb Baochen Qiang:

> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>> + baochen
>>
>> James Prestwood <prestwoj@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
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

I believe it’s only happening with Cisco networks. I am happy to test a 
patch.

By the way, is the firmware version logged by Linux?

     ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 
0x00340aff sub 1a56:1535
     ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 
testmode 0
     ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 
features wowlan,ignore-otp,mfp crc32 bf907c7c
     ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
     ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp 
max-sta 32 raw 0 hwcrypto 1

Is it 4.4.1-00288? How can I find the file in `/lib/firmware/`?


Kind regards,

Paul

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

Paul Menzel <pmenzel@molgen.mpg.de> writes:

> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>
>> 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.

I assume this means that the firmware version
WLAN.RM.4.4.1-00241-QCARMSWPZ-1 or newer has the fix.

>> 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
> 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
>
> I believe it’s only happening with Cisco networks. I am happy to test
> a patch.
>
> By the way, is the firmware version logged by Linux?
>
>     ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id
>     0x00340aff sub 1a56:1535
>     ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
>     testmode 0
>     ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6
>     features wowlan,ignore-otp,mfp crc32 bf907c7c
>     ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
>     ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp
>     max-sta 32 raw 0 hwcrypto 1
>
> Is it 4.4.1-00288?

Yes, that should be WLAN.RM.4.4.1-00288-QCARMSWPZ-1. But I don't know
why 'QCARMSWPZ-1' is not printed by ath10k, maybe we have a bug
somewhere.

> How can I find the file in `/lib/firmware/`?

It should be in ath10k/QCA6174/hw3.0/firmware-6.bin.

All firmware releases are available here:

https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads

And more info here:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Paul Menzel]

Dear Kalle,


Am 26.06.24 um 12:16 schrieb Kalle Valo:
> Paul Menzel writes:
> 
>> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>>
>>> 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.
> 
> I assume this means that the firmware version
> WLAN.RM.4.4.1-00241-QCARMSWPZ-1 or newer has the fix.
> 
>>> 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
>> 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
>>
>> I believe it’s only happening with Cisco networks. I am happy to test
>> a patch.
>>
>> By the way, is the firmware version logged by Linux?
>>
>>      ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
>>      ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
>>      ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp crc32 bf907c7c
>>      ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
>>      ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
>>
>> Is it 4.4.1-00288?
> 
> Yes, that should be WLAN.RM.4.4.1-00288-QCARMSWPZ-1. But I don't know
> why 'QCARMSWPZ-1' is not printed by ath10k, maybe we have a bug
> somewhere.
> 
>> How can I find the file in `/lib/firmware/`?
> 
> It should be in ath10k/QCA6174/hw3.0/firmware-6.bin.
> 
> All firmware releases are available here:
> 
> https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads
> 
> And more info here:
> 
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware

Thank you. It looks like the latest firmware version is 309, and Debian 
sid/unstable still ships version 288 in *firmware-atheros* 20230625-2 [1].

Unfortunately, there does not seem to be a change-log for version 309 
(or any version for that matter). I am going to manually copy it anyway, 
but it’d be nice, if I knew what to expect. ;-)


Kind regards,

Paul


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074308
      "firmware-atheros: QCA 6174: Newest version 309 missing"

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

Paul Menzel <pmenzel@molgen.mpg.de> writes:

>> All firmware releases are available here:
>> https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware/-/tree/main/QCA6174/hw3.0/4.4.1?ref_type=heads
>> And more info here:
>> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/firmware
>
> Thank you. It looks like the latest firmware version is 309, and
> Debian sid/unstable still ships version 288 in *firmware-atheros*
> 20230625-2 [1].
>
> Unfortunately, there does not seem to be a change-log for version 309
> (or any version for that matter). I am going to manually copy it
> anyway, but it’d be nice, if I knew what to expect. ;-)

Yeah, unfortunately there are no changelogs available for firmware
releases but I do understand the need for those. There has been
discussions to create them but no success yet.

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[James Prestwood]

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@gmail.com> writes:
>>
>>> Hi Kalle,
>>>
>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>> James Prestwood <prestwoj@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!

Thanks,

James

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

James Prestwood <prestwoj@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@gmail.com> writes:
>>>
>>>> Hi Kalle,
>>>>
>>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>>> James Prestwood <prestwoj@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?

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

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

Re: 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@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@gmail.com> writes:
>>>>
>>>>> Hi Kalle,
>>>>>
>>>>> On 6/17/24 8:27 AM, Kalle Valo wrote:
>>>>>> James Prestwood <prestwoj@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.

> 

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 6/26/2024 5:12 PM, Paul Menzel wrote:
> Dear Baochen,
> 
> 
> Thank you for your reply.
> 
> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
> 
>> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>>> + baochen
>>>
>>> James Prestwood <prestwoj@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.

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

> 
> I believe it’s only happening with Cisco networks. I am happy to test a patch.
> 
> By the way, is the firmware version logged by Linux?
> 
>     ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
>     ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
>     ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp crc32 bf907c7c
>     ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
>     ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
> 
> Is it 4.4.1-00288? How can I find the file in `/lib/firmware/`?
> 
> 
> Kind regards,
> 
> Paul

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Paul Menzel]

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Paul Menzel]

Dear Baochen,


Am 05.07.24 um 12:51 schrieb Baochen Qiang:
> 
> 
> On 7/5/2024 2:55 PM, Paul Menzel wrote:

>> 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@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@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.
Sorry, I meant, I do not know, what the access points were.

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

Please tell me how I enable full logging. Also, I cannot promise I am 
going to be in the area with that WiFI in the next weeks.

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

Don’t hold your breath, that I am going to be able to get to the public 
WiFi network for 1. in the next weeks.

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 7/5/2024 7:52 PM, Paul Menzel wrote:
> 
> Dear Baochen,
> 
> 
> Am 05.07.24 um 12:51 schrieb Baochen Qiang:
>>
>>
>> On 7/5/2024 2:55 PM, Paul Menzel wrote:
> 
>>> 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@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@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.
> Sorry, I meant, I do not know, what the access points were.
Sorry, I commented at the wrong line :(

I was meaning the station you were using (i.e, the one you hit this issue) is QCA6174.

> 
>> 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,
> 
> Please tell me how I enable full logging. 
once boot, first unload ath10k modules by 

sudo modprobe -r ath10k_pci

then load ath10k modules with

sudo modprobe ath10k_core debug_mask=0xffffffff
sudo modprobe ath10k_pci

you should see lots of prints now

Also, I cannot promise I am going to be in the area with that WiFI in the next weeks.
Never mind.

> 
>>>>> 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.
> 
> Don’t hold your breath, that I am going to be able to get to the public WiFi network for 1. in the next weeks.
> 
>>> 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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

Baochen Qiang <quic_bqiang@quicinc.com> writes:

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

I'm not sure why would we want to wait for the NSS 3 to be solved? Based
on my (limited) understanding I think it would be good to submit patches
for solved issues now.

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Kalle Valo]

Baochen Qiang <quic_bqiang@quicinc.com> writes:

>>> 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,
>> 
>> Please tell me how I enable full logging.
>
> once boot, first unload ath10k modules by 
>
> sudo modprobe -r ath10k_pci
>
> then load ath10k modules with
>
> sudo modprobe ath10k_core debug_mask=0xffffffff
> sudo modprobe ath10k_pci
>
> you should see lots of prints now

BTW the extensive debug messages can slow down the system so there's
also the option of using tracing which is a lot faster:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#tracing

Though I have not tested that for a long time but I hope it still works.

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

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

Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

[Baochen Qiang]

On 7/8/2024 6:33 PM, Kalle Valo wrote:
> Baochen Qiang <quic_bqiang@quicinc.com> writes:
> 
>>>>> 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.
> 
> I'm not sure why would we want to wait for the NSS 3 to be solved? Based
> on my (limited) understanding I think it would be good to submit patches
> for solved issues now.
Sure, will do today.

>