> On 3 May 2019, at 02:31, Hans Petter Selasky <[email protected]> wrote:
>
> On 2019-05-02 13:38, O'Connor, Daniel wrote:
>>> On 2 May 2019, at 20:33, Hans Petter Selasky <[email protected]> wrote:
>>>
>>> On 2019-05-02 12:44, O'Connor, Daniel wrote:
>>>>> On 2 May 2019, at 20:02, Hans Petter Selasky <[email protected]> wrote:
>>>>>
>>>>> On 2019-05-02 11:18, O'Connor, Daniel wrote:
>>>>>> OK, thanks.
>>>>>> To be honest I would much prefer to work out why this particular
>>>>>> hardware & software seem to drop the ball for such a long time - 50msec
>>>>>> without the kernel getting to schedule something (on a basically idle
>>>>>> system) is quite perplexing to me.
>>>>>
>>>>> Sounds like a lost IRQ issue. Did you try any of the EHCI quirks in
>>>>> hw.usb.ehci ?
>>>> No not, yet - thanks for the pointer!
>>>
>>> The 50ms delay may also be due to a physical link data error and needed
>>> recovery through clear stall which is expensive.
>>>
>> I see the same error on different hardware sets (both motherboard and USB
>> device) so I don't think it's that.
>
> If you can check if a USB BULK transfer is pending during this delay, then it
> might also be a firmware issue.
OK, I'll try and come up with a program to process usbdump output and show
things like response latency.
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
