Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> writes:

Hi Kalle,

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





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux