I have an USB 2.0 device which endpoints specify transfer interval of 4
micro-frames, ie 2 packets per ms. With Microsoft EHCI driver, the USB
transfers always resulted in the 2nd packet length being zero, although when
examined, there is actually valid data in it. This bug can be reproduced
consistently, across different system & different EHCI chipset.

Is this a known issue ? If so, is there a HotFix that can be applied to fix
this bug ? If a HotFix is not yet available, when can it be expected ? Which
OS (Windows Vista, Server 2003, XP, 2000) is the fix going to be available ?

Thanks.

-Hock

<px123> wrote:
We have not seen that behavior. Do your URBs each have an even number of
packets? Each URB must hold enough packets to handle an entire frame. Is
there an error code in the 2nd packet?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Yes, each of the URBs have 2 packets to handle an entire frame. There is no
errors in the 2nd packet status.

I found a previous post (USB stack gives misleading indications when polling
Interval not 1) in this newsgroup that explains a similar problem in more
details.

http://groups.google.com/group/micro...9b3cacf4a25392

and this Microsoft KB article (High-speed periodic USB isochronous transfers
with periods of 2 or 4 do not work correctly):
http://support.microsoft.com/?kbid=837371.

Looks like it is a bug in Microsoft EHCI driver.

Question for Microsoft guys: Is there any plan to fix this in a
HotFix/Service Pack for OSes other than Vista ?

Without the fix, it may be impossible to design an USB 2.0 device that would
work on Vista and the older Windows OSes, particularly when Device
Class-compliancy is a requirement. Some devices do need this kind of
transfers (polling interval 2 or 4 micro-frames) to achieve the required
transfer bandwidth. Also the device processing capabilities might limit the
use of polling interval of 1 micro-frames, so it is not always the case
that the bug can be workaround by changing the polling interval to meet the
EHCI driver limitation.

The consequences is an USB device designed to meet USB/Device Class
requirements may only work in Vista if this fix is not propagated down to
the older OSes. Given support for older OSes is still a requirement for a
lot of products (for the time being), Device Class compliancy is usually
sacrificed in order to support these OSes. The hardware vendor then has to
write & maintain custom drivers instead of using Microsoft's class drivers.
The USB device would not work in Vista without the vendor specific drivers.

I hope that Microsoft would consider fixing the EHCI driver in the older
OSes as it would be beneficial to everyone: developers & end-users.

Thanks.

-Hock

"Tim Roberts" <timr@probo.com> wrote in message
news:nr84a2di3nuohmjkbs09vig9e2cf24mvof@4ax.com...