Connection drop while running iperf on ARM based platform

DISCUSSION Michael Hirsch 2 participants 2 messages Apr 15, 2014 – Apr 19, 2014

lore

Share & tools

lore

Michael Hirsch

author

2014-04-15 09:35 UTC #0 lore raw

Hi all,

I have an issue using a with RT5572 chipset (TP-Link N600) on a Armada based embedded system.

After connecting to an AP and using iperf to stress-test the USB Wifi Dongle stops receiving data. Kernel version is 3.14, it happens both on firmware version 0.29 and 0.33.

iperf -c 192.168.44.170 -i 1 -t 1000 &
# ------------------------------------------------------------ Client connecting to 192.168.44.170, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.44.245 port 55342 connected with 192.168.44.170 port 5001

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  2.12 MBytes  17.8 Mbits/sec
[  147.046945] ieee80211 phy2: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick
[  3]  1.0- 2.0 sec  2.25 MBytes  18.9 Mbits/sec
[  148.046626] ieee80211 phy2: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick
[  148.058795] ieee80211 phy2: rt2800usb_txdone: Warning - Got TX status for an empty queue 3, dropping
[  3]  2.0- 3.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  3.0- 4.0 sec  1.88 MBytes  15.7 Mbits/sec
[  3]  4.0- 5.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3]  5.0- 6.0 sec  2.12 MBytes  17.8 Mbits/sec
[  3]  6.0- 7.0 sec  2.12 MBytes  17.8 Mbits/sec
[  3]  7.0- 8.0 sec  2.38 MBytes  19.9 Mbits/sec
[  3]  8.0- 9.0 sec  2.12 MBytes  17.8 Mbits/sec
[  155.047086] ieee80211 phy2: rt2800usb_watchdog: Warning - TX HW queue 1 timed out, invoke forced kick
[  155.067200] ieee80211 phy2: rt2800usb_txdone: Warning - Got TX status for an empty queue 3, dropping
[  3]  9.0-10.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3] 10.0-11.0 sec  2.25 MBytes  18.9 Mbits/sec
[  3] 11.0-12.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3] 12.0-13.0 sec  1.88 MBytes  15.7 Mbits/sec
[  158.343582] ieee80211 phy2: rt2800usb_txdone: Warning - Got TX status for an empty queue 3, dropping
[  3] 13.0-14.0 sec  1.62 MBytes  13.6 Mbits/sec
[  3] 14.0-15.0 sec  1.88 MBytes  15.7 Mbits/sec
[  3] 15.0-16.0 sec  2.25 MBytes  18.9 Mbits/sec
[  162.116741] ieee80211 phy2: rt2800usb_txdone: Warning - Got TX status for an empty queue 3, dropping
[  3] 16.0-17.0 sec  2.25 MBytes  18.9 Mbits/sec
[  3] 17.0-18.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3] 18.0-19.0 sec  1.62 MBytes  13.6 Mbits/sec
[  3] 19.0-20.0 sec  2.12 MBytes  17.8 Mbits/sec
[  3] 20.0-21.0 sec  2.00 MBytes  16.8 Mbits/sec
[  3] 21.0-22.0 sec  1.62 MBytes  13.6 Mbits/sec
[  3] 22.0-23.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3] 23.0-24.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3] 24.0-25.0 sec  1.75 MBytes  14.7 Mbits/sec
[  3] 25.0-26.0 sec  1.50 MBytes  12.6 Mbits/sec
[  171.816309] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
[  171.827208] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
[  171.838062] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
[  171.848877] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
[  171.859690] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
[  171.870544] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 15 in queue 2
[  171.881371] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 15 in queue 2
[  171.892183] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
[  171.902905] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
[  171.913630] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 1 in queue 2
[  171.924348] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 1 in queue 2
[  171.935094] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue 2
[  171.945816] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue 2
[  171.956571] ieee80211 phy2: rt2800usband_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
[  171.967293] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
[  171.978020] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 2
[  171.988754] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 2
[  171.999496] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2
[  172.010217] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2
[  172.022059] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2
[  172.033004] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[  172.043807] ieee80211 phy2: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2

and it stops.

I noticed
iw dev wlan1 link shows a tx bitrate of 1.0 MBit/s and according to iw it does not receive any packets any more.

