MT7612U support

[pellerb]

Hi, I bought EDUP EP-AC1605 WiFi adapters and these are equipped with MediaTek MT7612U controllers. I would like to use them with OpenWRT-based routers and USB3 connection (to have an additional WiFi device). It seems that this driver doesn't support MT7612U controller yet. The router detects a new USB device connection when I plug in, but it doesn't recognize this adapter even if kmod-mt76x2 driver package is installed. Could you please add MT7612U support in parallel with MT7612E? It would be also very nice to distribute compiled version of the package too. Thanks, Balázs

[LorenzoBianconi]

@LorenzoBianconi https://github.com/LorenzoBianconi : When bootup , rx urb mismatch problem bother me days. if I reboot the router without unplugging the dongle , sometimes(about 90%) the problem happens,and sometimes is just fine

when the issuse happens , the log realated it is

[ 8.603478] usb 1-1: reset high-speed USB device number 2 using orion-ehci [ 8.804468] mt76x2u 1-1:1.0: ASIC revision: 76120044 [ 8.836158] mt76x2u 1-1:1.0: ROM patch build: 20140408060640a [ 8.910710] ------------[ cut here ]------------ [ 8.915372] WARNING: CPU: 0 PID: 0 at /home/myname/LEDE/build_dir/target-arm_xscale_musl_eabi/linux-kirkwood/mt76-mt76x2u-758f64a1/usb.c:345 mt76_usb_complete_rx+0x90/0x100 [mt76] [ 8.931345] rx urb mismatch [ 8.931349] Modules linked in: mt76x2u(+) mt76x2_common mt76 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 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 nfdefrag ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack iptable_mangle iptable_filter ip_tables crc_itu_t crc_ccitt compat xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netpor t ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap _ipmac [ 9.006136] ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables tun xhci_plat_hcd xhci_pci xhci_hcd ehci_platform [ 9.024149] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.37 #0 [ 9.030004] Hardware name: Marvell Kirkwood (Flattened Device Tree) [ 9.036291] Backtrace: [ 9.038765] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 9.046367] r7:bf3a30f0 r6:00000000 r5:bf3a4f30 r4:c0801d90 [ 9.052064] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 9.059328] [] (dump_stack) from [] (warn+0xe0/0x10c) [ 9.066320] [] (warn) from [] (warn_slowpath_fmt+0x40/0x48) [ 9.073837] r9:00000040 r8:ffffe000 r7:60000093 r6:c6969b90 r5:c69f0080 r4:bf3a4f20 [ 9.081623] [] (warn_slowpath_fmt) from [] (mt76_usb_complete_rx+0x90/0x100 [mt76]) [ 9.091054] r3:bf3a610c r2:bf3a4f20 [ 9.094636] r4:c6969460 [ 9.097196] [] (mt76_usb_complete_rx [mt76]) from [] (usb_hcd_giveback_urb+0xac/0x104) [ 9.107067] r7:c6a558e0 r6:00000000 r5:60000013 r4:c69f0080 [ 9.112757] [] (__usb_hcd_giveback_urb) from [] (usb_giveback_urb_bh+0x90/0xd4) [ 9.121838] r7:c6a558e0 r6:00000000 r5:c0801df8 r4:c6a558dc [ 9.127526] [] (usb_giveback_urb_bh) from [] (tasklet_action+0x84/0xcc) [ 9.135911] r7:00000100 r6:00000000 r5:c0808fa0 r4:00000000 [ 9.141598] [] (tasklet_action) from [] (do_softirq+0x118/0x2fc) [ 9.149550] r7:00000100 r6:00000018 r5:00000006 r4:c084d138 [ 9.155236] [] (do_softirq) from [] (irq_exit+0xa4/0xf8) [ 9.162492] r10:00000000 r9:c0801f00 r8:c7809400 r7:00000001 r6:00000000 r5:c0847824 [ 9.170351] r4:00000000 [ 9.172903] [] (irq_exit) from [] (handle_domain_irq+0x8c/0xa8) [ 9.180771] [] (handle_domain_irq) from [] (orion_handle_irq+0x74/0xa0) [ 9.189333] r9:c0801f00 r8:00000001 r7:c087a87c r6:c781a01c r5:00080000 r4:00000013 [ 9.197112] [] (orion_handle_irq) from [] (__irq_svc+0x68/0x84) [ 9.204797] Exception stack(0xc0801f00 to 0xc0801f48) [ 9.209869] 1f00: 00000000 00000000 00000000 60000013 00000000 ffffe000 c0803088 c083ebf0 [ 9.218082] 1f20: c080c2fa c0669220 00000000 c0801f5c c0801f50 c0801f50 c0102f60 c05a4464 [ 9.226292] 1f40: 60000013 ffffffff [ 9.229794] r10:00000000 r9:c0800000 r8:c080c2fa r7:c0801f34 r6:ffffffff r5:60000013 [ 9.237653] r4:c05a4464 [ 9.240208] [] (default_idle_call) from [] (do_idle+0x84/0x144) [ 9.247895] [] (do_idle) from [] (cpu_startup_entry+0x14/0x18) [ 9.255500] r10:00735474 r9:c0736a20 r8:c7ffca60 r7:00000000 r6:c0803020 r5:ffffffff [ 9.263360] r4:c080a90c r3:40000013 [ 9.266948] [] (cpu_startup_entry) from [] (rest_init+0x74/0x94) [ 9.274729] [] (rest_init) from [] (start_kernel+0x3a4/0x428) [ 9.282240] r5:ffffffff r4:c084caa0 [ 9.285828] [] (start_kernel) from [<00008048>] (0x8048) [ 9.292031] ---[ end trace 0e412fa249281f90 ]--- [ 9.354707] mt76x2u 1-1:1.0: Firmware Version: 0.0.00 [ 9.359789] mt76x2u 1-1:1.0: Build: 1 [ 9.363534] mt76x2u 1-1:1.0: Build Time: 201406241830__ [ 10.299574] usbcore: registered new interface driver mt76x2u ............................

[ 23.451087] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 25.043805] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 26.623541] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 29.743608] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 31.303541] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out ............................

even I increase the value of MT_VEND_REQ_MAX_RETRY and MT_VEND_REQ_TOUT_MS in usb.c can not solve it. In my humble opinion, is it something related to the USB init ? How about init the USB device more than one time to avoid this issuse?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-388257649, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCTZKvbOgjvBtoLnI_-Bs3V_ITt1Vks5txRXugaJpZM4RS8Yv .

@cyangy could you please double check if this patch helps to fix the 'rx urb mismatch' issue (not tested since I am not able to trigger the issue for the moment)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2u_init.c b/drivers/net/wireless/mediatek/mt76/mt76x2u_init.c index f253648844e0..e38893256f95 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x2u_init.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x2u_init.c @@ -276,11 +276,11 @@ int mt76x2u_register_device(struct mt76x2_dev *dev) if (err < 0) return err;

• err = mt76x2u_alloc_queues(dev);

• err = mt76x2u_init_hardware(dev); if (err < 0) goto fail;

• err = mt76x2u_init_hardware(dev);

• err = mt76x2u_alloc_queues(dev); if (err < 0) goto fail;

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[LorenzoBianconi]

@LorenzoBianconi https://github.com/LorenzoBianconi:

1- Are you using the kernel source from my github repo or have you backported just the mt76 driver? Huge ping delay seems related to this issue

Compiled the mt76 driver only for my kernel, taken from your mt76/tree/mt76x2u. Kernel is Fedora's 4.15.15-200.fc26.x86_64.

Have you backported mac80211 stack? Could you please try to compile the kernel from my github tree since I run a pretty long test (few hours) and the connection was stable (~200M TCP)

2- If I understood correctly, if the dongle is plugged in your pc at device bootstrap it will properly work just once, if you reboot the pc without unplugging the dongle it will not be loaded properly. Correct?

I've done some more testing. It seems to only happen if I power off the machine, wait a while and then power it up, then the first time the module is inserted with the dongle already plugged in the firmware upload hangs with the mentioned errors. If I just reboot having previously used the device, even if I reboot from Windows, it doesn't hang, at least it didn't just now. I may also mention that the device works without issues from Windows non-stop, so it doesn't seem to be a hardware failure, and USB support seems stable for other devices on my machine on both Windows and Linux.

Could you please try the patch I posted to @cyangy?

3- Before rmmod mt76x2u mt76x2_common, have you stopped wpa_supplicant? (I agree it should not crash even if wpa_supplicant is still running)

Well, wpa_supplicant was running. I did some more testing and disconnected, and if wpa_supplicant is running, even if it (supposedly) isn't doing anything, I get that crash when doing rmmod. But if I stop wpa_supplicant, I don't get the crash.

Are there any printk I could add anywhere, or any debug mode I could activate to provide more info? Any other suggestions or anything, please feel free to ask.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-388217553, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCabLekZZtvFFm0yZHGMT2S9mPgNiks5txM-ugaJpZM4RS8Yv .

