Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]

openwrt303 · November 8, 2020, 8:15am

On a TL-WDR3600 that was constantly rebooting when watching youtube live video streams, this error appeared using

logread -f

(before it froze and reboot itself)

Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.701972] ------------[ cut here ]------------
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.706692] WARNING: CPU: 0 PID: 0 at backports-4.19.137-1/net/mac80211/rx.c:4551 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.717760] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 127 (0x7f)
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.727385] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.795620] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.195 #0
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.801632] Stack : 00000000 800b2c34 80500000 804b066c 00000000 00000000 00000000 00000000
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.810146]         00000000 00000000 00000000 00000000 00000000 00000001 87c07cd0 19976158
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.818655]         87c07d68 00000000 00000000 00003f18 00000038 804491d8 00000008 00000000
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.827147]         000000d5 12e9009a 000000d4 00000000 87c07cb0 00000000 00000000 876675f0
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.835657]         87629da4 000011c7 00000000 87412080 00000002 80280814 00000000 80630000
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.844166]         ...
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.846648] Call Trace:
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.846659] [<800b2c34>] 0x800b2c34
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.852690] [<80500000>] 0x80500000
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.856258] [<804491d8>] 0x804491d8
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.859835] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.865840] [<80280814>] 0x80280814
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.869401] [<8006a56c>] 0x8006a56c
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.872939] [<8006a574>] 0x8006a574
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.876479] [<80084d30>] 0x80084d30
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.880039] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.886060] [<80084db8>] 0x80084db8
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.889634] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.895646] [<803034ac>] 0x803034ac
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.899212] [<80303694>] 0x80303694
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.902762] [<876d43f4>] 0x876d43f4 [ath9k_common@876d4000+0x2be0]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.909080] [<876e77c0>] 0x876e77c0 [ath9k@876e0000+0x18290]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.914844] [<876e77a0>] 0x876e77a0 [ath9k@876e0000+0x18290]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.920622] [<876e4a24>] 0x876e4a24 [ath9k@876e0000+0x18290]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.926363] [<800b8454>] 0x800b8454
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.929919] [<80087e1c>] 0x80087e1c
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.933455] [<800b4380>] 0x800b4380
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.936994] [<8044ed28>] 0x8044ed28
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.940548] [<800b8e24>] 0x800b8e24
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.944090] [<8022f740>] 0x8022f740
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.947625] [<800657d8>] 0x800657d8
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.951175]
Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.952691] ---[ end trace c85213225f7d126a ]---
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.225797] ------------[ cut here ]------------
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.230557] WARNING: CPU: 0 PID: 0 at backports-4.19.137-1/net/mac80211/rx.c:4551 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.241603] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 126 (0x7e)
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.251234] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.319477] CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.14.195 #0
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.326731] Stack : 00000000 800b2c34 80500000 804b066c 00000000 00000000 00000000 00000000
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.335228]         00000000 00000000 00000000 00000000 00000000 00000001 87c07cd0 19976158
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.343739]         87c07d68 00000000 00000000 00004a90 00000038 804491d8 00000008 00000000
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.352245]         000000fb af6189d9 000000fa 00000000 87c07cb0 00000000 00000000 876675f0
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.360751]         87629da4 000011c7 00000000 87412080 00000000 80280814 00000000 80630000
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.369256]         ...
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.371740] Call Trace:
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.371751] [<800b2c34>] 0x800b2c34
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.377782] [<80500000>] 0x80500000
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.381349] [<804491d8>] 0x804491d8
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.384904] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.390936] [<80280814>] 0x80280814
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.394479] [<8006a56c>] 0x8006a56c
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.398040] [<8006a574>] 0x8006a574
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.401583] [<80084d30>] 0x80084d30
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.405130] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.411172] [<80084db8>] 0x80084db8
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.414744] [<87629da4>] 0x87629da4 [mac80211@87600000+0x6c5c0]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.420772] [<803034ac>] 0x803034ac
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.424330] [<80303694>] 0x80303694
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.427903] [<876d43f4>] 0x876d43f4 [ath9k_common@876d4000+0x2be0]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.434201] [<876e77c0>] 0x876e77c0 [ath9k@876e0000+0x18290]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.439994] [<876e77a0>] 0x876e77a0 [ath9k@876e0000+0x18290]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.445761] [<876e4a24>] 0x876e4a24 [ath9k@876e0000+0x18290]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.451518] [<800b8454>] 0x800b8454
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.455062] [<80087e1c>] 0x80087e1c
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.458619] [<800b4380>] 0x800b4380
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.462155] [<8044ed28>] 0x8044ed28
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.465692] [<800b8e24>] 0x800b8e24
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.469253] [<8022f740>] 0x8022f740
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.472797] [<800657d8>] 0x800657d8
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.476346]
Sun Nov  8 01:38:22 2020 kern.warn kernel: [93082.477863] ---[ end trace c85213225f7d126b ]---

It is the first time that I get to see an error before the reboot.
I had Force 40mhz mode enabled on 2.412 GHz, which is the only radio enabled on this device, so I've unchecked Force 40mhz mode, since it may be the problem. it hasn't crashed again yet.

lleachii · November 8, 2020, 8:48am

If disabling the force 40 MHz fixed it, that's fine. Forcing 40 MHz does nothing on the client side anyways (except show a 40 MHz beacon).

