On Thu, Dec 19, 2013 at 01:38:54PM +0000, Chris Sykes wrote: > Hi, > > I have a user space application which communicates with an embedded > micro-controller over USB via an FTDI FT232H chip. > > I'm seeing occasional data loss while reading data transmitted by the > micro, and I believe that when this occurs the FTDI UART Rx fifo is being > overrun (there's no flow control between the micro and FTDI part). > > I captured a trace of one of these overflows using usbmon and it appears to > show the host stops polling the FTDI device for 200ms. The FTDI chip is > at address 2:011, there's also a USB mass storage device on the bus at > 2:002: > > Normal bulk-in transfers, submissions/callbacks are all interleaved, FTDI > status bytes == 0x3620: > f7243700 878013928 C Bi:2:011:1 0 202 = 326006ae ... > f7243700 878013948 S Bi:2:011:1 -115 512 < > f7243d00 878014928 C Bi:2:011:1 0 202 = 3260994f ... > f7243d00 878014948 S Bi:2:011:1 -115 512 < > f7243700 878015921 C Bi:2:011:1 0 202 = 3260543e ... > > Then we see two callback responses to a single submission: > f7243700 878015939 S Bi:2:011:1 -115 512 < > f7243d00 878016920 C Bi:2:011:1 0 202 = 32609a01 ... > f7243700 878017929 C Bi:2:011:1 0 202 = 3260cf55 ... > > Then the trace goes idle for almost 200ms, eventually there are some > transfers to/from the mass storage device: > f71cef80 878215673 C Bi:2:002:1 0 13 = 55534253 f82a0000 00000000 00 > f71cef80 878215857 S Bo:2:002:2 -115 31 = 55534243 ... > f71cef80 878215922 C Bo:2:002:2 0 31 > > f7243680 878215953 S Bo:2:002:2 -115 512 = 626f6f74 ... > f7243680 878218558 C Bo:2:002:2 0 512 > > f71cef80 878218605 S Bi:2:002:1 -115 13 < > f71cef80 878228672 C Bi:2:002:1 0 13 = 55534253 f92a0000 00000000 00 > > ~212ms after the last exchange with the FTDI device, the host appears to > send two back-to-back Bi submissions (18us apart), the responses from the > FTDI device show the status bytes have changed to 0x3262. I believe the > bit that's changed indicates an overrun of the FTDI Rx FIFO (not surprising > if it's not been serviced for over 200ms): > > +212078 f7243700 878230007 S Bi:2:011:1 -115 512 < > f7243d00 878230025 S Bi:2:011:1 -115 512 < > f7243700 878230167 C Bi:2:011:1 0 202 = 32624c06 ... > f7243700 878230186 S Bi:2:011:1 -115 512 < > f7243d00 878230194 C Bi:2:011:1 0 202 = 3262ae09 ... > f7243d00 878230200 S Bi:2:011:1 -115 512 < > f7243700 878230288 C Bi:2:011:1 0 2 = 3262 > f7243700 878230294 S Bi:2:011:1 -115 512 < > f7243d00 878230922 C Bi:2:011:1 0 176 = 3260398e ... > f7243d00 878230944 S Bi:2:011:1 -115 512 < > > The ttyUSBX device remains open throughout, and my application is > polling/reading the device descriptor in a loop. > > Kernel is: > 3.10.17-yocto-standard (latest from the Yocto poky stable branch). > > The host controller is: > Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 04) > > I realise that this configuration is never going to be that reliable > without flow control between the micro and the FTDI chip, but I was hoping > that somebody might be able to help explain why the host appears to have > stopped polling the device for >200ms? Was anything else going on on your machine during that time period? USB can be held off for long periods of time for no real reason, but that does seem like a long time. And yes, the real solution is to use flow control, but still, this shouldn't be happening. What type of cpu/system is this running on? thanks, greg k-h -- 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