I will try to reproduce it but it is not a big issue if the fw is running when you try to re-insert the module (it is the WARN_ON() in usb.c:345)

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[cyangy]

@LorenzoBianconi : I'm trying your patch now . By the way, after hours work, I found that the issuse only happen if function mt76_usb_rx_tasklet(unsigned long data) been called while the for (i = 0; i < q->ndesc; i++) cycle of function mt76_usb_alloc_rx(struct mt76_dev *dev) not finish yet. for example,this is what the output of rx urb mismatch issuse happen after I add debug message in usb.c

[   10.444421] mt76x2u 1-1:1.0: ASIC revision: 76120044
[   10.465555] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=0 err=0
[   10.472853] mt76x2u 1-1:1.0: mt76_usb_rx_tasklet(unsigned long data) been called err=0 
[   10.482571] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=1 err=0
[   10.489920] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=2 err=0
                          ...............................................

But in this situation ,for example

[   10.444421] mt76x2u 1-1:1.0: ASIC revision: 76120044
[   10.465555] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=0 err=0
[   10.482571] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=1 err=0
                           ...............................................
[   10.489920] mt76x2u 1-1:1.0: mt76_usb_alloc_rx(struct mt76_dev *dev) been called  i=15 err=0  // for (i = 0; i < q->ndesc; i++)   cycle  in  mt76_usb_alloc_rx(struct mt76_dev *dev)  finished
[   11.521452] mt76x2u 1-1:1.0: mt76_usb_rx_tasklet(unsigned long data) been called err=0 
                          ...............................................

all will be fine.

So, my opinion is : make sure the function mt76_usb_rx_tasklet not been called before the function mt76_usb_alloc_rx finish it's job.

[LorenzoBianconi]

@cyangy thx a lot for the bug report I will work on it

[cyangy]

@LorenzoBianconi : I use the patch of mt76x2u_init.c you privide , after at least 50 times reboot (with power cut off and not cut off ), the rx urb mismatch issuse disappear,but these issuse happen sometime

[   13.603496] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out
[   27.619708] mt76x2u: probe of 1-1:1.0 failed with error -110

or sometimes

[   10.083453] mt76x2u 1-1:1.0: firmware upload timed out
[   25.118571] mt76x2u 1-1:1.0: MAC RX failed to stop
[   25.129494] mt76x2u: probe of 1-1:1.0 failed with error -5

or sometimes

[    8.983391] mt76x2u 1-1:1.0: Build Time: 201406241830____
[   10.083453] mt76x2u 1-1:1.0: firmware upload timed out
[   25.118571] mt76x2u 1-1:1.0: MAC RX failed to stop
[   25.129494] mt76x2u: probe of 1-1:1.0 failed with error -5

or sometimes

[    8.844699] mt76x2u 1-1:1.0: ROM patch build: 20140408060640a
[   12.093501] mt76x2u 1-1:1.0: vendor request req:07 off:09a8 failed:-110
[   15.293486] mt76x2u 1-1:1.0: vendor request req:06 off:09a8 failed:-110

Only 20% of these testes work well . So the patch may not a solution. As I mentioned before, maybe the problem is just because of the function mt76_usb_rx_tasklet been called before the function mt76_usb_alloc_rx finish it's job . Is this the key point ?

[cyangy]

@araujorm : This is my patch to track function excute in usb.c ,you may have a try to figure out what you issue relate to.

diff -Nur a/usb.c b/usb.c
--- a/usb.c 2018-05-10 23:09:20.000000000 +0800
+++ b/usb.c 2018-05-11 19:54:18.011881920 +0800
@@ -357,6 +357,7 @@
    struct mt76_usb_buf *buf;
    int err;

+   static int mt76_usb_rx_tasklet_counter = 0;
    rcu_read_lock();

    while (true) {
@@ -371,6 +372,7 @@
        err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX,
                      buf, GFP_ATOMIC,
                      mt76_usb_complete_rx, dev);
+          dev_err(dev->dev, "mt76_usb_rx_tasklet(unsigned long data) called,err=%d mt76_usb_rx_tasklet_counter=%d\n",err,mt76_usb_rx_tasklet_counter); 
        if (err < 0)
            break;
    }
@@ -400,6 +402,7 @@
        err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX,
                      &q->entry[i].ubuf, GFP_KERNEL,
                      mt76_usb_complete_rx, dev);
+       dev_err(dev->dev, "mt76_usb_alloc_rx(struct mt76_dev *dev) called  i=%d err=%d\n",i, err);
        if (err < 0)
            return err;
    }
@@ -416,6 +419,7 @@
        err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX,
                      &q->entry[i].ubuf, GFP_KERNEL,
                      mt76_usb_complete_rx, dev);
+       dev_err(dev->dev, "mt76_usb_submit_rx_buffers(struct mt76_dev *dev) called  i=%d err=%d\n",i, err); //this functions seem never been called
        if (err < 0)
            return err;
    }

[LorenzoBianconi]

@araujorm : This is my patch to track function excute in usb.c ,you may have a try to figure out what you issue relate to.

diff -Nur a/usb.c b/usb.c --- a/usb.c 2018-05-10 23:09:20.000000000 +0800 +++ b/usb.c 2018-05-11 19:54:18.011881920 +0800 @@ -357,6 +357,7 @@ struct mt76_usb_buf *buf; int err;

• static int mt76_usb_rx_tasklet_counter = 0; rcu_read_lock();

  while (true) { @@ -371,6 +372,7 @@ err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX, buf, GFP_ATOMIC, mt76_usb_complete_rx, dev);

• dev_err(dev->dev, "mt76_usb_rx_tasklet(unsigned long data) called,err=%d mt76_usb_rx_tasklet_counter=%d\n",err,mt76_usb_rx_tasklet_counter); if (err < 0) break; } @@ -400,6 +402,7 @@ err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX, &q->entry[i].ubuf, GFP_KERNEL, mt76_usb_complete_rx, dev);
• dev_err(dev->dev, "mt76_usb_alloc_rx(struct mt76_dev *dev) called i=%d err=%d\n",i, err); if (err < 0) return err; } @@ -416,6 +419,7 @@ err = mt76_usb_submit_buf(dev, USB_DIR_IN, MT_EP_IN_PKT_RX, &q->entry[i].ubuf, GFP_KERNEL, mt76_usb_complete_rx, dev);
• dev_err(dev->dev, "mt76_usb_submit_rx_buffers(struct mt76_dev *dev) called i=%d err=%d\n",i, err); //this functions seem never been called if (err < 0) return err; }

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

@cyangy Could you please test the following patch that make usb urb submission atomic please.

https://pastebin.com/mgQiYCCa

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[cyangy]

@LorenzoBianconi : I'll do it right now.

[cyangy]

@LorenzoBianconi : :+1: Problem solved. After apply the patch you posted to mt76x2u, just the patch, no other code modfied. Now after 30 times reboot (with power cut off and not cut off ), pluge and unpluge ,every thing work well except when rmmod mt76x2u when the USB pluged-in

