Re: Query regarding USB gadget driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux