With 23.05.0 on Linksys WRT1900ACv2, I plugged the Comfast CF-953AX on USB 3 port (direct connection, no angled/extension cable), loaded kmod-mt7921u with firmware packages, after a reboot I can see it working. But after doing a few speed test with it, it crashed and WiFi AP is gone.
At the beginning I thought it was router hangs, but ethernet access is good and internet works with cable, following kernel messages showing up. Looking at changelog of 23.05.0-rc3 this is supposed to be fixed, how should I troubleshoot this?
[ 2318.064772] mt7921u 6-1:1.3: Message 00020002 (seq 6) timeout
[ 2318.284722] mt7921u 6-1:1.3: timed out waiting for pending tx
[ 2318.308533] ------------[ cut here ]------------
[ 2318.308941] WARNING: CPU: 6 PID: 9078 at kernel/kthread.c:659 kthread_park+0xac/0xc0
[ 2318.309625] Modules linked in: ath9k ath9k_common rtw89_8852ce rtw89_8852c rtw89_8852be rtw89_8852b rtw89_8852ae rtw89_8852a rtw88_8822cu rtw88_8822ce rtw88_8822c rtw88_8822bu rtw88_8822be rtw88_8822b rtw88_8821cu rtw88_8821ce rtw88_8821c rtw88_8723du rtw88_8723de rtw88_8723d rtl8821ae rtl_pci mt7921u mt7921e mt7921_common btcoexist ath9k_hw ath10k_pci ath10k_core ath wireguard rtw89_pci rtw89_core rtw88_usb rtw88_pci rtw88_core rtlwifi rtl8812au rndis_host pppoe nft_fib_inet nf_flow_table_inet mt792x_usb mt792x_lib mt7915e mt76x2u mt76x2_common mt76x02_usb mt76x02_lib mt76_usb mt76_connac_lib mt76 mac80211 libchacha20poly1305 l2tp_ppp ipt_REJECT chacha_neon cfg80211 cdc_ncm cdc_ether zstd xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_cgroup xt_addrtype xt_TCPMSS xt_REDIRECT xt_MASQUERADE xt_LOG xt_HL xt_DSCP xt_CLASSIFY usbnet usblp ums_usbat
[ 2318.309789] ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_fsm ts_bm sch_cake rfcomm r8169 r8152 pptp pppox ppp_mppe ppp_async poly1305_neon nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_compat nft_chain_nat nf_tables nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_log_syslog nf_flow_table nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda macvlan lzo_rle lzo libcurve25519_generic libchacha iptable_nat iptable_mangle iptable_filter ipt_ECN ipheth ip_tables hidp hci_uart crc_ccitt compat btusb btrtl btmtk btintel br_netfilter bnep bluetooth asn1_decoder fuse
[ 2318.317489] ntfs3 sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact configs pwm_fan gpio_fan cryptodev xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ipmac ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6table_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_NPT ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 pppoatm ppp_generic slhc ip_gre gre ifb dummy l2tp_netlink l2tp_core oid_registry ip_tunnel veth tun xfrm_user xfrm_ipcomp af_key xfrm_algo hfsplus hfs cdrom autofs4 br2684 atm nls_utf8 nls_cp437 vxlan udp_tunnel ip6_udp_tunnel wp512 twofish_generic twofish_common tea serpent_generic khazad cast6_generic cast5_generic cast_common
[ 2318.325166] camellia_generic blowfish_generic blowfish_common anubis ecdh_generic ecc xts crypto_user algif_skcipher algif_rng algif_hash algif_aead af_alg seqiv jitterentropy_rng drbg kpp hmac echainiv deflate cmac authencesn authenc arc4 crypto_acompress uas dwc2 fsl_mph_dr_of ehci_fsl sata_dwc_460ex gpio_button_hotplug xfs vfat fat exfat btrfs xor zstd_decompress zstd_compress zstd_common xor_neon raid6_pq lzo_decompress lzo_compress dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax udc_core tpm encrypted_keys trusted
[ 2318.336769] CPU: 6 PID: 9078 Comm: kworker/u16:0 Not tainted 6.1.59 #0
[ 2318.337341] Hardware name: FriendlyElec NanoPi R6S (DT)
[ 2318.337797] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
[ 2318.338342] pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2318.338951] pc : kthread_park+0xac/0xc0
[ 2318.339289] lr : mt76u_stop_tx+0x200/0x2b0 [mt76_usb]
[ 2318.339739] sp : ffff800014d4bc80
[ 2318.340030] x29: ffff800014d4bc80 x28: 0000000000000000 x27: 00000000fffffef7
[ 2318.340656] x26: ffff000109ca9cb0 x25: ffff00010216d880 x24: 0000000000000100
[ 2318.341282] x23: ffff000109ca20b8 x22: ffff000109ca2098 x21: ffff000109ca4860
[ 2318.341907] x20: ffff00010a1ca500 x19: ffff0001002d5400 x18: 0000000000000000
[ 2318.342532] x17: 000000040044ffff x16: 004000b2b5503510 x15: 0000000000000000
[ 2318.343157] x14: ffff00010024aa00 x13: ffff8001f6171000 x12: 00000000000003c5
[ 2318.343782] x11: 071c71c71c71c71c x10: 0000000000000980 x9 : ffff800014d4bba0
[ 2318.344408] x8 : ffff00010ca841e0 x7 : 0000000000000001 x6 : ffff8000091d6028
[ 2318.345032] x5 : ffff8000091d6028 x4 : 0000000000000000 x3 : 0000000000002800
[ 2318.345657] x2 : 0000000000000000 x1 : 0000000000001fe0 x0 : 0000000000000004
[ 2318.346282] Call trace:
[ 2318.346497] kthread_park+0xac/0xc0
[ 2318.346804] mt76u_stop_tx+0x200/0x2b0 [mt76_usb]
[ 2318.347224] 0xffff80000175354c
[ 2318.347502] mt7921_mac_reset_work+0x84/0x154 [mt7921_common]
[ 2318.348013] process_one_work+0x1d4/0x330
[ 2318.348367] worker_thread+0x70/0x430
[ 2318.348691] kthread+0x108/0x10c
[ 2318.348976] ret_from_fork+0x10/0x20
[ 2318.349291] ---[ end trace 0000000000000000 ]---
ritech
November 9, 2023, 10:47am
2
same problem too
I don't have solution at the moment, and these days I am on a trip so couldn't find enough time to check.
M3L1H
December 3, 2023, 3:31pm
4
I have the same issue with new bought ALFA AWUS036AXML. 5GHZ works fine until I do a speedtest. 6GHZ works but 10mbps connection strength...
timed out waiting for pending tx errors are still alive on kernel 6.6.xx (tested on 6.6.47). Anyone found a solution? The adapter on a x86_64 box works fine but not on ARM (raspberrypi)
I strongly believe that it's the issue with USB bus on Raspberry Pi (especially the Pi4)
For me, it happens on rpi5. That's what I am thinking and it also happens on a rpi3b with its usb 2.0 port.
opened 10:30PM - 06 Sep 22 UTC
This issue is for maintaining a list of problematic issues that need work. This … list will be maintained and updated in this first post by @morrownr . Please add posts to this issue as you have updated information for the existing BUGs in the list or if you have information about a new BUG. Thank you.
Dear Mediatek devs... help is appreciated.
-----
Bug: (2024-04-18) See: https://github.com/morrownr/USB-WiFi/issues/392 . WDS/4addr not supported in AP mode. First reported with Alfa AXML adapter that uses the mt7921au chipset and mt7921u driver). The OP is unable to use WDS/4addr in AP mode.
Status: Open
Info: It was reported that this capability does work with an adapter that uses the mt7612u chipset/driver.
-----
Bug: (2024-03-26) See: https://github.com/morrownr/USB-WiFi/issues/378 Wifi adapter not showing up. First reported with Alfa AXML adapter that uses the mt7921au chipset and mt7921u driver). The adapter is non-functional until using the workaround below.
Status: Open
Workaround: the workaround is to run `modprobe -r btusb` first, then plug in the usb wifi adapter.
More input is needed. Is this a problem with btusb?
-----
Bug: (2023-12-22) Many Linux distros are detecting Bluetooth capability in mt7921au based adapters but none of the adapters on the market have Bluetooth turned on so it won't work. Linux should not be detecting Bluetooth capability when it is actually not available.
Status: Open and ongoing
Here is a link to a location where you can get a copy of the Intel White Paper that explains the details of why USB3 capable WiFi adapters should not have Bluetooth capability turned on:
https://www.usb.org/document-library/usb-30-radio-frequency-interference-impact-24-ghz-wireless-devices
USB3 WiFi adapters should not have Bluetooth turned on as the USB3 will cause interference with Bluetooth. If makers decide they really want Bluetooth capability in an adapter then they need to limit wifi to USB2 capability. All adapters with the mt7921au chipset that I am aware of have Bluetooth turned off so WiFi can operate in USB3 mode. However, there is a bug in that Bluetooth capability is still being detected by Linux distros and the driver/firmware is loading. Systems act like Bluetooth is available but when you try to use the Bluetooth, it won't work. It is not clear to me how this can be fixed but it really does need to be fixed.
This is not a problem with PCIe cards. I have a mt7922 based PCIe card. Wifi and Bluetooth work well together because wifi uses the PCIe bus and not USB. Please understand that issue in this bug is not exclusive to this chipset. This is an issue will all USB WiFi adapters. The adapters that have USB wifi capability and BT capabilities over the years have limited USB to USB2 to avoid the problem of interference.
-----
Bug: (2023-12-07) Active monitor mode breaks driver.
Status: open
Reporter: @ZerBea
Link: https://github.com/openwrt/mt76/issues/839
Problem: Using Active Monitor mode breaks the driver
Driver reports that active monitor mode is possible:
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)
But if hcxdumptool set active monitor mode, it stops working.
If active monitor mode is disabled, everything's fine
0 ERROR(s) during runtime
638 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
83 EPB written to pcapng dumpfile
exit on sigterm
I don't think the problem is related to hcxdumptool, because it can be reproduced with iw, ip link and tshark, too:
$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set type monitor
$ sudo ip link set wlp22s0f0u4i3 up
$ tsahrk -i wlp22s0f0u4i3
22 packets captured
$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set monitor active
$ sudo ip link set wlp22s0f0u4i3 up
$ tshark -i wlp22s0f0u4i3
Capturing on 'wlp22s0f0u4i3'
^C
0 packets captured
Background:
Running active monitor mode, the device ACK incoming frames addressed to the virtual MAC of the device.
This feature is really useful to perform PMKID attacks.
At the moment, active monitor mode is working on:
mt76x0u
mt76x2u
It is not working on:
mt7601u
mt7921u
I see two options:
active monitor mode should be fixed, or
active monitor mode capability should not be reported by the driver
mt7601u
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)
mt7921u
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)
-----
Bug: LED does not function in several of the usb wifi adapters that use the mt7921au chipset.
Status: open, it is unclear what the problem is.
Reported by @morrownr
Confirmed by numerous users.
-----
Bug: AP Mode DFS (5 GHz) support is non-functional
Status: open
Reported by @morrownr
Confirmed by numerous users.
This is really a serious omission in that in many places in the world there are limited non-DFS channels available leading to high levels of congestion.
Dear Mediatek, does your usb chipset competitor support DFS channels in AP Mode? Yes they do. See: out-of-kernel drivers for rtl8812au, rtl8811au, rtl8812bu and rtl8811cu. You need to think about this. Sincerely.
-----
Bug: txpower reading is showing as unusually low as in 3 dBm using `iw`.
Status: open
Reported by several individuals.
This reading must be wrong because actual usage suggests the reading should be much higher.
-----
Bug: (feature request) mt7921u driver does not support 2 interfaces of AP mode on one adapter
Status: open
Reported by @whitslack
mt7921u driver does not support 2 instances of AP mode whereas this was common on some drivers for older adapters.
```
Now:
valid interface combinations:
* #{ managed, P2P-client } <= 2, #{ AP, P2P-GO } <= 1,
total <= 2, #channels <= 2
What we want:
valid interface combinations:
* #{ managed, P2P-client } <= 2, #{ AP, P2P-GO } <= 2,
total <= 2, #channels <= 2
```
-----
Bug: connection is dropped and the only way to correct the situation is to reboot (AP mode)
Status: open
Testing to see if SG helps performance:
scatter-gather test with mt7921au based adapter
Issue: connection drops and the only resolution is to reboot the system.
Raspberry Pi 4B
RasPiOS 2023-05-03
I changed the modulate parameter and rebooted between each test so as to alternate on and off.
iperf3 -c 192.168.1.1 -t 300
scatter-gather off (disable_usb_sg=1)
```
1:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-300.00 sec 19.9 GBytes 569 Mbits/sec 4 sender
[ 5] 0.00-300.01 sec 19.9 GBytes 569 Mbits/sec receiver
2:
[ 5] 0.00-300.00 sec 19.9 GBytes 570 Mbits/sec 5 sender
[ 5] 0.00-300.01 sec 19.9 GBytes 570 Mbits/sec receiver
3:
[ 5] 0.00-300.00 sec 20.0 GBytes 573 Mbits/sec 2 sender
[ 5] 0.00-300.01 sec 20.0 GBytes 573 Mbits/sec receiver
```
scatter-gather on (disable_usb_sg=0)
```
1:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-300.00 sec 19.9 GBytes 570 Mbits/sec 1 sender
[ 5] 0.00-300.01 sec 19.9 GBytes 570 Mbits/sec receiver
2:
[ 5] 0.00-300.00 sec 20.0 GBytes 572 Mbits/sec 48 sender
[ 5] 0.00-300.01 sec 20.0 GBytes 572 Mbits/sec receiver
3.
[ 5] 0.00-300.00 sec 19.9 GBytes 571 Mbits/sec 0 sender
[ 5] 0.00-300.02 sec 19.9 GBytes 571 Mbits/sec receiver
```
Observation: So much for needing to average the results. I was careful
to check that sg was on or off. I have no explanation for how the results
could be so close. I see no evidence that sg is providing any performance
increase.
Previous to this testing session, I have been able to see the issue of
the connection being dropped and only a reboot will connect the
situation. It happened twice a few days ago while testing with sg on.
There is a history of this with mt7612u adapters. I have yet to duplicate
the issue with sg off.
Conclusion: Further testing on different platforms is needed. I will test
x86_64 next. Given the history of sg causing problems such as connections
dropping that can only be corrected with a reboot, it may be better for the
default to be disable_usb_sg=1 with a follow up to determine what the
problem is.
-----
FYI - There is also a discussion here.