[   78.995889] usbcore: deregistering interface driver mt76x2u
[   79.001560] wlan0: deauthenticating from 14:75:8a:44:46:e2 by local choice (Reason: 3=DEAUTH_LEAVING)
[   79.075222] ------------[ cut here ]------------
[   79.079893] WARNING: CPU: 0 PID: 3417 at /home/myname/LEDE/build_dir/target-arm_xscale_musl_eabi/linux-kirkwood/mt76-mt76x2u-758f64a1/usb.c:345 mt76_usb_complete_rx+0x90/0x100 [mt76]
[   79.096125] rx urb mismatch
[   79.096129] Modules linked in: rtl8192cu rtl8192c_common rtl_usb pppoe ppp_async rtlwifi pppox ppp_generic nf_conntrack_ipv6 mwl8k mt76x2u(-) mt76x2_common mt76 mac80211 iptable_nat ipt_REJECT ipt_MASt
[   79.169793]  ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nm
[   79.197676] CPU: 0 PID: 3417 Comm: sh Not tainted 4.14.37 #0
[   79.203356] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[   79.209643] Backtrace: 
[   79.212108] [<c0105e1c>] (dump_backtrace) from [<c0106104>] (show_stack+0x18/0x1c)
[   79.219711]  r7:bf3a30ec r6:00000000 r5:bf3a4f30 r4:c61f7e40
[   79.225407] [<c01060ec>] (show_stack) from [<c05886c0>] (dump_stack+0x20/0x28)
[   79.232671] [<c05886a0>] (dump_stack) from [<c01103d8>] (__warn+0xe0/0x10c)
[   79.239664] [<c01102f8>] (__warn) from [<c0110444>] (warn_slowpath_fmt+0x40/0x48)
[   79.247182]  r9:00000040 r8:ffffe000 r7:60000093 r6:c6ce9b90 r5:c6998700 r4:bf3a4f20
[   79.254967] [<c0110408>] (warn_slowpath_fmt) from [<bf3a30ec>] (mt76_usb_complete_rx+0x90/0x100 [mt76])
[   79.264399]  r3:bf3a610c r2:bf3a4f20
[   79.267990]  r4:c6ce9460
[   79.270548] [<bf3a305c>] (mt76_usb_complete_rx [mt76]) from [<c0428f5c>] (__usb_hcd_giveback_urb+0xac/0x104)
[   79.280420]  r7:c6a558e0 r6:00000000 r5:a0000013 r4:c6998700
[   79.286109] [<c0428eb0>] (__usb_hcd_giveback_urb) from [<c0429044>] (usb_giveback_urb_bh+0x90/0xd4)
[   79.295192]  r7:c6a558e0 r6:00000000 r5:c61f7ea8 r4:c6a558dc
[   79.300880] [<c0428fb4>] (usb_giveback_urb_bh) from [<c01141b8>] (tasklet_action+0x84/0xcc)
[   79.309265]  r7:00000100 r6:00000000 r5:c0808fa0 r4:00000000
[   79.314951] [<c0114134>] (tasklet_action) from [<c01014d0>] (__do_softirq+0x118/0x2fc)
[   79.322903]  r7:00000100 r6:00000018 r5:00000006 r4:c084d138
[   79.328588] [<c01013b8>] (__do_softirq) from [<c0113d98>] (irq_exit+0xa4/0xf8)
[   79.335846]  r10:00000000 r9:c61f7fb0 r8:c7809400 r7:00000001 r6:00000000 r5:c0847824
[   79.343705]  r4:00000000
[   79.346257] [<c0113cf4>] (irq_exit) from [<c013f548>] (__handle_domain_irq+0x8c/0xa8)
[   79.354123] [<c013f4bc>] (__handle_domain_irq) from [<c010138c>] (orion_handle_irq+0x74/0xa0)
[   79.362687]  r9:c61f7fb0 r8:00000001 r7:c087a87c r6:c781a01c r5:00080000 r4:00000013
[   79.370466] [<c0101318>] (orion_handle_irq) from [<c0106f78>] (__irq_usr+0x58/0x80)
[   79.378150] Exception stack(0xc61f7fb0 to 0xc61f7ff8)
[   79.383220] 7fa0:                                     0000000a b6faf76a 0000006f 0006e803
[   79.391436] 7fc0: 0000000a 0166250e 0166250c 0008332c 00000004 00000000 00000000 bea8f654
[   79.399648] 7fe0: 00000300 bea8f5e8 000351cc 000351f8 20000010 ffffffff
[   79.406295]  r10:00000000 r9:00000000 r8:00053977 r7:0005397f r6:ffffffff r5:20000010
[   79.414154]  r4:000351f8
[   79.416691] ---[ end trace b4be17775b2a01bd ]---

but I don't think it's a problem(because if insmod mt76x2u , it works again). If someone wants to remove the device, just unpluge it .

[LorenzoBianconi]

@cyangy do you mean this patch, right? If you confirm I will push it. I will look to the rmmod issue during the we

Thx for testing

[cyangy]

@LorenzoBianconi : Yes this patch. Good night.

[LorenzoBianconi]

@cyangy ok, cool, I will push it. Btw I will stabilize STA mode and push it upstream first, then I will switch to AP mode (I am not 100% of hw capabilities). Thx a lot for testing it

[araujorm]

Hi.

First of all, I can also confirm that with the latest patch tested by cyangy I'm no longer having problems inserting the module after a cold boot, which is great. Moving on.

I was yet unable to compile your full kernel, but still planning to try it later when possible.

Meanwhile, after looking at the issue you referred, I've been doing some checks and trying to do some debugging and I think I might have found a clue to the culprit for the "pauses".

Take a look at the functions mt76_txq_schedule_list and mt76_txq_send_burst in tx.c. I placed some printks over there near both the return -EBUSY parts and noticed that everytime I have those pauses, it's hitting there.

I then commented both of those checks, the ones like this, there's one on each of those functions:

                if (test_bit(MT76_SCANNING, &dev->state) ||
                    test_bit(MT76_RESET, &dev->state))
                        return -EBUSY;

and then I no longer get those huge ping time values. I however don't always have brilliant results on speed test, and the ping values seem irregular oscillating between 1ms and 50 ms, when before they were between 1ms and 2ms (when not suffering from the "pauses", because if so I get 10000ms to 15000ms as I said before). This means something that must be taken care of isn't being, but at least I don't get those mood-killing "pauses".

I've searched for MT76_RESET on the code and I only get other references of that being set or checked in mt7603_mac.c, which isn't used for mt76x2u. So, obviously, something is missing and not being handled for mt76x2u (and I believe it's the same case for mt76x2e). A mystery is: what is setting it? Is there any clashing somewhere?

I then tried to comment the MT76_RESET parts on tx.c, leaving the MT76_SCANNING checks only, and vice-versa, but the huge 15 seconds ping values still occur like before. The "pauses" only stop occurring when I remove both of the -EBUSY returns.

Any clue on what is missing to handle those states correctly? And what about the MT76_RESET, is that really the same state on mt76x2[eu] that what you have on mt7603?

If there's anything you want me to try, please feel free to ask. Meanwhile I'll continue to test usage and stability without both of those -EBUSY returns.

[LorenzoBianconi]

@LorenzoBianconi : Yes this patch. Good night.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

@cyangy: module unload WARN should be fixed in a343cb68676b7172d4f3d0b0b1cb78cc8dc70ac1 . Could you please give it a whirl?

For subsequent bugs I guess it is more efficient to open separated issues on GH

Regards, Lorenzo

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[LorenzoBianconi]

Hi.

First of all, I can also confirm that with the latest patch tested by cyangy I'm no longer having problems inserting the module after a cold boot, which is great. Moving on.

I was yet unable to compile your full kernel, but still planning to try it later when possible.

What is the kernel version you are running? mt76 tx side is based on mac80211 queue management so first you need to be sure you are running an updated mac80211 stack. To confirm this I have never faced that issue running mt76x2u on my laptop or on openwrt. @cyangy what about you?

Meanwhile, after looking at the issue you referred, I've been doing some checks and trying to do some debugging and I think I might have found a clue to the culprit for the "pauses".

Take a look at the functions mt76_txq_schedule_list and mt76_txq_send_burst in tx.c. I placed some printks over there near both the return -EBUSY parts and noticed that everytime I have those pauses, it's hitting there.

I then commented both of those checks, the ones like this, there's one on each of those functions:

            if (test_bit(MT76_SCANNING, &dev->state) ||
                test_bit(MT76_RESET, &dev->state))
                    return -EBUSY;

and then I no longer get those huge ping time values. I however don't always have brilliant results on speed test, and the ping values seem irregular oscillating between 1ms and 50 ms, when before they were between 1ms and 2ms (when not suffering from the "pauses", because if so I get 10000ms to 15000ms as I said before). This means something that must be taken care of isn't being, but at least I don't get those mood-killing "pauses".

I've searched for MT76_RESET on the code and I only get other references of that being set or checked in mt7603_mac.c, which isn't used for mt76x2u. So, obviously, something is missing and not being handled for mt76x2u (and I believe it's the same case for mt76x2e). A mystery is: what is setting it? Is there any clashing somewhere?

I then tried to comment the MT76_RESET parts on tx.c, leaving the MT76_SCANNING checks only, and vice-versa, but the huge 15 seconds ping values still occur like before. The "pauses" only stop occurring when I remove both of the -EBUSY returns.

Any clue on what is missing to handle those states correctly? And what about the MT76_RESET, is that really the same state on mt76x2[eu] that what you have on mt7603?

If there's anything you want me to try, please feel free to ask. Meanwhile I'll continue to test usage and stability without both of those -EBUSY returns.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-388504185, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCXqgKTg0iu48cu1DUSoz0Mbv8sLKks5txhWHgaJpZM4RS8Yv .

I guess first we need to be on the same page running the same sw. I guess it will pretty easy to use my GH tree, just copy fedora default config and fix new stuff typing 'make oldconfig'. I am currently using wireless-drivers-next tree on my feodra27 btw. Thx a lot for testing

Regards, Lorenzo

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[cyangy]

@LorenzoBianconi : It's my pleasure. I'm doing other things on windows now. I will test it as soon as I finish my job. Let's move to open a separated issues . It seems can not open an issue on this branch

[cyangy]

@LorenzoBianconi : rmmod mt76x2u tested. No warning now,But it seems there is an issuse I didn't notice before on OpenWRT ,that is once the net speed near about 1MB/s ,then the speed decrease rapidly，and the error message

[  119.873753] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out
[  121.423969] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out
[  124.034309] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out
[  125.584520] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out
[  140.631405] mt76x2u 1-1:1.0: MAC RX failed to stop
                    ............................................

appears, then the network not work any more.

##################The issuse on Ubuntu is################### I test it on ubuntu 16.04LTS which kernel is 4.13.0-41 ,the error message error: mt76x2u_mcu_wait_resp timed out not appear ,but the network is not stable ,the ping is:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=3.57 ms
             .........................
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=6.41 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=18137 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=17121 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=16097 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=15075 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=14052 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=13029 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=12005 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=10982 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=9959 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=8935 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=7912 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=6888 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=1.09 ms
             .........................
64 bytes from 192.168.0.1: icmp_seq=122 ttl=64 time=1.69 ms
64 bytes from 192.168.0.1: icmp_seq=123 ttl=64 time=18430 ms
64 bytes from 192.168.0.1: icmp_seq=124 ttl=64 time=17414 ms
64 bytes from 192.168.0.1: icmp_seq=125 ttl=64 time=16390 ms
64 bytes from 192.168.0.1: icmp_seq=126 ttl=64 time=15367 ms
64 bytes from 192.168.0.1: icmp_seq=127 ttl=64 time=14344 ms
64 bytes from 192.168.0.1: icmp_seq=128 ttl=64 time=13320 ms
64 bytes from 192.168.0.1: icmp_seq=129 ttl=64 time=12293 ms
64 bytes from 192.168.0.1: icmp_seq=130 ttl=64 time=11273 ms
64 bytes from 192.168.0.1: icmp_seq=131 ttl=64 time=10250 ms
64 bytes from 192.168.0.1: icmp_seq=132 ttl=64 time=9226 ms
64 bytes from 192.168.0.1: icmp_seq=133 ttl=64 time=8203 ms
64 bytes from 192.168.0.1: icmp_seq=134 ttl=64 time=7179 ms
64 bytes from 192.168.0.1: icmp_seq=135 ttl=64 time=0.740 ms
             .........................
64 bytes from 192.168.0.1: icmp_seq=233 ttl=64 time=2.62 ms
64 bytes from 192.168.0.1: icmp_seq=234 ttl=64 time=0.617 ms
64 bytes from 192.168.0.1: icmp_seq=235 ttl=64 time=18693 ms
64 bytes from 192.168.0.1: icmp_seq=236 ttl=64 time=17671 ms
64 bytes from 192.168.0.1: icmp_seq=237 ttl=64 time=16648 ms
64 bytes from 192.168.0.1: icmp_seq=238 ttl=64 time=15628 ms
64 bytes from 192.168.0.1: icmp_seq=239 ttl=64 time=14605 ms
64 bytes from 192.168.0.1: icmp_seq=240 ttl=64 time=13582 ms
64 bytes from 192.168.0.1: icmp_seq=241 ttl=64 time=12559 ms
64 bytes from 192.168.0.1: icmp_seq=242 ttl=64 time=11536 ms
64 bytes from 192.168.0.1: icmp_seq=243 ttl=64 time=10513 ms
64 bytes from 192.168.0.1: icmp_seq=244 ttl=64 time=9490 ms
64 bytes from 192.168.0.1: icmp_seq=245 ttl=64 time=8467 ms
64 bytes from 192.168.0.1: icmp_seq=246 ttl=64 time=7444 ms
64 bytes from 192.168.0.1: icmp_seq=247 ttl=64 time=30.0 ms
64 bytes from 192.168.0.1: icmp_seq=248 ttl=64 time=1.04 ms
             .........................

net speed is

this appearance periodically (about 20 seconds Low and about 105 seconds High). I'm sure that the router 192.168.0.1 work well . The problem is the same as @araujorm faced.

[araujorm]

@cyangy

Yes, that's exactly what happens to me. For the record, I since also tried with the latest Fedora 26 kernel - 4.16.7-100.fc26.x86_64 - which is the same version as fedora 27, and the problem persists.

I'm compiling the full kernel that @LorenzoBianconi suggested and I'll post the results as soon as I'm able to.

Meanwhile, if you want to have a more or less usable driver on older kernels, you can try to comment the lines I said above in tx.c (there are 2 instances of those) and try again. Better than nothing, I guess, at least until we ensure that the problem is something missing on the mac80211 on those older kernels and check if there is a possible solution for them.

[LorenzoBianconi]

@LorenzoBianconi https://github.com/LorenzoBianconi : rmmod mt76x2u tested. No warning now,But it seems there is an issuse I didn't notice before on OpenWRT ,that is once the net speed near about 1MB/s ,then the speed decrease rapidly，and the error message

[ 119.873753] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 121.423969] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 124.034309] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 125.584520] mt76x2u 1-1:1.0: error: mt76x2u_mcu_wait_resp timed out [ 140.631405] mt76x2u 1-1:1.0: MAC RX failed to stop ............................................

appears, then the network not work any more.

##################The issuse on Ubuntu is################### I test it on ubuntu 16.04LTS which kernel is 4.13.0-41 ,the error message error: mt76x2u_mcu_wait_resp timed out not appear ,but the network is not stable ,the ping is:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=3.57 ms ......................... 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=6.41 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=18137 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=17121 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=16097 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=15075 ms 64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=14052 ms 64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=13029 ms 64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=12005 ms 64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=10982 ms 64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=9959 ms 64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=8935 ms 64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=7912 ms 64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=6888 ms 64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=1.09 ms ......................... 64 bytes from 192.168.0.1: icmp_seq=122 ttl=64 time=1.69 ms 64 bytes from 192.168.0.1: icmp_seq=123 ttl=64 time=18430 ms 64 bytes from 192.168.0.1: icmp_seq=124 ttl=64 time=17414 ms 64 bytes from 192.168.0.1: icmp_seq=125 ttl=64 time=16390 ms 64 bytes from 192.168.0.1: icmp_seq=126 ttl=64 time=15367 ms 64 bytes from 192.168.0.1: icmp_seq=127 ttl=64 time=14344 ms 64 bytes from 192.168.0.1: icmp_seq=128 ttl=64 time=13320 ms 64 bytes from 192.168.0.1: icmp_seq=129 ttl=64 time=12293 ms 64 bytes from 192.168.0.1: icmp_seq=130 ttl=64 time=11273 ms 64 bytes from 192.168.0.1: icmp_seq=131 ttl=64 time=10250 ms 64 bytes from 192.168.0.1: icmp_seq=132 ttl=64 time=9226 ms 64 bytes from 192.168.0.1: icmp_seq=133 ttl=64 time=8203 ms 64 bytes from 192.168.0.1: icmp_seq=134 ttl=64 time=7179 ms 64 bytes from 192.168.0.1: icmp_seq=135 ttl=64 time=0.740 ms ......................... 64 bytes from 192.168.0.1: icmp_seq=233 ttl=64 time=2.62 ms 64 bytes from 192.168.0.1: icmp_seq=234 ttl=64 time=0.617 ms 64 bytes from 192.168.0.1: icmp_seq=235 ttl=64 time=18693 ms 64 bytes from 192.168.0.1: icmp_seq=236 ttl=64 time=17671 ms 64 bytes from 192.168.0.1: icmp_seq=237 ttl=64 time=16648 ms 64 bytes from 192.168.0.1: icmp_seq=238 ttl=64 time=15628 ms 64 bytes from 192.168.0.1: icmp_seq=239 ttl=64 time=14605 ms 64 bytes from 192.168.0.1: icmp_seq=240 ttl=64 time=13582 ms 64 bytes from 192.168.0.1: icmp_seq=241 ttl=64 time=12559 ms 64 bytes from 192.168.0.1: icmp_seq=242 ttl=64 time=11536 ms 64 bytes from 192.168.0.1: icmp_seq=243 ttl=64 time=10513 ms 64 bytes from 192.168.0.1: icmp_seq=244 ttl=64 time=9490 ms 64 bytes from 192.168.0.1: icmp_seq=245 ttl=64 time=8467 ms 64 bytes from 192.168.0.1: icmp_seq=246 ttl=64 time=7444 ms 64 bytes from 192.168.0.1: icmp_seq=247 ttl=64 time=30.0 ms 64 bytes from 192.168.0.1: icmp_seq=248 ttl=64 time=1.04 ms .........................

net speed is

https://camo.githubusercontent.com/5108c6dc06b6346a602f186fe428b42442f1b954/68747470733a2f2f696d6167652e6962622e636f2f636a55624c642f6e6574776f726b2e706e67 this appearance periodically (about 20 seconds Low and about 105 seconds High). I'm sure that the router 192.168.0.1 work well . The problem is the same as @araujorm https://github.com/araujorm faced.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-388561332, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCSs7XBf4v9NiIpgIDh49sEeUhaU9ks5txvqKgaJpZM4RS8Yv .

@cyangy: Does this issue happen connecting the dongle to an openwrt router or to a pc? Does this happen after rmmod/isnmod the module or during normal operation?

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[araujorm]

Hello.

