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