We are experiencing problems transferring USB data between two sabresd board, one acting as USB device, the other as USB host.
Steps to reproduce the problem:
1) Connect two sabresd boards with a micro USB cable and a USB OTG host adapter, both the cables will be connected to the USB OTG port of the board, the board with the micro USB cable connected will be called "board A" (being USB device) and the one with the USB OTG host adapter connected "board B" (being USB host)
2) Run Ltib 4.1.0 image for sabresd on both boards
3) On board B recompile Linux Kernel, enabling the following entries (both are in Device Drivers / Network device support / USB Network Adapters)
a) <*> Multi-purpose USB Networking Framework (CONFIG_USB_USBNET)
b) <*> CDC Ethernet support (smart devices such as cable modems) (CONFIG_USB_NET_CDCETHER)
4) On board A:
a) load g_ether module (modprobe g_ether)
b) assign an IP address to the usb0 interface (e.g. ifconfig usb0 10.1.2.1)
c) run: iperf -s
5) On board B:
a) assign an IP address to the usb0 interface (e.g. ifconfig usb0 10.1.2.2)
b) run: iperf -c 10.1.2.1 -t 86400 -i 1
Usually in at most 40 minutes the transfer is blocked, sometimes for some seconds, sometimes forever. You could see it's blocked from the iperf output from board B, it usually gets updated once every second giving the actual transfer bandwidth, when the transfer is blocked the output doesn't get updated or it reports 0 bandwidth. Also often when the problem occurs an output similar to the following is output on board B console (or in dmesg):
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x288/0x2ac()
NETDEV WATCHDOG: usb0 (cdc_ether): transmit queue 0 timed out
Modules linked in: unifi_sdio
[<8003d6c8>] (unwind_backtrace+0x0/0xf8) from [<800684e8>] (warn_slowpath_commo)
[<800684e8>] (warn_slowpath_common+0x4c/0x64) from [<80068594>] (warn_slowpath_)
[<80068594>] (warn_slowpath_fmt+0x30/0x40) from [<80370030>] (dev_watchdog+0x28)
[<80370030>] (dev_watchdog+0x288/0x2ac) from [<80073d10>] (run_timer_softirq+0x)
[<80073d10>] (run_timer_softirq+0xec/0x214) from [<8006ddf4>] (__do_softirq+0xa)
[<8006ddf4>] (__do_softirq+0xac/0x140) from [<8006e330>] (irq_exit+0x94/0x9c)
[<8006e330>] (irq_exit+0x94/0x9c) from [<800312e0>] (do_IPI+0x10c/0x17c)
[<800312e0>] (do_IPI+0x10c/0x17c) from [<80036a4c>] (__irq_svc+0x4c/0xe8)
Exception stack(0x94051f90 to 0x94051fd8)
1f80: 806234e0 80000093 00000001 00000000
1fa0: 94050000 8061c124 8045db28 805f20f4 1000406a 412fc09a 00000000 00000000
1fc0: 00000000 94051fd8 800454e8 80037b38 40000013 ffffffff
[<80036a4c>] (__irq_svc+0x4c/0xe8) from [<80037b38>] (default_idle+0x24/0x28)
[<80037b38>] (default_idle+0x24/0x28) from [<80037d3c>] (cpu_idle+0xc8/0x108)
[<80037d3c>] (cpu_idle+0xc8/0x108) from [<10452b14>] (0x10452b14)
---[ end trace d61d8bd232f84b47 ]---
When the transfer is blocked we found 2 ways to unblock it:
1) on Board B, put iperf to background (with ctrl-Z, then with the command "bg"), then to foreground again (with the command "fg")
2) on Board B run a ping to Board A (e.g. "ping 10.1.2.1")
We also tried using other gadget drivers without any success (cdc_eem, to reproduce with it you should just replace step 4a with the following command: "modprobe g_ether use_eem=1"). We tried using the latest iperf available (2.0.5), without success. The problem shows up also using scp/netcat instead of iperf.
We run many tests and the problem seems to not be present on Yocto 1.6 from fsl-community-bsp, running the default kernel (3.10.17).
