On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > Hi, > > On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > > 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 > > just a little hint, use any of the dev_*() macros next time, they'll > print the device name which helps figuring out which UDC you're using. > > Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen > maintains that one, it really helps adding maintainers to Cc list. > > > 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?. > I just tried latest usb-next with i.mx6 platform, it works ok with 10 mins iperf bi-direction test. I am wronging Vybrid is not fast enough, run top to see if iperf occupies too much (>95%) cpu utilization, if it is, run perf top (or similar perf tool) to see which function affects most, from my experiences, CONFIG_SMP affects UP platform's performance, try to disable it. > yeah, I'd start pointing fingers at chipidea. But just to make sure, can > you try the same thing with dummy_hcd ? dummy_hcd is a SW-only host and > peripheral "controller" pair tied together. If that one works, you > definitely have a bug with chipidea. > > If you want to debug chipidea like that, I'd strongly suggest using > either tracepoints (which would have to be added to chipidea; but hey, > desirable patch - see drivers/usb/dwc3/trace.h for reference) or just > use plain old trace_printk(). > > Then setup a huge trace buffer (I usually go for 20MiB or more) and > reproduce the failure; read trace, add more traces, try again, until you > find out where the problem lies. > > good luck, and please send patches if you manage to solve the problem > :-) > > -- > balbi -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
