Michael Hirsch wrote:
> 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
> 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.
> 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
--- os/linux/rt_linux.c.orig 2012-10-22 05:52:59.000000000 +0200
+++ os/linux/rt_linux.c 2013-12-28 19:13:28.677118438 +0100
@@ -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 {
