> On 12/17/2014 05:46 AM, Peter Chen wrote: > > 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. > > > > I was wondering how you got the numbers exactly. The reference manual > shows bit 16 - bit 23 as the revision of the controller core, bit 0 - bit 5 as the ID > and bit 24 - bit 31 are reserved. Just for my own information is there a different > interpretation as well? > It seems the RM just follows earlier chipidea core (1.1a) > Just to be clear so this confirms that the Vybrid has 2.40 core which needs the > errata and which is presently not implemented in software, which results in the > issue we are seeing? Otherwise I will just carry on my testing and also try and > see if I can implement the errata fix. > Yes, it is not implemented in software, it may be result in your issue. Peter -- 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
