Problem with USB2 under Win2K

Hi everybody,

I develop a driver for an USB device that is capable of operating at both
full and high speed. I tested it under WinXP and Win2K at both high and
full speed and found a problem when running under Win2K at high speed.

Requests to device are sent as MJ_DEVICE_CONTROL Irp’s. Each request is
executed as an USB Out operation on one Bulk pipe followed by an In
operation on another Bulk pipe. The device can only deliver something on
the IN pipe after it has received something on the OUT pipe.

For performance reasons the driver first submits the In Urb asynchronously
using the original Irp and setting a completion routine. Then the Out Urb
is executed synchronously using a dedicated Irp created by
IoBuildDeviceIoControlRequest. After that the original Irp is marked
pending and the dispatch routine returns STATUS_PENDING. The processing
of original Irp is then completed in the completion routine.

I figured out that the problem under Win2K shows up only when the next Irp
arrives /before/ the previous one is completed. When this happens the
second IN Urb is submitted and the second OUT Urb is executed before the
first one is processed. As the result both the first and the second Bulk
In Urb’s never get completed by the underlying driver. This does not
cause any problems in full speed mode and under WinXP in high speed mode.

Does anybody knows this problem and if yes are there any workarounds
(besides of serializing Irp processing?) Alternatively, what could be
wrong with my driver?

Regards,
– Pavel

xxxxx@dmt.de wrote:

Does anybody knows this problem and if yes are there any workarounds
(besides of serializing Irp processing?) Alternatively, what could be
wrong with my driver?

I think you simply have to serialize the incoming IRPs. From your
description, it sounds like doing IRPs in order is a logical necessity
imposed by the hardware.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

Walter Oney wrote:

xxxxx@dmt.de wrote:

>Does anybody knows this problem and if yes are there any workarounds
>(besides of serializing Irp processing?) Alternatively, what could be
>wrong with my driver?
>

I think you simply have to serialize the incoming IRPs. From your
description, it sounds like doing IRPs in order is a logical necessity
imposed by the hardware.

Yes and no. The firmware processes requests sequentially.
However, it is capable of receiving the next request while
processing the current one. Therefore when processing a
sequence of requests, the driver only has to ensure that the
order of IN transactions match the order of the
corresponding OUT transactions. In other words, only
operations on the same pipe have to be serialized.

OTOH, since performace is an issue I want to push this
serialization as close to the hardware as possible. Only if
there is absolutely no other choice I would serialize
request processing in the driver.

Regards,
– Pavel