On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: > On 12/16/2014 02:15 PM, Peter Chen wrote: > > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > >> On 12/16/2014 06:16 AM, Peter Chen wrote: > >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > >>>> Hello, > >>>> > >>>> On 12/15/2014 07:42 AM, Peter Chen wrote: > >>>>> On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > >>>>>> Hello, > >>>>>> > >>>>>> On 12/12/2014 07:21 AM, Peter Chen wrote: > >>>>>>> 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. > >>>>>> > >>>>>> We did think that it is probably an issue seen with Vybrids only. > >>>>>> > >>>>> > >>>>> - Check Vybrid errata to see if any missing in code > >>>> > >>>> I had not checked the Vybrid errata. There are two erratas and I think one > >>>> of them might be relevant to the issue. > >>>> > >>>> e6857: Adding dTD to Primed Endpoint may not be recognized > >>>> > >>> > > > > Sorry, I made a mistake, it is a new errata, and does not be included in > > the code. All imx project uses 2.0a or 2.50a which does not need this > > errata, and Vybrid uses 2.40a core which needs this errata, I will do a > > patch for this soon, but before that, would you read your ID register > > ($BASE + 0x0) for me? I would like to confirm if your REVISION value > > is 0100b. > > > > As per the reference manual and also the devmem2 readout of the USB ID register > the value is 0xE481FA05. This gives a Revision number 0x81 for the controller > core and 0x05 for the ID viz. configuration number. > Thanks, Revision Number is bit 21 - bit 24, it is 0100b if your ID value is 0xE481FA05. -- 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