Even with the 4.17.0-rc1+ kernel from the mt76x2u tree the problem persists, in fact it was almost immediately that I got the bug to trigger (the speedtest couldn't even start). Tried again after a while, it triggered as usual. Screenshot:

BTW, the way I trigger this is very simple. I'm not running anything else, and the wi-fi connection is configured using NetworkManager, more specifically the applet that comes with MATE. Then I leave a ping running in a terminal window, and in a firefox browser start a test to speedtest dot net. 9/10 times the bug is triggered and I get at least a ping time of 15 seconds like the one in the image.

Anything else you want me to try, please feel free to ask.

[cyangy]

@LorenzoBianconi : Sorry for my bad English. Before this line ##################The issuse on Ubuntu is################### I talk about the dongle plugged in the OpenWRT and connect to a TP-LINK route (192.168.0.1) which I'm sure it work well. After that line I talk about the dongle plugged in a PC(Ubuntu16.04LTS,kernel 4.13) and connect to the same router. It's too late, so tired,I have to go to sleep now. @araujorm : I'll try your method tomorrow.

[araujorm]

@LorenzoBianconi

The problem with the huge ping value and the device "pausing" is definitely triggered on the routines I mentioned, but unlike what I said earlier, the MT76_RESET flag is never set. I confirmed this by placing some more specific dev_err calls (as a matter of fact, it's only set in mt7603 code so that's something that probably should be optimized later on the common routines, but that's not the main issue right now).

So, every time it happens, it's because the flag MT76_SCANNING is set, and takes a long while to be unset. I can confirm it can be triggered almost every time I do a iwlist <wlan-device> scanning command, and I think it's my NetworkManager applet that causes that to happen on a regular basis (probably you are not using NetworkManager, or you are using a different applet or no applet at all, so could that be why you aren't having the problem)?

That MT76_SCANNING flag is set in mt76x2u_sw_scan function, and cleared in mt76x2u_sw_scan_complete function, both in mt76x2u_main.c file.

I went to compare similar routines with the other mt76 based devices and noticed some differences with the respective counterparts _sw_scan and _sw_scan_complete in mt7603_main.c and mt76x2_main.c. I'm not sure if what's there is related to AP code or not, and thus not related to this issue, so I wouldn't really bet the solution is there, but I'm asking someone who surely understands these drivers better (you) to take a look :)

On thing is certain, the symptoms are very similar to what happens in mt76x2 (not USB), as described in https://github.com/openwrt/mt76/issues/152. If the origin of the problem is the same, I'd say the problem triggering may depend on what each one has running on their router or laptop (in this case, something that triggers scannings on a regular basis like MATE's NetworkManager applet), and (just a hunch) the amount of networks in the zones or the amount of networks nearby with the same SSID (which is my case, I have a few). I also wouldn't rule out it triggering more often in certain cases being related to the amount of CPUs each device has, because if you have a openwrt router with only one cheap MIPS CPU (like I do, with a mt76x2 device where I never had these symptoms), you don't have as much concurrency and that may come into play if there is a race condition somewhere. In my case with the mt76x2u, my PC is a desktop computer with 4 cores and 8 threads, and the problem happens almost all the time.

If you still can't trigger the bug, please tell me if you need me to test anything. Thanks in advance.

[cyangy]

@LorenzoBianconi @araujorm : I commit the code

        if (test_bit(MT76_SCANNING, &dev->state) ||
            test_bit(MT76_RESET, &dev->state))
            return -EBUSY;

in function mt76_txq_schedule_list and mt76_txq_send_burst of tx.c then teseted on Ubuntu like before.

Plug in the dongle, download something from internet, after a while (about 60 seconds) , then the error message appears

[56838.152233] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[56909.630109] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[56911.230230] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[56912.862110] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[56914.462112] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[56916.382117] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[56917.982115] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

Once the message mt76x2u_mcu_wait_resp timed out appears, the network can not use any more,So I have to unpluge the dongle and pluge in again, downloading ... and then

[57015.576178] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[57140.539807] mt76x2u 3-5:1.0: MAC RX failed to stop
[57142.146146] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57143.742178] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57145.342133] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57146.942213] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57148.574140] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57150.174124] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57151.806119] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

unpluge the dongle and pluge in again, downloading ... and then

[57222.128377] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[57554.530730] mt76x2u 3-5:1.0: MAC RX failed to stop
[57556.130198] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57557.726193] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57559.326137] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[57560.926154] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

unpluge the dongle and pluge in again, downloading ... and then

[57859.956728] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[58084.762682] mt76x2u 3-5:1.0: MAC RX failed to stop
[58086.366165] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58087.966155] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58089.570168] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58091.170134] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58092.798159] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58094.398159] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[58096.066138] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

If not commit the code

        if (test_bit(MT76_SCANNING, &dev->state) ||
            test_bit(MT76_RESET, &dev->state))
            return -EBUSY;

in function mt76_txq_schedule_list and mt76_txq_send_burst of tx.c then . Like I posted before, there seems no error message but just the network changes between available(105 seconds) and unavailable(20 seconds),but after a long run (about 900 seconds),the error message appears.

[58697.131476] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[59193.556027] mt76x2u 3-5:1.0: MAC RX failed to stop
[59195.166201] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[59196.766278] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

then network not usable any more,So I have to unpluge the dongle and pluge in again, downloading ... and then

[59394.460463] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[59721.514610] mt76x2u 3-5:1.0: MAC RX failed to stop
[59723.102314] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[59724.702325] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

repeat

[60137.216782] IPv6: ADDRCONF(NETDEV_CHANGE): wlxa00460111870: link becomes ready
[60219.534810] mt76x2u 3-5:1.0: MAC RX failed to stop
[60221.118250] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out
[60222.718225] mt76x2u 3-5:1.0: error: mt76x2u_mcu_wait_resp timed out

Once the message mt76x2u_mcu_wait_resp timed out appears, the network can not use any more

[LorenzoBianconi]

@LorenzoBianconi https://github.com/LorenzoBianconi

The problem with the huge ping value and the device "pausing" is definitely triggered on the routines I mentioned, but unlike what I said earlier, the MT76_RESET flag is never set. I confirmed this by placing some more specific dev_err calls (as a matter of fact, it's only set in mt7603 code so that's something that probably should be optimized later on the common routines, but that's not the main issue right now).

So, every time it happens, it's because the flag MT76_SCANNING is set, and takes a long while to be unset. I can confirm it can be triggered almost every time I do a iwlist scanning command, and I think it's my NetworkManager applet that causes that to happen on a regular basis (probably you are not using NetworkManager, or you are using a different applet or no applet at all, so could that be why you aren't having the problem)?

That MT76_SCANNING flag is set in mt76x2u_sw_scan function, and cleared in mt76x2u_sw_scan_complete function, both in mt76x2u_main.c file.

mt76x2u_sw_scan routines are run at beginning/end of frequency scanning. Are you able to trigger that issue just at channel saturation or even just 'pinging' the AP or browsing the web? Does that issue occur while downloading or uploading traffic? What about channel quality/RSSI? I have not carried out any test with low RSSI, so if it is feasible for you I would ask to double check if the issue occurs even if you are pretty close to the AP. If it is feasible, could you please perform the following test?

1- measure the channel bandwidth using tool like iperf 2- send background downlink TCP traffic using iperf (AP -> STA) 3- ping the AP 4- repeat step 2 with uplink TCP traffic (STA -> AP)

Regards, Lorenzo

I went to compare similar routines with the other mt76 based devices and

noticed some differences with the respective counterparts _sw_scan and _sw_scan_complete in mt7603_main.c and mt76x2_main.c. I'm not sure if what's there is related to AP code or not, and thus not related to this issue, so I wouldn't really bet the solution is there, but I'm asking someone who surely understands these drivers better (you) to take a look :)

On thing is certain, the symptoms are very similar to what happens in mt76x2 (not USB), as described in #152 https://github.com/openwrt/mt76/issues/152. If the origin of the problem is the same, I'd say the problem triggering may depend on what each one has running on their router or laptop (in this case, something that triggers scannings on a regular basis like MATE's NetworkManager applet), and (just a hunch) the amount of networks in the zones or the amount of networks nearby with the same SSID (which is my case, I have a few). I also wouldn't rule out it triggering more often in certain cases being related to the amount of CPUs each device has, because if you have a openwrt router with only one cheap MIPS CPU (like I do, with a mt76x2 device where I never had these symptoms), you don't have as much concurrency and that may come into play if there is a race condition somewhere. In my case with the mt76x2u, my PC is a desktop computer with 4 cores and 8 threads, and the problem happens almost all the time.

If you still can't trigger the bug, please tell me if you need me to test anything. Thanks in advance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-388588588, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCXRMB55z4vhtK-6nC32wjv_tTJU4ks5tx2aJgaJpZM4RS8Yv .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[LorenzoBianconi]

@cyangy @araujorm could you please try latest version, should improve stability under load Regards, Lorenzo

[araujorm]

Hello.

First, I'm sorry but I still wasn't able to test the adapter closer to the router, it's a desktop pc. Signal level isn't anything awesome, as you can see in the image below, but on windows it achieves stable 100 mbps speeds (at least, at the moment I don't have any means to test for more).

Will try to move it closer as soon as I can.

Meanwhile I tried the latest commit, but unfortunately I didn't notice differences. Let's hope it helps with the problem @cyangy is having or at least help him collecting new information.

I did some more tests, this time with iperf3, by leaving a server running on a raspberry pi connected via ethernet (so 100 Mbps max, like my Internet speed). It's directly connected to the router AP.

As far as I can tell, the problems occur either with download (iperf3 -R -c) and upload (iperf3 -c), seems to me there's no difference in that regard.

With no changes from your latest source I still get those "pauses" for about 15 seconds, maybe once every minute, which makes it unusable:

Also when it happens, iwlist scanning hangs, and at least once it returned with this error:

If I comment out the return -EBUSY lines in tx.c as before, I no longer get the "pauses" and the adapter is usable, but maximum speed, as well as average speed in general, is slower in iperf3 (with speedtest I also had that impression, but here seems to me more obvious):

I still think that it's something related with scanning, that isn't being handled properly on the driver's side. Why it doesn't happen to you, I don't know, but please notice that this problem is only in 5 GHz - I don't get the pauses in 2.4 GHz connections. Could that be your case? Or maybe the router/AP beacon interval or other related settings? (unfortunately it's an ISP router that is partially locked so I can't see or change advanced settings from it, but the truth is that with the adapter connected in windows it works well)

Anything else, please let me know and feel free to ask.

Thanks and best regards.

EDIT - important correction - "pauses" also happen with 2.4 GHz, I guess I had made most tests on 5 GHz only, but now I've just confirmed it makes no difference.

[cyangy]

@LorenzoBianconi @araujorm : I do not have time to test the driver this week because I'm doing other works which very important.I will test it as soon as I finish my jobs.

[LorenzoBianconi]

@araujorm I guess the scanning is due to NetworkManager that if the signal is low (by default < -80dbm) performs a frequency scanning every 30s. You can disable this behavior defining the bssid of the AP you want to connect:

• through NM applet or
• nmcli connection modify $con 802-11-wireless.bssid $bssid

[araujorm]

@LorenzoBianconi Setting the BSSID made that NM no longer performs frequency scanning as you said, and the truth is that I no longer get "pauses" like before. I was able to run iperf3 during at least 30 minutes without pauses (until I was convinced, then cancelled it). But the problem still exists, because if I do a iwlist wlanX scanning (at least if done as root), I still get the pauses, so for now unless when testing new commits I'll stick to commenting the return -EBUSY lines in tx.c

About the RSSI: well, the value is strangely low when comparing to windows. As you can see in my last screenshot, I have 56/70 which is 80%. But in windows (performing netsh wlan show networks mode=bssid) I get constant 96%. The truth is that I can get constante 92 Mbps with iperf3 on windows, while on Linux I get the results I showed yesterday - a few spikes of 90 Mbps, but generally slower speeds like 60 or 70 Mbps. So I don't think on Linux I'm getting the real signal strength value. It would be interesting if others compared these values with the netsh command on windows and iwconfig on Linux too. Do you want me to open another issue about this? If so, on your repo or on this one?

Thank you and best regards.

[LorenzoBianconi]

@LorenzoBianconi Setting the BSSID made that NM no longer performs frequency scanning as you said, and the truth is that I no longer get "pauses" like before. I was able to run iperf3 during at least 30 minutes without pauses (until I was convinced, then canceled it). But the problem still exists, because if I do a iwlist wlanX scanning (at least if done as root), I still get the pauses, so for now unless when testing new commits I'll stick to commenting the return -EBUSY lines in tx.c

@araujorm: if you run 'iwlist wlanX scan' you perform a scan so it is expected the tx is stopped during this process.

About the RSSI: well, the value is strangely low when comparing to windows. As you can see in my last screenshot, I have 56/70 which is 80%. But in windows (performing netsh wlan show networks mode=bssid) I get constant 96%. The trif uth is that I can get constante 92 Mbps with iperf3 on windows, while on Linux I get the results I showed yesterday - a few spikes of 90 Mbps, but generally slower speeds like 60 or 70 Mbps. So I don't think on Linux I'm getting the real signal strength value. It would be interesting if others compared these values with the netsh command on windows and iwconfig on Linux too. Do you want me to open another issue about this? If so, on your repo or on this one?

Yes thx, it will be helpful

Regards, Lorenzo

Thank you and best regards.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[araujorm]

@LorenzoBianconi Regarding the pauses during the scan, it doesn't happen with other wifi cards, where one can trigger scans at will and the network continues to transmit (rx and tx) continuously even with the scan in progress. I'm not saying the throughput will be the same or not, but I never seen any card that stops everything else while scanning (and remember that removing the returns -EBUSY in tx.c works, at least partially, so that one can scan for SSIDs and still have traffic passing). Do you mean it is expected because it is a known issue? Or am I misunderstanding?

EDIT: Just to clarify that I'm not trying to discuss if it is expected to internally pause or not for some microseconds, what I mean is that pausing completely tx and rx for 15 seconds isn't something I've ever seen on other wifi cards, hope you understand.

Regarding the lower RSSI and throughput when compared to Windows, I've opened a new issue: https://github.com/LorenzoBianconi/mt76/issues/1

Thanks and best regards.

[LorenzoBianconi]

@araujorm I ported Felix patchset to fix ping delay issue. Could you please test latest version? Thx

[araujorm]

@LorenzoBianconi It works, thank you very much.

I still have lower speeds once in a while, specially when scanning (I notice when I leave a TCP iperf running, start a iw dev scan on another terminal), but it also happens on mt76x2 and my cheap router where I've been testing openwrt, so it's not mt76x2u specific. It however doesn't happen with a UDP iperf3 (speed is stable at good values, with iperf3 -u -b 0 my_rasperry_pi_server even when scanning) so it seems something related to Nagle algorithm kicking in on TCP connections. It would be useful if more people tested because it may be something specific to my surroundings. Can you or @nbd168 reproduce that? (I don't know if Felix is following this thread, if you think it would be more useful to mention that on another one please tell me)

Anyway, besides speed going down here and then, this driver is much more stable and useful than every other I've tested. Thanks again to you and @nbd168.

[magnets110]

Does the MT7612U support monitor mode?

[LorenzoBianconi]

On Fri, 21 Sep 2018, 01:23 magnets110, notifications@github.com wrote:

Does the MT7612U support monitor mode?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-423365418, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCc_pT1ENQUJOr4uiKnGI6zo_3_6yks5udCODgaJpZM4RS8Yv .

Yes, it does

[nbd168]

MT7612U support is included in the latest version used in OpenWrt master.

[chrismonks]

Did you ever get AP mode to work on 7612U?

[sinancetinkaya]

I have EDUP EP-AC1605 too and the Access Point in LuCi/wireless is not working (or I couldn't get it to work)

Is AP mode supported? If yes, is there any guide how to enable it? here is /etc/config/wireless

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'platform/1e1c0000.xhci/usb2/2-1/2-1.4/2-1.4:1.0'
        option htmode 'VHT80'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option ssid 'HotSpot_5ghz'
        option key '**********'
        option encryption 'psk2+ccmp'

root@OpenWrt:~# iw phy0 info
Wiphy phy0
        max # scan SSIDs: 4
        max scan IEs length: 2243 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports RSN-IBSS.
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * CCMP-128 (00-0f-ac:4)
                * CCMP-256 (00-0f-ac:10)
                * GCMP-128 (00-0f-ac:8)
                * GCMP-256 (00-0f-ac:9)
                * CMAC (00-0f-ac:6)
                * CMAC-256 (00-0f-ac:13)
                * GMAC-128 (00-0f-ac:11)
                * GMAC-256 (00-0f-ac:12)
        Available Antennas: TX 0x3 RX 0x3
        Supported interface modes:
                 * managed
                 * monitor
        Band 1:
                Capabilities: 0x1ff
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-15
                Bitrates (non-HT):
                        * 1.0 Mbps (short preamble supported)
                        * 2.0 Mbps (short preamble supported)
                        * 5.5 Mbps (short preamble supported)
                        * 11.0 Mbps (short preamble supported)
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (20.0 dBm)
                        * 2472 MHz [13] (20.0 dBm)
                        * 2484 MHz [14] (disabled)
        Band 2:
                Capabilities: 0x1ff
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-15
                VHT Capabilities (0x018001b0):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)
                        TX STBC
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Bitrates (non-HT):
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 5180 MHz [36] (23.0 dBm)
                        * 5200 MHz [40] (23.0 dBm)
                        * 5220 MHz [44] (23.0 dBm)
                        * 5240 MHz [48] (23.0 dBm)
                        * 5260 MHz [52] (20.0 dBm) (radar detection)
                        * 5280 MHz [56] (20.0 dBm) (radar detection)
                        * 5300 MHz [60] (20.0 dBm) (radar detection)
                        * 5320 MHz [64] (20.0 dBm) (radar detection)
                        * 5500 MHz [100] (27.0 dBm) (radar detection)
                        * 5520 MHz [104] (27.0 dBm) (radar detection)
                        * 5540 MHz [108] (27.0 dBm) (radar detection)
                        * 5560 MHz [112] (27.0 dBm) (radar detection)
                        * 5580 MHz [116] (27.0 dBm) (radar detection)
                        * 5600 MHz [120] (27.0 dBm) (radar detection)
                        * 5620 MHz [124] (27.0 dBm) (radar detection)
                        * 5640 MHz [128] (27.0 dBm) (radar detection)
                        * 5660 MHz [132] (27.0 dBm) (radar detection)
                        * 5680 MHz [136] (27.0 dBm) (radar detection)
                        * 5700 MHz [140] (27.0 dBm) (radar detection)
                        * 5745 MHz [149] (disabled)
                        * 5765 MHz [153] (disabled)
                        * 5785 MHz [157] (disabled)
                        * 5805 MHz [161] (disabled)
                        * 5825 MHz [165] (disabled)
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * start_ap
                 * new_station
                 * new_mpath
                 * set_mesh_config
                 * set_bss
                 * authenticate
                 * associate
                 * deauthenticate
                 * disassociate
                 * join_ibss
                 * join_mesh
                 * set_tx_bitrate_mask
                 * frame
                 * frame_wait_cancel
                 * set_wiphy_netns
                 * set_channel
                 * set_wds_peer
                 * probe_client
                 * set_noack_map
                 * register_beacons
                 * start_p2p_device
                 * set_mcast_rate
                 * testmode
                 * connect
                 * disconnect
                 * set_qos_map
                 * set_multicast_to_unicast
        Supported TX frame types:
                 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        Supported RX frame types:
                 * IBSS: 0x40 0xb0 0xc0 0xd0
                 * managed: 0x40 0xd0
                 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * mesh point: 0xb0 0xc0 0xd0
                 * P2P-client: 0x40 0xd0
                 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * P2P-device: 0x40 0xd0
        software interface modes (can always be added):
                 * monitor
        interface combinations are not supported
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Device supports TX status socket option.
        Device supports HT-IBSS.
        Device supports SAE with AUTHENTICATE command
        Device supports low priority scan.
        Device supports scan flush.
        Device supports AP scan.
        Device supports per-vif TX power setting
        Driver supports full state transitions for AP/GO clients
        Driver supports a userspace MPM
        Device supports active monitor (which will ACK incoming frames)
        Device supports configuring vdev MAC-addr on create.

[LorenzoBianconi]

AP mode is not supported by mt76x2u driver (or mt76x0u) since usb does not provide tbtt interrupts

On Fri, Dec 28, 2018 at 9:17 PM chrismonks notifications@github.com wrote:

Did you ever get AP mode to work on 7612U?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-450420688, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCasgZlKJE_9ZqGPTDSp7G9t45O6wks5u9nxKgaJpZM4RS8Yv .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[sinancetinkaya]

AP mode is not supported by mt76x2u driver (or mt76x0u) since usb does not provide tbtt interrupts … On Fri, Dec 28, 2018 at 9:17 PM chrismonks @.***> wrote: Did you ever get AP mode to work on 7612U? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#139 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCasgZlKJE_9ZqGPTDSp7G9t45O6wks5u9nxKgaJpZM4RS8Yv . -- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

Is this a hardware limitation or it's just not implemented by kernel/driver yet?

[LorenzoBianconi]

AP mode is not supported by mt76x2u driver (or mt76x0u) since usb does not provide tbtt interrupts … <#m-8839034381004729261> On Fri, Dec 28, 2018 at 9:17 PM chrismonks @.***> wrote: Did you ever get AP mode to work on 7612U? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#139 (comment) https://github.com/openwrt/mt76/issues/139#issuecomment-450420688>, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCasgZlKJE_9ZqGPTDSp7G9t45O6wks5u9nxKgaJpZM4RS8Yv . -- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

Is this a hardware limitation or it's just not implemented by kernel/driver yet?

usb does not support interrupt by default, it is not chipset related

Lorenzo

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139#issuecomment-453244073, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwNCe0cxbyGXbEEqU_ds2JGrdPFf3DSks5vB6QngaJpZM4RS8Yv .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[jksmurf]

Hi,

I'm a Linux newbie but can resonably follow instructions, which is what brought me here. I hope I am in the correct forum?

I've been testing Librelec Alpha Matrix 19 with Linux 5.1.1 [https://forum.kodi.tv/showthread.php?tid=298461&pid=2467317#pid2467317] with a Netgear A6210 and the dev kindly added the mt7612 firmware at my request after I told him the mt76x2 drivers seemed to have been recently updated in the kernel (correct me if I am wrong about this) [source https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c] shows the Netgear A6210 explicitly.

The wiki https://wikidevi.com/wiki/netgear_a6210 shows the device ID 0846 9053 which appears in the list of aliases (and so do the ASUS USB-AC54 (0b05 1833) and USB-AC55 (0b05 17eb).

I was hoping the new mt76x2 driver https://github.com/openwrt/mt76 would make it work finally on my RPi2 running Librelec Alpha but whilst I can actually get a brief connection, I am getting constant disconnects.

Power management is off on the devices by default it seems, so that's positive as a Netgear KB solution (in Windows) to disconnects was to turn that function off. It's running through a powered hub so power should be fine.

The A6210 doesn't come up by itself (at all), either as wlan0 (or wlan1) on boot if another (working) Wifi Adapter is not plugged in together with it. However if I start with the A6210 only, the Libreelec config shows Network Wireless Active ... but there are no connections. If I then (hot) plug/unplug the adapter the connections appear and I can even SSH in with putty (the logs attached are using this) but it then quickly drops the connection and putty times out. I'm at a loss because two other WiFi adapters TP-Link WN821N and TP-Link T4Uv2 both work without dropping conenctions.

I see there has been some discussions on the MT76x2 drivers (with subsequent updates) in Feb 19 https://patchwork.codeaurora.org/patch/731027/ which brought me here.

As regards messages I am not sure what is significant or not:

1. dmesg (attached) shows a number of these error messages mt76x2u 1-1.5.4:1.0: rx urb failed: -71
2. iw event -t -f shows "RSSI went above threshold" and "Beacon Loss"
3. Some authorize/deauthorize messages but this might be when I had to plug/unplug the adapter after it stopped working.

dmesg.txt iw_events.txt wlan and wiphy info.txt Another_dmesg_trial.txt

Happy to help troubleshoot if given guidance, if not then just happy to hear if there are other folks with a similar issue and that it's not just my system.

Cheers

k.

[LorenzoBianconi]

Hi,

I'm a Linux newbie but can resonably follow instructions, which is what brought me here. I hope I am in the correct forum?

I've been testing Librelec Alpha Matrix 19 with Linux 5.1.1 [https://forum.kodi.tv/showthread.php?tid=298461&pid=2467317#pid2467317] with a Netgear A6210 and the dev kindly added the mt7612 firmware at my request after I told him the mt76x2 drivers seemed to have been recently updated in the kernel (correct me if I am wrong about this) [source https://github.com/torvalds/linux/blob/master/drivers/net/wireless/mediatek/mt76/mt76x2/usb.c] shows the Netgear A6210 explicitly.

The wiki https://wikidevi.com/wiki/netgear_a6210 shows the device ID 0846 9053 which appears in the list of aliases (and so do the ASUS USB-AC54 (0b05 1833) and USB-AC55 (0b05 17eb).

I was hoping the new mt76x2 driver https://github.com/openwrt/mt76 would make it work finally on my RPi2 running Librelec Alpha but whilst I can actually get a brief connection, I am getting constant disconnects.

Power management is off on the devices by default it seems, so that's positive as a Netgear KB solution (in Windows) to disconnects was to turn that function off. It's running through a powered hub so power should be fine.

The A6210 doesn't come up by itself (at all), either as wlan0 (or wlan1) on boot if another (working) Wifi Adapter is not plugged in together with it. However if I start with the A6210 only, the Libreelec config shows Network Wireless Active ... but there are no connections. If I then (hot) plug/unplug the adapter the connections appear and I can even SSH in with putty (the logs attached are using this) but it then quickly drops the connection and putty times out. I'm at a loss because two other WiFi adapters TP-Link WN821N and TP-Link T4Uv2 both work without dropping conenctions.

Hi,

I have just compiled rpi-5.1.y from https://github.com/raspberrypi/linux for my rpi3 and my A6210 usb dongle works as expected. root@rasp-dev:/home/pi# iw dev wlxa040a05c9d56 link Connected to xx:xx:xx:80:11:15 (on wlxa040a05c9d56) SSID: xxxxxx freq: 5180 RX: 1700008 bytes (15077 packets) TX: 56847 bytes (477 packets) signal: -47 dBm tx bitrate: 6.0 MBit/s

   bss flags:      short-slot-time
   dtim period:    2
   beacon int:     100

root@rasp-dev:/home/pi# ethtool -i wlxa040a05c9d56 driver: mt76x2u version: 5.1.1-v7+ firmware-version: 0.0.00-b1 expansion-rom-version: bus-info: 1-1.2:1.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no

Could you please try to attach the usb dongle directly to the rpi?

Regards, Lorenzo

I see there has been some discussions on the MT76x2 drivers (with subsequent updates) in Feb 19 https://patchwork.codeaurora.org/patch/731027/ which brought me here.

As regards messages I am not sure what is significant or not:

dmesg (attached) shows a number of these error messages mt76x2u 1-1.5.4:1.0: rx urb failed: -71 iw event -t -f shows "RSSI went above threshold" and "Beacon Loss" Some authorize/deauthorize messages but this might be when I had to plug/unplug the adapter after it stopped working.

dmesg.txt iw_events.txt wlan and wiphy info.txt Another_dmesg_trial.txt

Happy to help troubleshoot if given guidance, if not then just happy to hear if there are other folks with a similar issue and that it's not just my system.

Cheers

k.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[jksmurf]

Hi Lorenzo,

Really appreciate your responding, much appreciated. From many threads around it seems you are the right person for this chipset. My apologies for the late reply, I had to find out how the commands to issue via SSH to get the data you sent above.

I put the Netgear A6210 Adapter directly into the RPi2 and it started but I got an undervoltage message. I only have a FLIRC and the Adapter; and the USB Powered Hub which should not be drawing power right? I disabled my very light overclock of the Pi to test and the same thing occurs.

What happens for me is on boot I can SSH into the RPi2 (PuTTY) and get the same sort of output as you. I then navigate around a while and it gets stuck, PuTTY says software caused a network disconnection but at the same time, (a) my router shows the WiFi adpater connected (see jpg) and (b) Libreelec's Configuration shows the Wireless network as Active and the Connection still available. At this point often (but not always) the Pi then reboots, if it does so by itself, I cannot putty (or WinSCP) in, despite (a) and (b) above. I then select disconnect/reconnect and refresh and despite it disconnecting, it fails when trying to reconnect. If I pull the power on the whole thing it works again like right in the beginning.

If I pull out the adapter and replug it, it will work fine, reconnects (then goes through the above cycle). I see error messages like "[ 19.106995] mt76x2u 1-1.4.3:1.0: vendor request req:07 off:1000 failed:-71" in the second dmesg paste. Also "[ 30.417452] mt76x2u 1-1.4.3:1.0: rx urb failed: -71" errors.

Can you tell me what I'd need to do to get a continuous dmesg log of what is happening leading up to and at the point of failure so someone more knowledable than me can interpret what is going on please? Or what I can help to provide (it might take a while I am really new to Linux)!

I am pretty sure the rest of the setup is fine, it works great running Kodi HD Videos using my TP-Link T4Uv2 (but this is an out of tree driver which Libreelec say they will remove in LE10).

EDIT: Would this be a similar issue as that for another mt67 based chip (based on error messages above)?

1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716301
2. https://bugzilla.kernel.org/show_bug.cgi?id=202673

Lastly I have been advised to open a kernel bug report https://forum.kodi.tv/showthread.php?tid=343068&pid=2855408#pid2855408 but looking at what others have done I don’t think I’m qualified to do so?

Thanks a lot!

Cheers Kristian dmesg2_lots errors re mt76x2.txt dmesg.txt

My dmesgs http://ix.io/1JxH http://ix.io/1JxK (lots of failed errors for mt76x2)

LibreELEC (Milhouse): devel-20190519212154-#0519-g77c88ba (RPi2.arm)
QTPi2:~ # iw dev wlan0 link
Connected to xx:xx:xx:xx:xx:ac (on wlan0)
        SSID: SmurfNET
        freq: 5220
        RX: 295894 bytes (1320 packets)
        TX: 107120 bytes (728 packets)
        signal: -43 dBm
        tx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2

        bss flags:      short-slot-time
        dtim period:    3
        beacon int:     100

QTPi2:~ # ethtool -i wlan0
driver: mt76x2u
version: 5.1.1
firmware-version: 0.0.00-b1
expansion-rom-version:
bus-info: 1-1.5:1.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

[LorenzoBianconi]

Hi Lorenzo,

Really appreciate your responding, much appreciated. From many threads around it seems you are the right person for this chipset. My apologies for the late reply, I had to find out how the commands to issue via SSH to get the data you sent above.

I put the Netgear A6210 Adapter directly into the RPi2 and it started but I got an undervoltage message. I only have a FLIRC and the Adapter; and the USB Powered Hub which should not be drawing power right? I disabled my very light overclock of the Pi to test and the same thing occurs.

Hi Kristian,

What are the specs of your power adapter? I guess you should use a 2A power adapter. Regards,

Lorenzo

What happens for me is on boot I can SSH into the RPi2 (PuTTY) and get the same sort of output as you. I then navigate around a while and it gets stuck, PuTTY says software caused a network disconnection but at the same time, (a) my router shows the WiFi adpater connected (see jpg) and (b) Libreelec's Configuration shows the Wireless network as Active and the Connection still available. At this point often (but not always) the Pi then reboots, if it does so by itself, I cannot putty (or WinSCP) in, despite (a) and (b) above. I then select disconnect/reconnect and refresh and despite it dsiconencting, it fails when trying to reconnect. If I pull the power on the whole thing it works again like right in the beginning.

If I pull out the adapter and replug it, it will work fine, reconnects (then goes through the above cycle). I see error messages like "[ 19.106995] mt76x2u 1-1.4.3:1.0: vendor request req:07 off:1000 failed:-71" in the second dmesg paste. Also "[ 30.417452] mt76x2u 1-1.4.3:1.0: rx urb failed: -71" errors.

Can you tell me what I'd need to do to get a continuous dmesg log of what is happening leading up to and at the point of failure so someone more knowledable than me can interpret what is going on please?

Thanks a lot!

Cheers Kristian dmesg2_lots errors re mt76x2.txt https://github.com/openwrt/mt76/files/3196329/dmesg2_lots.errors.re.mt76x2.txt dmesg.txt https://github.com/openwrt/mt76/files/3196331/dmesg.txt [image: Netgear_after_Crash] https://user-images.githubusercontent.com/23158634/57997671-869a8200-7b00-11e9-8bcf-3c6e68a04c1f.jpg [image: IMG_0825] https://user-images.githubusercontent.com/23158634/57997689-9fa33300-7b00-11e9-8466-1f5d710e92f1.JPG

My dmesgs http://ix.io/1JxH http://ix.io/1JxK (lots of failed errors for mt76x2)

LibreELEC (Milhouse): devel-20190519212154-#0519-g77c88ba (RPi2.arm) QTPi2:~ # iw dev wlan0 link Connected to xx:xx:xx:xx:xx:ac (on wlan0) SSID: SmurfNET freq: 5220 RX: 295894 bytes (1320 packets) TX: 107120 bytes (728 packets) signal: -43 dBm tx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2

bss flags:      short-slot-time
dtim period:    3
beacon int:     100

QTPi2:~ # ethtool -i wlan0 driver: mt76x2u version: 5.1.1 firmware-version: 0.0.00-b1 expansion-rom-version: bus-info: 1-1.5:1.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/139?email_source=notifications&email_token=AAOA2CJU4WOPRPJU4O4UKGTPWIXQFA5CNFSM4EKLYYX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVXWXCY#issuecomment-493841291, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOA2CLTVU2DRKGKT5TTL63PWIXQFANCNFSM4EKLYYXQ .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[jksmurf]

Hi Lorenzo; yes, 5.1v 2.1A, tested voltage = 5.3v (no load). Tried many power adapters, my wife is an electronics engineer she measured them with a voltmeter (ok not under load I'll admit and did not use an oscilloscope, but anyway, I have read a lot about power supply and cables recently!). I also have a good very short Micro-USB Cable. Low voltage messages I got were when I didn’t use the hub and plugged in the Adapter to the RPi2; but I have tried with and without the hub. Like I said though, no issues with the other adapter, on the same rig. Did you have time to see the other info / queries, anything else I need to provide? thank you once again k.

[jksmurf]

Apologies all, I saw (too late) that this thread has been marked closed

At the advice of Milhouse https://forum.kodi.tv/showthread.php?tid=343068&pid=2855408#pid2855408 I have been recommended to open a Kernel bug report on the issue. I have done so here https://bugzilla.kernel.org/show_bug.cgi?id=203657. Thanks, k.

[liugang]

Does AP Mode be supported?

https://github.com/torvalds/linux/commits/master/drivers/net/wireless/mediatek/mt76/mt76x02_util.c

https://github.com/torvalds/linux/commit/02d49a2e354b2026e1b0f60aabeafc37d540a2e1#diff-8a314ab288ac846fcfd720f17fe99c47

mt76x02: enable AP mode for USB

Enable AP mode. For now without multi-vif support, this will require more testing and investigation.