Running the same wifi module on a x86 Laptop with 3.14 kernel works better.

There is also drops to 0 at running iperf, but it seems to be able to recover. Also on a x86 laptops is see the TX Status timeout messages (if it's enabled in the kernel config). I followed the discussion a bit about those messages and can't say whether these messages have anything todo with shown issue (no packets received)

Any suggestion where I could start searching? For me it looks like a rate-control issue, but that's speculation.

Best regards

Michael

Andreas Hartmann

2014-04-19 12:57 UTC #1 lore raw

Quoted 4 lines · Michael Hirsch

Hi all,
I have an issue using a with RT5572 chipset (TP-Link N600) on a Armada based embedded system.

The actual rt2800usb module unfortunately is broken (and nobody seems to be working on them any more.) They are considered to be ready :-) [1].

Xose Vazquez Perez wrote in [1]: "because the goal already was reached". Well, if the goal was to kick out the far better working vendor drivers
- it is really reached. But it was obviously never the goal to achieve the same (or even better) quality.

Besides that, rt2800usb isn't considered for chips other than rt2x00 [2].

Therefore:
Don't use it. Try rt5572sta (DPO_RT5572_LinuxSTA_2.6.1.3_20121022) from mediatek.com. You may add these patches:

For 64bit (most probably not needed for arm):
http://thread.gmane.org/gmane.linux.network/313147

for EAP-TLS:
http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1249/focus=1474
Apply it with
patch -R -p1 --dry-run <1474-001.bin

If your kernel uses CONFIG_UIDGID_STRICT_TYPE_CHECKS:
http://article.gmane.org/gmane.linux.drivers.rt2x00.user/2450
(With kernel 3.14, you have to modify the patch, because 3.14 removed CONFIG_UIDGID_STRICT_TYPE_CHECKS).

Maybe you have to add the usb device id to DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtusb_dev_id.c

Quoted 1 line

Running the same wifi module on a x86 Laptop with 3.14 kernel works better.

Anyway, most probably not good at all. That's at least my finding for rt3572 and rt3573, which both work _much_ better and completely stable with high throughput even w/ bad radio conditions as sta with the vendor driver.

Quoted 8 lines

There is also drops to 0 at running iperf, but it seems to be able to recover. Also on a x86 laptops is see the TX Status timeout messages (if it's enabled in the kernel config). I followed the discussion a bit about those messages and can't say whether these messages have anything todo with shown issue (no packets received)
Any suggestion where I could start searching? For me it looks like a rate-control issue, but that's speculation.

Additionally, USB handling compared to vendor driver is suboptimal. rt2800usb needs far to much system resources to "work".

Regards,
Andreas

[1]
http://news.gmane.org/find-root.php?group=gmane.linux.drivers.rt2x00.user&article=2441
[2] http://permalink.gmane.org/gmane.linux.drivers.rt2x00.user/2468

linux/rt_linux.c renamed from linux/rt_linux.c.orig +10 -0

@@ -34,6 +34,10 @@
 #include "rt_os_util.h"
 #include <linux/rtnetlink.h>
 
+#ifdef CONFIG_UIDGID_STRICT_TYPE_CHECKS
+#include <linux/uidgid.h>
+#endif
+
 #if defined(CONFIG_RA_HW_NAT) || defined(CONFIG_RA_HW_NAT_MODULE)
 #include "../../../../../../net/nat/hw_nat/ra_nat.h"
 #include "../../../../../../net/nat/hw_nat/frame_engine.h"

@@ -1138,9 +1142,15 @@
 		pOSFSInfo->fsgid = current->fsgid;
 		current->fsuid = current->fsgid = 0;
 #else
+#ifdef CONFIG_UIDGID_STRICT_TYPE_CHECKS
+		struct user_namespace *to = current_user_ns();
+		pOSFSInfo->fsuid = from_kuid_munged(to, current_fsuid());
+		pOSFSInfo->fsgid = from_kgid_munged(to, current_fsgid());
+#else
 		pOSFSInfo->fsuid = current_fsuid();
 		pOSFSInfo->fsgid = current_fsgid();
 #endif
+#endif
 		pOSFSInfo->fs = get_fs();
 		set_fs(KERNEL_DS);
 	} else {