> From: Chris Sykes
> 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 ...
Looks like the driver is double-buffering reads.
So you are seeing both URB completing (at the usual time interval).
I'd add some timestamped traces to the driver that is generating the
URB and work out where/why it isn't processing the completion upcall
and resubmitting the URB.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
