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.
On 6/18/2024 6:33 PM, Kalle Valo wrote:
+ baochenOK, there are two issues here:
James Prestwood <prestwoj@xxxxxxxxx> writes:
Hi Kalle,Good point.
On 6/17/24 8:27 AM, Kalle Valo wrote:
James Prestwood <prestwoj@xxxxxxxxx> writes:I think its more than this combination (Paul's are different).
Hi Paul,More reliable link to the discussion:
On 6/16/24 6:10 AM, Paul Menzel wrote:
Dear Linux folks,This has been reported/discussed [1]. It was hinted that there was a
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
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
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?
So how many combinations are we willing to add here? Seems like thatYeah, but there haven't been that many different values reported yet,
could get out of hand if there are more than a few invalid
combinations.
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 specificGood idea, limiting per hardware would be simple to implement using
hardware/firmware?
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?
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.
That would be great!
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.