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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/msg13406.html
More reliable link to the discussion:
https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.skhan@xxxxxxxxxxxxxxxxxxx/
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@xxxxxxxxxxxxxx/
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) (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
