Message-ID: <fb8acc69-89aa-4b26-91b4-e768ae4c2238@molgen.mpg.de>
Date: Fri, 5 Jul 2024 13:52:48 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Baochen Qiang <quic_bqiang@...cinc.com>
Cc: Kalle Valo <kvalo@...nel.org>, James Prestwood <prestwoj@...il.com>,
 linux-wireless@...r.kernel.org, ath10k@...ts.infradead.org,
 LKML <linux-kernel@...r.kernel.org>, Chun Wu <chunwu@....qualcomm.com>
Subject: Re: invalid vht params rate 1920 100kbps nss 2 mcs 9


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@...il.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@...emianrhapsody.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

Powered by blists - more mailing lists