Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

mt7610u: flood of "rx urb failed" and "vendor request * failed" #454

Open
ghost opened this issue Sep 26, 2020 · 5 comments
Open

mt7610u: flood of "rx urb failed" and "vendor request * failed" #454

ghost opened this issue Sep 26, 2020 · 5 comments

Comments

@ghost
Copy link

ghost commented Sep 26, 2020 •
edited by ghost

This issue is not related to openwrt but only concerns the mt76 driver itself.

I'm running kernel 5.8 on a desktop computer, and whenever I plug in a MT7610U dongle, it seems to upset mt76x0u because I get a non-stop flood of errors. The dongle is a generic one without any branding on it, and it seems to work just fine on Windows 10 with both Microsoft's stock drivers and the OEM drivers stored on the SPI flash. It doesn't seem to be a firmware issue, as I've verified /lib/firmware/mediatek/mt7610u.bin is present on my computer. Any ideas on why this is happening?

usb 1-1.3: new high-speed USB device number 8 using xhci_hcd
usb 1-1.3: New USB device found, idVendor=0e8d, idProduct=7610, bcdDevice= 1.00
usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3: Product: WiFi
usb 1-1.3: Manufacturer: MediaTek
usb 1-1.3: SerialNumber: 1.0
usb 1-1.3: reset high-speed USB device number 8 using xhci_hcd
mt76x0u 1-1.3:1.0: ASIC revision: 76100002 MAC revision: 76502000
mt76u_complete_rx: 6284 callbacks suppressed
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
mt76x0u 1-1.3:1.0: rx urb failed: -32
xhci_hcd 0000:09:00.0: WARN Cannot submit Set TR Deq Ptr
xhci_hcd 0000:09:00.0: A Set TR Deq Ptr command is pending.
mt76x0u 1-1.3:1.0: vendor request req:07 off:09a8 failed:-110
mt76x0u 1-1.3:1.0: vendor request req:06 off:09a8 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:42 off:0230 failed:-71
mt76u_complete_rx: 13264 callbacks suppressed
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: rx urb failed: -71
mt76x0u 1-1.3:1.0: vendor request req:42 off:0232 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:42 off:0234 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:42 off:0236 failed:-71
mt76x0u 1-1.3:1.0: firmware upload failed: -71
mt76x0u 1-1.3:1.0: vendor request req:06 off:0800 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:07 off:0080 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:06 off:0080 failed:-71
mt76x0u 1-1.3:1.0: vendor request req:06 off:0080 failed:-71
mt76x0u: probe of 1-1.3:1.0 failed with error -71
usb 1-1.3: USB disconnect, device number 8
@ghost ghost mentioned this issue Oct 2, 2020
Closed
@ce-4
Copy link

ce-4 commented Nov 6, 2020 •
edited

I get a similar/same error with my AVM FRITZ!WLAN AC 430 dongle

on Debian Buster / Linux x220 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux

[ 8175.717163] usb 2-1: new high-speed USB device number 5 using xhci_hcd
[ 8175.866428] usb 2-1: New USB device found, idVendor=057c, idProduct=62ff, bcdDevice= 2.14
[ 8175.866433] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8175.866436] usb 2-1: Product: FRITZ!WLAN USB Stick AC 430
[ 8175.866438] usb 2-1: Manufacturer: AVM Berlin
[ 8175.866439] usb 2-1: SerialNumber: 3431Cxxxxx
[ 8175.867317] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 8175.868370] scsi host6: usb-storage 2-1:1.0
[ 8176.454216] usb 2-1: USB disconnect, device number 5
[ 8176.797144] usb 2-1: new high-speed USB device number 6 using xhci_hcd
[ 8176.971195] usb 2-1: New USB device found, idVendor=057c, idProduct=8502, bcdDevice= 1.00
[ 8176.971200] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8176.971203] usb 2-1: Product: FRITZ!WLAN AC 430
[ 8176.971205] usb 2-1: Manufacturer: AVM
[ 8176.971207] usb 2-1: SerialNumber: 3431Cxxxx
[ 8177.097374] usb 2-1: reset high-speed USB device number 6 using xhci_hcd
[ 8177.256345] mt76x0 2-1:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 8177.257161] mt76x0 2-1:1.0: firmware: direct-loading firmware mediatek/mt7610u.bin
[ 8180.868927] mt76x0 2-1:1.0: Vendor request req:06 off:09a8 failed:-110
[ 8184.100680] mt76x0 2-1:1.0: Vendor request req:42 off:0230 failed:-110
[ 8187.300312] mt76x0 2-1:1.0: Vendor request req:06 off:0800 failed:-110
[ 8190.499981] mt76x0 2-1:1.0: Vendor request req:07 off:0080 failed:-110
[ 8193.699510] mt76x0 2-1:1.0: Vendor request req:06 off:0080 failed:-110
[ 8196.899064] mt76x0 2-1:1.0: Vendor request req:06 off:0080 failed:-110
[ 8196.899128] mt76x0: probe of 2-1:1.0 failed with error -110

