> From: Bin Liu [mailto:b-liu@xxxxxx] > On Thu, May 05, 2016 at 03:12:00PM +0000, Andrew Goodbody wrote: > > > From: Bin Liu [mailto:b-liu@xxxxxx] > > > Hi, > > > > > > On Thu, May 05, 2016 at 12:22:33PM +0000, Andrew Goodbody wrote: > > > > > From: Bin Liu [mailto:b-liu@xxxxxx] Hi, > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +0000, Andrew Goodbody > wrote: > > > > > > Hi, > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > When the system is busy it seems that the musb driver is > > > > > > silently dropping occasional packets. I have a usbmon trace > > > > > > that does not show the packet and I have a trace from a > > > > > > hardware USB analyser that does show the packet. So the device > > > > > > is correctly sending the packet, it is even being ACKed, but > > > > > > it is not passed up to the application. The packet is a bulk > > > > > > transfer packet of 20 bytes. Can anyone please give me > > > > > > pointers to where to go looking for the problem? The syslog shows > nothing relevant. > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > AM3352BZCZ100 > > > > > > > > > What kernel version do you use? > > > > > > > > 4.5.0 > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still happen > > > > > when CPPI disabled? > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > interrupt with no > > > errors or packet!". > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to check > > > > > if musb receives the packet or not. > > > > > > > > > > Regards, > > > > > -Bin. > > > > > > > > I am having problems doing this. If I enable the whole file then I > > > > get lots of messages on the console about /dev/kmsg buffer > > > > overrun. There are more then 26 million packets in the hardware > > > > trace and I have not worked out how to correlate any of the > > > > possible message from dynamic debug with those packets even when I > > > > enable some of the dynamic debug lines. I can see a few messages > > > > about "DMA complete but packet still in FIFO, CSR 2103" and just the > occasional "extra TX2 ready, csr 2100" > > > > when I enable some of the lines for dynamic debug. > > > > > > Well, this issue would not be easy to debug. Is this with your custom > board? > > > If so, have you run EyeDiagram test to rule out signal integrity > > > problem? Are you able to reproduce it with any TI EVM, such as > > > Beaglebone Black? If so, please explain the detail of the test case, > > > I could try to reproduce it on my side. > > > > Yes this is on a custom board and yes we did EyeDiagram tests. Also > > the ACK from the controller is seen, so that should rule out signal > > integrity issues. I have just reproduced this on the Beaglebone Black > > using the latest TI SDK. Do you have access to 16 iPads with lightning > > connectors and do you have a Mac running 10.10.x? > > No, I don't have those :( > > 16 devices connecting to musb sounds too many. what is the ep info in the > descriptor of the ipad device? T: Bus=02 Lev=04 Prnt=06 Port=06 Cnt=07 Dev#= 19 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 4 P: Vendor=05ac ProdID=12ab Rev= 3.40 S: Manufacturer=Apple Inc. S: Product=iPad S: SerialNumber=1da5f4610eafb36fa1e9eead80a56cb2db11dfce C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver= E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms C: #Ifs= 3 Cfg#= 2 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver= I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver= I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver= E: Ad=81(I) Atr=01(Isoc) MxPS= 192 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=125us C:* #Ifs= 2 Cfg#= 3 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fe Prot=02 Driver=usbfs E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms C: #Ifs= 3 Cfg#= 4 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver= E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fe Prot=02 Driver= E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=fd Prot=01 Driver= I: If#= 2 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=fd Prot=01 Driver= E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=fd Prot=01 Driver= E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Config #4 is the relevant one. Interface #0 quickly uses up the controller endpoints and then starts to return -ENOSPC thereafter for the interrupt URBs from later iPads, but that does not matter for my use case. Interface #1 is the one that is actually used, just a bulk in and a bulk out endpoint. So some URBs get opened on controller endpoints 2-15, but most are just queued up on controller endpoint 1. Yes this will keep the controller busy. Although I said 16 iPads, this problem will happen with fewer, it just becomes rarer. Andrew > > > > > > > > Andrew > > > > > > Regards, > > > -Bin. -- 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
