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? 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. Thanks for your inputs. -Regards, Sanchayan. -- 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
