List of Bug Reports for the mt7921au chipset / mt7921u driver... #107
Comments
|
Hi @morrownr I cannot reproduce the mess system log in in 6.0-rc3. Can you please show me full log & reproduce steps(if any special)? Thanks, |
|
Hi @deren I will retest on the original system plus two additional systems and report as soon as I can. Regards, Nick |
|
Hi @deren I have numbered the bugs so as to make it easier to reference them. The bug in question is now called Bug 2. I have withdrawn Bug 2. After additional testing on different hardware, it appears this bug may be unique to that system so I need to back up and see if I can isolate the cause. Have you been able to duplicate Bug 1? Regards, Nick |
|
Hi @morrownr I cannot reproduce Bug2, either. The BT function always working properly, even if plug&play or reload driver several times. But the log is weird to me, it looks like missing fw file on filesystem. Can you please check this problem related to any specific device? Regards, |
|
Hi @deren
I have a laptop computer that uses a wifi card based on the mt7921 chipset. Bluetooth works well. However, the subject here is about a usb wifi adapter that uses the mt7921au chipset. I have found no evidence that this adapter supports bluetooth. Is the capability turned off in hardware? I don't know but am trying to find out.
What I posted is not information from a single log. The first section shows the log entries when the most up to date BT firmware is installed. The second section shows the log entries when I delete the BT firmware and reboot. The first section of the log with the firmware installed makes me think the driver is trying to bring BT up but it is unable due to the lack of hardware. Bluetooth support is rare on usb wifi adapters. Could it be that the driver, mt7921u, is making an incorrect assumption that BT hardware is there to use? My mt7921au based usb wifi adapter is showing no sign of support for BT whether the firmware is install or not. This adapter is a Comfast CF-951AX. Regards, Nick |
|
Hi @morrownr
Got it. I did not get the point.
What I have is CF-953AX and can verify BT function working well in the card. Regarding the CF-951AX, there are some information about BT function. ( hope that is real :) )
I guess you consider the three lines means the BT function not working properly, right? The log do not show up in my test environment(ubuntu2004+kernel 6.0-rc5 + CF-953AX) and I think this is related to BT protocol usage in your host system. Can you see BT still alive in your system, such as desktop UI? For example, I can see the device is running after CF-953AX plugged.
Regards, |
morrownr
changed the title
|
Hi @deren
I consider those 3 lines are possibly going to give a hint as to why BT is not working. And it is not working. I wish I was more familiar with BT but I am not so I am having to go slow with my troubleshooting. I also have a little nano BT adapter with a Braodcome chipset. I plugged it in and BT works with it. Mt test distro is Mint 21 (updated to kernel 6.0 rc3) and a short look at the forums tells me Mint is having problems with BT so I am going to suspend my report pending further investigation. I appreciate your help.
Yes. It shows in the gui applet that supports BT. In fact, with the nano adapter plugged in, both show. The difference is that I can pair with other BT devices with the nano adapter but I can't get anything with the Mediatek based adapter. I'll continue trying to determine the problem. Nick |
|
Question: Since you have a Comfast CF-953AX adapter, my question is have you tested AP mode 5 GHz band DFS channel support? I bring this up due to the MANY users that make use of AP mode. Many products also include usb adapters and AP mode is sometimes an important part of the product. I am contacted at times to serve in a consulting roll so I see many use cases that would benefit greatly from this support... and the 5 Realtek drivers I have up here all support this and it works well. There is a gap in capability that needs to be closed and it doesn't seem to be working for me. Thanks, Nick |
|
On RasPi4B with Raspbian and kernel 6.0.0-rc7-v8+ (as well as earlier kernels), CF-953AX in AP mode and the latest September 2022 Firmware, I can relatively consistently reproduce firmware hangs by running a speedtest and After the hang, the AP will recover and the following (starting from 4440.067187) is printed in the kernel log. |
|
maybe some issues again with usb scatter gather |
|
@ayyyuki1 possible. Based on above call trace, mt7921u driver does call a mt76_usb function. I'll try reproducing the issue with |
My opinion is that I would like to see either the default setting for scatter-gather be changed or simple clean the code out of mt76. I have seen the problems that it causes with mt7612u based adapters and I have taken the time to do extensive tests to see if it increases speed in any worthwhile level. My conclusion is that I cannot see any increases in speed. I say dump it from the code. |
|
I think the problem with scatter gather was suspected to be a bug in the USB hardware of a Raspberry Pi. |
|
With |
|
Can the firmware of the VIA chip be upgraded? |
|
Yes. |
I'm looking to move this bug report up into message 1 with the other bugs. You mentioned the distro and kernel but did not mention:
|
|
I also want to know if is using an extension cable.
And is it using a powered USB hub.
I had to use a powered USB hub for the keyboard/mouse of my hdmi switch.
Oct. 8, 2022 00:55:53 Nick ***@***.***>:
On RasPi4B with Raspbian and kernel 6.0.0-rc7-v8+[raspberrypi/linux@3fb5ca8] (as well as earlier kernels), CF-953AX in AP mode and the latest September 2022 Firmware, I can relatively consistently reproduce firmware hangs by running a speedtest and *apt upgrade* in parallel on the SC7180 Snapdragon 7c. (Having other devices connected and other traffic patterns sometimes also causes the hang).
@leezu[https://github.com/leezu]
I'm looking to move this bug report up into message 1 with the other bugs. You mentioned the distro and kernel but did not mention:
* > band/channel ?
* > hostapd ? and hostapd.conf
* > WPA3 ?
* > wpa_supplicant version ?
* > 32 bit ?
* > hostapd.log showing anything ?
…
—
Reply to this email directly, view it on GitHub[#107 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AACKGALRAHP3GR4JLFJPJELWCD5FPANCNFSM6AAAAAAQGHSOXA].
You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AACKGAKA3YFOTWPOFOZ3XBLWCD5FPA5CNFSM6AAAAAAQGHSOXCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSL2STJM.gif]
|
band/channel: 36
It uses this extension lead https://smile.amazon.com/gp/product/B082HQXRZ1/ as without extension lead, the CF-953AX covers up the LAN port. |
|
I added your firmware hanging issue as Bug 6. Please check it to see if I did a good job. Also, I have been running AP mode 5 GHz over the few days with my RasPi4B. It appears I am seeing the same problem. Every few hours I will lose internet access. It can and usually does recover but it can take a long time. I shut down scatter/gather this morning to see if it helps. We will see. Can I get you to test 2.4 GHz AP mode? Look at Bug 2. I am reporting that 2.4 GHz AP mode is not working. Would like confirmation.
FYI: I think you need 2.10 for WPA3 support. I have a guide to do the upgrade if you want a copy. Nick |
|
Regarding bug 6., if I build a vanilla 6.4.rc linux kernel for my raspberry pi 4, I cannot reproduce the issue anymore. |
|
Hi @gifter77 Copy all. Will update. |
|
It seems Mediatek have a new firmware release for MT7921. I've seen this message in linux-wireless today: But the firmware is not yet available here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek. I hope the new firmware fixes some of the issues. |
|
After about 3 weeks without any issues, a new kind of error occurs: The kernel is alive but the wifi is dead. A normal |
|
What is your distro and kernel version? |
It's a Raspberry Pi 4B box with 64-bit official Raspberry Pi OS. The system is up-to-date with Linux kernel 6.1.73. $ uname -a
Linux ty 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux |
|
I have a Pi4B with the 2-23-05-12 RaspPiOS. The kernel is the same as yours. I'm not seeing what you are seeing but mine is running in AP mode. What is the output of: $ ethtool -i wlan0 Replace wlan0 with your interface name. I'm looking for the firmware version you are using. Something is different between our systems. |
Mine is also running in AP mode with the hostapd-WiFi6.conf you provided.
$ ethtool -i wlan1
driver: mt7921u
version: 6.1.0-rpi8-rpi-v8
firmware-version: ____010000-20231109190959
expansion-rom-version:
bus-info: 2-1:1.3
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no |
|
Here is what I am looking at. My firmware is the original firmware that came with the 2023-12-05 release on the RasPiOS 64 bit. I had not upgraded yet but I'm not seeing any issues. You might try backing off to the same version I am using to see what happens.
That makes me thing there is a problem with usb. Have you tried the other usb3 port? |
I was seeing those crashes every day or few until I switched to a simpler (read: worse) HostAPd configuration at @morrownr's suggestion. I then ran my access point for 3½ months straight with not a single crash or hang and only rebooted it once in that time to upgrade the kernel. Moreover, with the simpler config my Wi-Fi network was more reliably visible: whereas previously I often would need to scan several times on both my phone and my laptop to find my network and connect to it, after I dumbed down the config, then both devices consistently found the network on their first scan. This leads me to suspect that there is something amiss with the transmit multi-queuing in the driver and/or firmware for this chipset since it doesn't even appear to send out the beacon frames entirely on pace when I use my preferred config. Since 17 March 2024, I have switched to a slightly less crippled HostAPd configuration that now enables 802.11n+WMM and 256-bit ciphers and in theory 802.11ax, although my AP will never actually enable AX mode since I have many legacy client devices in my network. I have had zero hangs, crashes, or slowdowns with this config in the first week of testing it. My hope is that, by titration and process of elimination, I can eventually find exactly the HostAPd option that these drivers/firmware/chipset don't like, and then we will be able to send an actionable bug report to Mediatek. |
|
Hi, here is mine, i have some wmm params set and some for he. others are on their default and could be left away like beacon interval and such interface=wlx00c0cab38118 logger_syslog=1 ctrl_interface=/var/run/hostapd ssid=iot22 beacon_int=100 macaddr_acl=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_be_aifs=3 wmm_ac_vi_aifs=2 wmm_ac_vo_aifs=2 skip_inactivity_poll=1 ht_capab=[LDPC][HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935] ieee80211ax=1 he_su_beamformee=1 wpa=2 |
|
Wanted to share my own experience with the The AP appears to hang once this happens; it stops responding to pings or SSH connection attempts from the upstream network, the display output freezes completely, and the device doesn't seem to respond to keyboard inputs. However, a bash session via serial connection (using the OPi5+'s debug UART pins) seems stable and responsive through the AP "crash", and I can actually revive the AP through a simple I'm happy to help in any way I can. If there's more logging that would be useful, let me know. If anybody has any ideas for changes to make, also happy to modify/compile/test kernels/software/firmware/whatever. Hardware: Recently "upgraded" (sigh) my AP with an ALFA AWUS036AXML, which I'm using in conjunction with an Orange Pi 5+. I've been running the AP with ALFA unit attached via one of the OPi5+'s USB 3.0 Type-A ports, which interfaces with the RK3588 SOC through a hub chip (GL3523). However, I can recreate the same issue when the ALFA unit is connected through the OPi5+'s Type-C port, which, according to Orange Pi's schematics, is routed directly to one of the SOC's two USB3.1 interfaces. It's worth noting that the Type-C port has a separate, dedicated PMIC, which may be evidence against this being a power supply issue, at least on the host side. Software: running a bookworm release of Debian, kernel 6.1.43, with relevant mediatek drivers built as kernel modules. Some relevant outputs are below. neofetch: hostapd version: ethtool: systool for mt76_usb module: dmesg |
Almost certainly not a host power supply issue, as it was happening to me on an Intel Atom-based mini-ITX system with a 60W DC-DC PSU attached to a 12V 5A AC adapter that pulls under 15W at the wall while powering the system (so, lots of headroom).
Except in the very early days (before I found and fixed the packet headroom bug in the driver), I have never actually seen the |
Just got an interface hang on my "slightly less crippled HostAPd configuration." It happened while I was downloading a large file over Wi-Fi. I was able to bring down the interface with |
|
this is the same topic that im experiencing .... the hostapd config doesnt really matter |
|
question about USB3 mode and AMD RZ608 / mt7921u : in lsusb i see my adapter running in USB-2 mode , but isnt it supposed to be USB-3 ? is it possible to switch the speed ? |
I've never seen that chipset used in a usb adapter. The mt7921u driver automatically sets USB3 if all conditions are met for USB3 to be used. Same thing with the mt7612u driver. I've never seen them make a mistake. Not saying that it is not possible, just that I've never seen it. |
|
okay , im running on X86-64 Jasper Lake hardware with the thing plugged into a USB3 port on latest longterm kernel 6.6.23 and it runs in USB2 mode (480M). its the ALFA usb adapter ..... i have never seen it in USB3 mode root@odroid-h3:~# lsusb -t -v |
|
ok sorry when using the proper cable , then its USB3: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 10000M |
Been there, done that. USB3 is just not going to work with a USB2 cable or hub in the mix. |
|
Hi all, With my AWUS036AXML I had 1 common issue which is I believe I solved, and another 1 is a kind of solved. I have raspberry pi before 4 now 5, bookworm aarch64. Kernel was original but I tend to update it to latest one so it really does not matter. I use dhcpd+dnsmasq+hostapd setup. I took hostapd from morrownr's config but I changed to run with wlan0 directly, not bridge mode.
I solved these issues with adding
|
@MEL1H: Very interesting find, but I wonder how your system is able to change the power management mode. When I try it with I cannot use It's shocking to me that HostAPd does not disable power saving on an AP interface by default. APs are not supposed to enter any 802.11 power saving modes, I'm pretty sure. Maybe HostAPd assumes that the driver will ignore any power-saving mode settings when operating in AP mode, but the mt7921u driver actually does still apply power-saving modes to the chipset even when running in AP mode. That would certainly explain some things, although ideally power saving should at least work in AP mode, even if performance is lousy. What follows is pure conjecture on my part. Maybe the reason I am seeing no hangs when I disable WMM is that then the chipset transmits only on its primary queue, which does correctly toggle power-saving modes as necessary to service the queue. Perhaps the additional transmit queues utilized by WMM are not correctly tied into power management, such that there can arise a rare edge case wherein the primary queue is empty, the PHY is in power-saving mode, and yet a WMM queue is not empty. The non-empty WMM queue cannot be serviced while in power-saving mode, leading to a hang and an eventual transmit timeout. On a completely separate tack, there is another somewhat recent patch pending merge into a kernel release that has me hopeful: wifi: mt76: mt792xu: enable dmashdl support, whose commit message reads: "dmashdl(DMA scheduler) was disable and may cause packets corruption without propoer resource handling. Enable this to control resources between usb-bus/pse/hardware-ac-queue." The mentions of "packets corruption" and "hardware [802.11]ac queue" seem very relevant to our issue at hand. I have not attempted to merge this patch into my kernel myself. |
|
@whitslack it is actually a coincidence. At the very begining, I have tried many commands related with iw to make power saving off however all failed. Then I decided to use rpi onboard wifi at same time with AWUS036AXML, when I prepared the interfaces for onboard wifi I just gave a shot for awus also then somehow it worked.
I hope that patch will solve the other issue permanently. Thanks for informing. |
Was the interface up when you ran the command? Some commands only work if the interface is down. To check: $ ip a To take the interface down: I did a quick test on the easiest thing to test which is my wifi card with a mt7922 chip that uses the mt7921e driver and it worked... turned power off. The interface was down when I tested. I can take a mt7921au interface down on another system and test if you want.
I saw that as well. |
|
i tried the dma patch you mentioned on top of the LTS kernel 6.6.28 , it didnt solve the "tx urb " errors or the others .... i switched power management off while the adapter was turned off and at least this worked. I tried the 3-4 most promising patches from master tree of mt76 , no success ) |
|
Today my rpi stuck again. when I checked the journal I found that message |
|
@whitslack |
@morrownr: That was indeed the problem. In related news, I discovered that even my extremely crippled config, although much more stable than WMM-enabled configs, still can exhibit the hang. I am now testing that same config with power saving turned off. Fingers crossed that this is the magic bullet! Update: Nope. Even with power saving disabled and using the extremely crippled (pre-802.11n) config, it is still possible for the driver to wedge itself into a corner and die. A simple |
and others
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: #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: #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 btusbfirst, 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: openwrt/mt76#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.
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)
scatter-gather on (disable_usb_sg=0)
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.
The text was updated successfully, but these errors were encountered: