Hello,
This question was posted on forum Windows Hardware WDK and Driver
Development. Mr. Gupta from MS ask some questions, and thread is sleep for
now. But i need solve this strange behavior…
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-
US/fbad1f95-16d0-4a9f-8758-72ff3078fd9f/usb-20-device-
interrupt-transfer-timing-issue-on-usb-30-extensible-
host-controller-port-w10w8?forum=wdk
Original question:
we have a USB 2.0 high-speed device. When device is connected to USB 3.0
USB extensible host controller port, then interrupt transfers are coming in
8 ms interval (picture 1), instead of 4 ms (picture 2), as specified in
configuration descriptor (bInterval in my descriptor is 6 => 32*0.125us =>
4ms).
When USB 3.0 host controller is disabled in BIOS, then interrupt transfers
are properly timed again.
This behavior was tested on different mainboards. Mostly with Z97 and Q87
Intel chipset. Windows 8 and Windows 10. USB tracer is Ellisys USB
Explorer. Device is “vendor specific”, and don’t belong under any class.
Driver is old WDM style, but work for years…
Seem, Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) driver
do wrong timing for interrupt transfers, when device is vendor specific.
When device is class device (for example USB HDD), then interrupt transfers
are properly timed.
From the side of device driver i can’t do anything regard of interrupt
transfer timing. Or?
It’s not a case of slow driver, because (for test purpose) changing of
bInterval to 5, interrupt transfers coming in 4ms intervals.
Does anyone have an idea where to look for a mistake? Something in
descriptors, or driver?
Picture1 (USB 3.0 HC port): https://social.msdn.microsoft.
com/Forums/getfile/944062
Picture2 (USB 2.0 HC port): https://social.msdn.microsoft.
com/Forums/getfile/944064
Best regards,
Slavomir Tomascik
Slavo Tomascik wrote:
we have a USB 2.0 high-speed device. When device is connected to USB
3.0 USB extensible host controller port, then interrupt transfers are
coming in 8 ms interval (picture 1), instead of 4 ms (picture 2), as
specified in configuration descriptor (bInterval in my descriptor is 6
=> 32*0.125us => 4ms).
When USB 3.0 host controller is disabled in BIOS, then interrupt
transfers are properly timed again.
This behavior was tested on different mainboards. Mostly with Z97 and
Q87 Intel chipset. Windows 8 and Windows 10. USB tracer is Ellisys USB
Explorer. Device is “vendor specific”, and don’t belong under any
class. Driver is old WDM style, but work for years…
Seem, Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
driver do wrong timing for interrupt transfers, when device is vendor
specific. When device is class device (for example USB HDD), then
interrupt transfers are properly timed.
How does your driver do its URBs? Do you have several URBs outstanding
at any given time?
Here’s my line of thinking. If you only had one URB outstanding, then
it’s possible that the USB 3 overhead is just enough higher that you
can’t get your request turned around and resubmitted in 4 ms. In that
case, you’d miss every other interval.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
thanks for interesting idea. As you point, i have only one outstanding URB
at a time. After completion, URB is reused, and send again. But i think
it’s not this case. For testing purposes, device descriptor was modified to
bInterval = 5, and interrupt transfers coming in 4ms intervals. In case of
USB3 overhead, or driver URB slow processing, will be time 8ms regardless
of bInterval value.
Slavomir.
On Tue, Nov 22, 2016 at 10:17 PM, Tim Roberts wrote:
> Slavo Tomascik wrote:
> >
> > we have a USB 2.0 high-speed device. When device is connected to USB
> > 3.0 USB extensible host controller port, then interrupt transfers are
> > coming in 8 ms interval (picture 1), instead of 4 ms (picture 2), as
> > specified in configuration descriptor (bInterval in my descriptor is 6
> > => 32*0.125us => 4ms).
> > When USB 3.0 host controller is disabled in BIOS, then interrupt
> > transfers are properly timed again.
> >
> > This behavior was tested on different mainboards. Mostly with Z97 and
> > Q87 Intel chipset. Windows 8 and Windows 10. USB tracer is Ellisys USB
> > Explorer. Device is “vendor specific”, and don’t belong under any
> > class. Driver is old WDM style, but work for years…
> > Seem, Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
> > driver do wrong timing for interrupt transfers, when device is vendor
> > specific. When device is class device (for example USB HDD), then
> > interrupt transfers are properly timed.
> >
>
> How does your driver do its URBs? Do you have several URBs outstanding
> at any given time?
>
> Here’s my line of thinking. If you only had one URB outstanding, then
> it’s possible that the USB 3 overhead is just enough higher that you
> can’t get your request turned around and resubmitted in 4 ms. In that
> case, you’d miss every other interval.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>