I have a driver which takes a single OnRead request via a sequential queue and stores it for later, in its place the driver creates several new read requests which are sent down to the USB input pipe (bulk endpoint).
I have the OnCompletion handler for the sent requests buffer the received data as each requests completes (in whatever order windows chooses) and once all requests (using a counter) have completed, the original read request is CompletedWithInformation.
This setup appears to be working however I am unsure how to deal with error handling. For example, assume 5 new requests are created and sent down the pipe, request 1 completes without error then request 2 completes with an error status.
Requests 3,4 and 5 are either still pending at the host controller (using RAW_IO) or have been serviced and the OnCompletion just hasn’t occurred. What happens to 3-5 if they were still pending at the time request 2 completed with error, for example assume the endpoint goes into an error state? Do they immediately complete with error, or will they sit waiting for the error condition to clear up until a timeout?
In either case, how should the driver handle this?
*) Wait for requests 3-5 to also complete (with/without error) and then complete the original request with an error and perform a pipe abort/reset?
*) Or, Complete the original request with error as soon as 2 came in and attempt to have the pipe abort/reset (to try to cancel req 3-5) followed by ignoring req 3-5 if they happen to have already been serviced before the pipe reset but yet to have their OnCompletion callback?
*) A saner approach that is eluding me at this time? Advice more than welcome.
Is there a callback available for requests that have been sent down to the host controller but subsequently cancelled due to a pipe abort/reset? Or would those still have an OnCompletion callback but with an error to signify cancellation?
It is really up to you. the semantics your driver exposes is yours to define. When I have had this problem I keep the app request completion logic the same in the case of success or failure, waiting for all sent requests to complete first. In the error case, I would cancel the sent requests to make sure they come back expediently
From: xxxxx@figmentgames.com Sent: Thursday, October 8, 2015 7:32 AM To: Windows System Software Devs Interest List Subject: [ntdev] USB endpoint completion error handling.
Hi,
I have a driver which takes a single OnRead request via a sequential queue and stores it for later, in its place the driver creates several new read requests which are sent down to the USB input pipe (bulk endpoint).
I have the OnCompletion handler for the sent requests buffer the received data as each requests completes (in whatever order windows chooses) and once all requests (using a counter) have completed, the original read request is CompletedWithInformation.
This setup appears to be working however I am unsure how to deal with error handling. For example, assume 5 new requests are created and sent down the pipe, request 1 completes without error then request 2 completes with an error status.
Requests 3,4 and 5 are either still pending at the host controller (using RAW_IO) or have been serviced and the OnCompletion just hasn’t occurred. What happens to 3-5 if they were still pending at the time request 2 completed with error, for example assume the endpoint goes into an error state? Do they immediately complete with error, or will they sit waiting for the error condition to clear up until a timeout?
In either case, how should the driver handle this?
) Wait for requests 3-5 to also complete (with/without error) and then complete the original request with an error and perform a pipe abort/reset?
) Or, Complete the original request with error as soon as 2 came in and attempt to have the pipe abort/reset (to try to cancel req 3-5) followed by ignoring req 3-5 if they happen to have already been serviced before the pipe reset but yet to have their OnCompletion callback?
*) A saner approach that is eluding me at this time? Advice more than welcome.
Is there a callback available for requests that have been sent down to the host controller but subsequently cancelled due to a pipe abort/reset? Or would those still have an OnCompletion callback but with an error to signify cancellation?