Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just "ping" to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is "kevent 12 may have been dropped". I guess this is connected to the "TCP Previous Segment not captured" and "TCP Dup ACK" messages.
My script for the gadget configuration is as below: /bin/mount none /mnt -t configfs /bin/mkdir /mnt/usb_gadget/g1 cd /mnt/usb_gadget/g1 /bin/mkdir configs/c.1 /bin/mkdir functions/ecm.0 /bin/mkdir strings/0x409 /bin/mkdir configs/c.1/strings/0x409 echo 0xa4a2 > idProduct echo 0x0525 > idVendor echo Freescale123 > strings/0x409/serialnumber echo Freescale > strings/0x409/manufacturer echo "USB Serial Gadget" > strings/0x409/product echo "Conf 1" > configs/c.1/strings/0x409/configuration echo 200 > configs/c.1/MaxPower ln -s functions/ecm.0 configs/c.1 echo ci_hdrc.0 > UDC /sbin/ifconfig usb0 up /sbin/ifconfig usb0 192.168.1.10 I have debug prints in the udc.c and u_ether.c using pr_debug and enable them when required using dynamic debug. Without running iperf, using ping gives me a sequence of prints as below: [ 277.434409] In eth_start_xmit [ 277.434517] In UDC irq [ 277.434553] In usb_gadget_giveback_request [ 277.434567] In tx_complete [ 277.435443] In UDC irq [ 277.435477] In usb_gadget_giveback_request [ 277.435491] In rx_complete [ 277.435517] In rx_submit [ 277.435601] In eth_start_xmit [ 277.436441] In UDC irq [ 277.436465] In usb_gadget_giveback_request [ 277.436478] In rx_complete [ 277.436493] In rx_submit [ 277.436520] In usb_gadget_giveback_request [ 277.436533] In tx_complete [ 278.434865] In eth_start_xmit [ 278.434959] In UDC irq [ 278.434993] In usb_gadget_giveback_request [ 278.435006] In tx_complete [ 278.435881] In UDC irq [ 278.435910] In usb_gadget_giveback_request [ 278.435923] In rx_complete [ 278.435946] In rx_submit After running iperf without debug prints and then enabling before using ping gives me a sequence of prints as below [ 81.989827] In UDC irq [ 81.989871] In usb_gadget_giveback_request [ 81.989886] In rx_complete [ 81.989905] In rx_submit [ 82.989892] In UDC irq [ 82.989951] In usb_gadget_giveback_request [ 82.989967] In rx_complete [ 82.989992] In rx_submit [ 83.990064] In UDC irq [ 83.990126] In usb_gadget_giveback_request [ 83.990142] In rx_complete [ 83.990167] In rx_submit [ 84.990007] In UDC irq [ 84.990049] In usb_gadget_giveback_request [ 84.990064] In rx_complete [ 84.990083] In rx_submit [ 85.990085] In UDC irq [ 85.990147] In usb_gadget_giveback_request [ 85.990163] In rx_complete [ 85.990188] In rx_submit If I force a full speed configuration for this USB client port, I get a slightly more reliable operation where iperf can run for may be half an hour or so or almost an hour before it falls through. Putting in a delay of 100-150 microseconds in eth_start_xmit also improves it like full speed, but, still not reliable. If I run iperf with debug prints enable, this gives similar results to full speed config. After the failure of iperf test, even ping doesn't work. Bringing down this usb0 interface and then up again makes ping work again. I do realize that putting debug prints or delays like this is not the right thing to do, especially in ISR, but, just trying to debug. This is my first time digging in the USB stack. Based on the above, it seems there might a subtle bug or race condition somewhere in the execution call chain which I have not been able to trace yet. Can someone give me some pointers on how I can dig and debug further?. Regards, Sanchayan. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