openwrt303 · November 8, 2020, 5:36pm

I had it enabled on two devices both on OpenWrt client and OpenWrt master, now it is disabled on both. I wil report back if I get a crash, so far so good.

AlexG · November 16, 2020, 8:24am

I have 40Mhz forced for a least two month but today night got same messages first time.

In my case forcing 40Mhz changes link speed on client to 300Mbps. Looks like adapter forced to 2x MIMO.

lleachii · November 16, 2020, 8:30am

Wow, your equipment defys the laws of physics...or the law governing radio emissions.

(Tx speeds of clients are determined by clients; but you may wanna read up on the history of why that setting was removed from devices .)

EDIT: Also, what happens when one person (AP and their clients) is allowed to speed on a highway (the 2.4 GHz, or any channel where limited availability of bandwidth is in question) in bumper-to-bumper traffic?

Your solution seems like "just give 'em more room"... ...so, who gets "less room"?

...and more importantly...where does this "more room" actually come from?

AlexG · November 16, 2020, 9:03am

I don't know how to check config on Windows client but in case of forcing 40MHz windows shows 300 mbps link speed, and in case of not -- 150MHz. Speedtest also shows twice slower when 40 MHz is not forced.

lleachii · November 16, 2020, 9:54am

Ummmm wow, that's actual rate when you're passing traffic, as seen on the OpenWrt Overview or Wireless pages?

Do you actually have 40 MHz set on the AP setting page?
To be clear, we're referencing 2.4 GHz, correct?

I noticed...you didn't mention your actual ISP bandwidth though...

As a note...some chips manufactured before that was removed - happened to do just as you describe...they are legit devices, hence the button appears (and works). In my case, the clients do nothing, nor does the AP, except show a 40 MHz beacon...I've never seen a client or AP (except in a very rural area with zero neighbors in radio range) go into 40 MHz on 2.4 GHz; but my experience may vary from others.

Just so you can see if you're unaware aware (in a spacial-awareness kinda way) what 40 Mhz traffic in 2.4 GHz space does to other APs, especially if there's any significant amount of them (3 or more) sharing the bandwidth..let's not get into the case where someone's running 40 MHz; and others set overlapping channels (which I see a lot of people in the forum request) - keep in mind my "speeding friends allowed on the traffic-jammed highway" scenario":

~ from: https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)

AlexG · November 16, 2020, 10:06am

At this moment:

Capture

OK. ISP speed is 100mbps.

But, 40MHz forced:

Capture1

40MHz disabled:

Capture3

Capture2

lleachii · November 16, 2020, 12:34pm

I understand...and from experience from others in the forum - I get your joy; but you weren't clear (since it does relate to the OPs topic)...although, not sure the live streams would be fixed in this manner...given the OP's experience...maybe you don't understand why as proof...

Yes, 40 MHz; but was 40 MHz set here:

screen13

Also, more precisely, is this:

Because it should work just the same if width is set at 40 Mhz. Also:

And you stated:

You also don't note your results in either case.

What happened in the OP's scenario when the radios thought that they had "more room" to speed on that "highway"???

(Please note the OP didn't have to be using Internet i.e. video from a local server or from the ISP's video network - they just had to use the WiFi. )

It's possible you could be "jamming"[1] the band.

I don't mean "jam" in an illegal sense, given I surmise you're using official firmware when the button appears and is usable. I simply mean all devices don't necessarily behave in the same manner, to a user's perceived positive - or negative benefits.

EDIT: You didn't answer:

AlexG · November 16, 2020, 3:16pm

Be sure:

Capture

But in any case of wireless setting this message at kernel log means some program exclutions that must be correctly solved in kernel/driver code.

lleachii · November 18, 2020, 12:49pm

I just realized you have a 40 MHz 2.4 GHz radio set to Channel 4...

I guess you really didn't look at the diagram I posted. I'm starting to understand your issue with speed and forcing 40 MHz, especially if you set the 20 MHz channel to the overlapping channel 4 as well.

I think it's users like yourself that made the need to eliminate that setting in newer hardware - very important.

AlexG · November 18, 2020, 4:27pm

Sorry but some text is on russian:

ergamus · November 18, 2020, 4:52pm

See the lines where your SSID intersects with other AP SSIDs on different channels? Your forced 40MHz channel width is now not only more susceptible to interference from neighboring channels, but you're also causing increased interference to all other APs in the affected spectrum.

Basically, you trade speed for connection stability. If you have weird moments of the day when the speed drops dramatically or you get packet loss, this is a possible reason (wifi firmware issues aside).

In general, force 40MHz mode when that graph only shows you. Yes, when you're the only person with a 2,4GHz Wifi AP in the area. Anything else, enforce 20MHz channel width. Keep in mind most people have their APs set to auto, which means every time there is a reboot or power loss, they will switch to a different channel.

On 5GHz, due to the way the signal propagates through material, the larger spectrum and various modulation techniques, you can get away with larger channel sizes, usually even in a congested RF space.

AlexG · November 18, 2020, 5:43pm

OK, that is quite clear, but please explain this message:

Sun Nov  8 01:36:08 2020 kern.warn kernel: [92948.717760] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 127 (0x7f)

lleachii · November 18, 2020, 11:43pm

From your screenshot, I suggest setting Channel 11 at 20 Mhz. You should see great improvement.