Typical Isoch or Interrupt end points require a client driver to continuously reissue i/o requests unless some exception occurs. The driver cannot decide to exit based on all error conditions – many error conditions can occur at runtime and the driver is expected to recover from them.
Isoch sample from DDK uses the following to conditions for exit, otherwise it recycles the irps.
STATUS_CANCELLED or STATUS_DEVICE_NOT_CONNECTED
In my experience I’ve found out that I need to extend the list to
STATUS_CANCELLED or STATUS_DEVICE_NOT_CONNECTED or STATUS_DELETE_PENDING
Failing to stop the i/o under any of these conditions results in a system crash.
But this does not make me anymore confident that I’m covering all cases. Finally my question is if Calling IoAcquireRemoveLock is the preferred method for covering all cases.
regards,
m navab
xxxxx@yahoo.com wrote:
Typical Isoch or Interrupt end points require a client driver to continuously reissue i/o requests unless some exception occurs. The driver cannot decide to exit based on all error conditions – many error conditions can occur at runtime and the driver is expected to recover from them.
Isoch sample from DDK uses the following to conditions for exit, otherwise it recycles the irps.
STATUS_CANCELLED or STATUS_DEVICE_NOT_CONNECTED
In my experience I’ve found out that I need to extend the list to
STATUS_CANCELLED or STATUS_DEVICE_NOT_CONNECTED or STATUS_DELETE_PENDING
Failing to stop the i/o under any of these conditions results in a system crash.
You shouldn’t need to check for STATUS_DELETE_PENDING if you handle
IRP_MJ_CLEANUP correctly. Under what circumstances do you see it?
I look for three conditions to stop recycling:
Irp->Cancel (which is equivalent to Status == STATUS_CANCELLED),
Irp->IoStatus.Status == STATUS_DEVICE_NOT_CONNECTED,
!USBD_SUCCESS(Urb->UrbHeader.Status) (but not for
USBD_STATUS_ISOCH_REQUEST_FAILED)
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My driver, although purely wdm, works similar to a network driver. It gets unsolicited packets that it indicates up the driver chain thru a registered callback. No module sends a create or cleanup to my driver. All of these concerns have to do with surprise removal (cable yank) of a continously streaming isoch/interrupt device.
xxxxx@yahoo.com wrote:
My driver, although purely wdm, works similar to a network driver. It gets unsolicited packets that it indicates up the driver chain thru a registered callback. No module sends a create or cleanup to my driver. All of these concerns have to do with surprise removal (cable yank) of a continously streaming isoch/interrupt device.
But these are all IRPs you are creating. You said YOU were deciding
whether to resubmit the URBs. The only way you should see
STATUS_DELETE_PENDING is if you submit an URB after you have already
acknowledged a removal or surprise removal request. As long as you set
a flag in your query_remove handler, and then don’t submit any new URBs
after that, you should never see this status.
Now, the reality is that we’re only talking about 3 extra instructions,
but it just led me to wondering whether there was something missing in
your removal handling.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.