same device on OpenWrt 19.07 (Linux 4.14.171 #0 Thu Feb 27 21:05:12 2020 mips GNU/Linux)


# modinfo mt76x0u
module:		/lib/modules/4.14.171/mt76x0u.ko
license:	GPL

[4970032.573364] usbcore: registered new interface driver mt76x0u
[4970032.580468] kmodloader: done loading kernel modules from /etc/modules.d/*
[4970485.762556] usb 1-1.1: USB disconnect, device number 3
[4970486.091732] usb 1-1.1: new high-speed USB device number 4 using ehci-platform
[4970486.431752] usb 1-1.1: reset high-speed USB device number 4 using ehci-platform
[4970486.612927] mt76x0u 1-1.1:1.0: ASIC revision: 76100002 MAC revision: 76502000
[4970486.967062] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.972201] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.977272] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.982362] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.987376] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.992958] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970486.998058] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970487.003160] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970487.008205] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970487.013259] mt76x0u 1-1.1:1.0: rx urb failed: -32
[4970490.241639] mt76x0u 1-1.1:1.0: vendor request req:06 off:09a8 failed:-145
[4970493.451631] mt76x0u 1-1.1:1.0: vendor request req:42 off:0230 failed:-145
[4970496.651565] mt76x0u 1-1.1:1.0: vendor request req:42 off:0232 failed:-145
[4970499.851529] mt76x0u 1-1.1:1.0: vendor request req:42 off:0234 failed:-145
[4970503.051541] mt76x0u 1-1.1:1.0: vendor request req:42 off:0236 failed:-145
[4970506.271518] mt76x0u 1-1.1:1.0: vendor request req:07 off:09a8 failed:-145
[4970509.471438] mt76x0u 1-1.1:1.0: vendor request req:06 off:09a8 failed:-145
[4970512.681432] mt76x0u 1-1.1:1.0: vendor request req:42 off:0230 failed:-145
[4970515.881398] mt76x0u 1-1.1:1.0: vendor request req:42 off:0232 failed:-145
[4970519.081372] mt76x0u 1-1.1:1.0: vendor request req:42 off:0234 failed:-145
[4970522.281368] mt76x0u 1-1.1:1.0: vendor request req:42 off:0236 failed:-145
[4970523.344354] mt76x0u 1-1.1:1.0: firmware upload failed: -145
[4970526.541317] mt76x0u 1-1.1:1.0: vendor request req:06 off:0800 failed:-145
[4970529.741257] mt76x0u 1-1.1:1.0: vendor request req:07 off:0080 failed:-145
[4970532.941230] mt76x0u 1-1.1:1.0: vendor request req:06 off:0080 failed:-145
[4970536.141193] mt76x0u 1-1.1:1.0: vendor request req:06 off:0080 failed:-145
[4970536.534425] mt76x0u: probe of 1-1.1:1.0 failed with error -145

@ce-4
Copy link

ce-4 commented Nov 7, 2020 •
edited

Fixed by applying a modifed patch from here, that adds a vnd_reset=<int> module param:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716301/comments/53

Seems like the same issue (some MT76x0 devices don't like the xxx_vendor_reset) and solution applies.

--- linux-source-4.19/drivers/net/wireless/mediatek/mt76/mt76x0/mcu_orig.c	2020-10-17 10:12:58.000000000 +0200
+++ linux-source-4.19/drivers/net/wireless/mediatek/mt76/mt76x0/mcu.c	2020-11-07 14:39:03.239358622 +0100
@@ -19,6 +19,8 @@
 #include <linux/delay.h>
 #include <linux/usb.h>
 #include <linux/skbuff.h>
+//	patch - add module param
+#include <linux/moduleparam.h>
 
 #include "mt76x0.h"
 #include "dma.h"
@@ -30,6 +32,17 @@
 #define MCU_FW_URB_SIZE			(MCU_FW_URB_MAX_PAYLOAD + 12)
 #define MCU_RESP_URB_SIZE		1024
 
+/*
+	patch - module prm - vnd_reset
+	Some mt76x0 devices are unable to
+	respond after vendor_reset is called,
+	therefore adding this option to turn off
+	reset. Usually the dongle loads OK if
+	reset is bypassed
+*/
+static int vnd_reset = 1;	//	reset by default
+module_param(vnd_reset,int,0660);
+
 static inline int firmware_running(struct mt76x0_dev *dev)
 {
 	return mt76_rr(dev, MT_MCU_COM_REG0) == 1;
@@ -570,7 +583,11 @@
 	mt76_set(dev, MT_USB_DMA_CFG, (MT_USB_DMA_CFG_RX_BULK_EN |
 				       MT_USB_DMA_CFG_TX_BULK_EN) |
 				       FIELD_PREP(MT_USB_DMA_CFG_RX_BULK_AGG_TOUT, 0x20));
-	mt76x0_vendor_reset(dev);
+	//	patch
+	if ( vnd_reset == 1 ){
+		mt76x0_vendor_reset(dev);
+	}
 	msleep(5);
 /*
 	mt76x0_rmw(dev, MT_PBF_CFG, 0, (MT_PBF_CFG_TX0Q_EN |

With patch applied all seems fine, 2.4/5ghz works as expected:

[114890.444851] usb-storage 2-3:1.0: USB Mass Storage device detected
[114890.445228] scsi host5: usb-storage 2-3:1.0
[114891.047692] usb 2-3: USB disconnect, device number 43
[114891.394925] usb 2-3: new high-speed USB device number 44 using xhci_hcd
[114891.572569] usb 2-3: New USB device found, idVendor=057c, idProduct=8502, bcdDevice= 1.00
[114891.572571] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[114891.572572] usb 2-3: Product: FRITZ!WLAN AC 430
[114891.572573] usb 2-3: Manufacturer: AVM
[114891.572574] usb 2-3: SerialNumber: 3431Cxxxxx
[114891.703187] usb 2-3: reset high-speed USB device number 44 using xhci_hcd
[114891.867526] mt76x0 2-3:1.0: ASIC revision: 76100002 MAC revision: 76502000
[114891.868594] mt76x0 2-3:1.0: firmware: direct-loading firmware mediatek/mt7610u.bin
[114892.559066] BBP version f000f200
[114892.577509] mt76x0 2-3:1.0: EEPROM ver:01 fae:07
[114892.577666] mt76x0 2-3:1.0: EEPROM country region 01 (channels 1-13)
[114892.582788] ieee80211 phy15: Selected rate control algorithm 'minstrel_ht'
[114892.602863] mt76x0 2-3:1.0 wlx3431c4d1c925: renamed from wlan0
[114892.652034] IPv6: ADDRCONF(NETDEV_UP): wlxxxx: link is not ready
[114892.679178] IPv6: ADDRCONF(NETDEV_UP): wlxxxx: link is not ready
[114892.707199] IPv6: ADDRCONF(NETDEV_UP): wlxxxx: link is not ready
[114892.798108] IPv6: ADDRCONF(NETDEV_UP): wlxxxx: link is not ready
[114897.379245] IPv6: ADDRCONF(NETDEV_UP): wlxxxx: link is not ready
[114901.855773] wlxxxxx: authenticate with XXXXXXXXXXXX
[114901.879883] wlxxxxx: send auth to XXXXXXXXXXXX (try 1/3)
[114901.881917] wlxxxxx: authenticated
[114901.887105] wlxxxxx: associate with XXXXXXXXXXXX (try 1/3)
[114901.888777] wlxxxxx: RX AssocResp from XXXXXXXXXXXX (capab=0x11 status=0 aid=2)
[114902.143570] wlxxxxx: associated

@ce-4
Copy link

ce-4 commented Nov 9, 2020 •
edited

Update:
recent driver version with out-of-tree compiled mt76x0u (2020-09-23-b22977c2) module on OpenWrt Trunk kernel 5.4.74 (on an GL.inet mt300 v2) does work without patching. somehow the led's don't work, but I don't care about that.
Error on my side (the busybox modprobe doesnt support params afaik and ignored the vnd_reset=1 param), so it appeared to work (but in fact still used my patched default value vnd_reset=0). So bug still happening with trunk from github.com/openwrt/mt76

@ce-4
Copy link

ce-4 commented Nov 12, 2020

Here's what i did on openwrt with trunk driver:

--- openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt76-2020-09-23-b22977c2/mt76x0/usb_mcu.c.orig	2020-11-08 11:57:36.873054619 +0100
+++ openwrt/build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/mt76-2020-09-23-b22977c2/mt76x0/usb_mcu.c	2020-11-09 13:24:40.155768274 +0100
@@ -5,6 +5,7 @@
 #include <linux/kernel.h>
 #include <linux/firmware.h>
 #include <linux/module.h>
+#include <linux/moduleparam.h>
 
 #include "mt76x0.h"
 #include "mcu.h"
@@ -13,6 +14,17 @@
 #define MCU_FW_URB_MAX_PAYLOAD		0x38f8
 #define MCU_FW_URB_SIZE			(MCU_FW_URB_MAX_PAYLOAD + 12)
 
+/*
+	patch - module prm - vnd_reset
+	Some mt76x0 devices are unable to
+	respond after vendor_reset is called,
+	therefore adding this option to turn off
+	reset. Usually the dongle loads OK if
+	reset is bypassed
+*/
+static int vnd_reset = 0;	//no reset by default (better ux in my case for openwrt)
+module_param(vnd_reset,int,0660);
+
 static int
 mt76x0u_upload_firmware(struct mt76x02_dev *dev,
 			const struct mt76x02_fw_header *hdr)
@@ -127,7 +139,12 @@
 	mt76_set(dev, MT_USB_DMA_CFG,
 		 (MT_USB_DMA_CFG_RX_BULK_EN | MT_USB_DMA_CFG_TX_BULK_EN) |
 		 FIELD_PREP(MT_USB_DMA_CFG_RX_BULK_AGG_TOUT, 0x20));
-	mt76x02u_mcu_fw_reset(dev);
+	
+	//	patch
+	if ( vnd_reset == 1 ){
+		mt76x02u_mcu_fw_reset(dev);
+	}
+
 	usleep_range(5000, 6000);
 
 	mt76_wr(dev, MT_FCE_PSE_CTRL, 1);

@schuettecarsten
Copy link

I get lots of "tx urb failed: -71" errors with an Alfa Tuba UAC2 device on OpenWRT 22.03 and snapshot builds. Any news on this issue or plan to apply the patches from here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@schuettecarsten @ce-4