I allocate an irp and pass it to the lower driver, and the lower return STATUS_PENDING, then i let the thread wait for 50 senconds, if the irp is not completed(i means my completion routine gets invoked) by the lower beyond the timeout value, i cancel the irp, but it fails(even i call the IoCancelIrp(),my completion routine doesn’t gets invoked, when the irp was pending), the reason seems to be that the lower driver don’t supply a cancel routine for the irp that it returns with pending status. Is it proper that a lower driver returns pending status without supplying a cancel routine for the irp? If it is, how terrible the system is! The irp my driver allocated sometimes was pending forever(remember, just sometimes), but i can’t cancel it, then the system was pending!!! The lower drivers here reference to 1394bus.sys, ohci1394.sys and sbp2port.sys.
activism@163.com wrote:
I allocate an irp and pass it to the lower driver, and the lower return STATUS_PENDING, then i let the thread wait for 50 senconds, if the irp is not completed(i means my completion routine gets invoked) by the lower beyond the timeout value, i cancel the irp, but it fails(even i call the IoCancelIrp(),my completion routine doesn’t gets invoked, when the irp was pending), the reason seems to be that the lower driver don’t supply a cancel routine for the irp that it returns with pending status. Is it proper that a lower driver returns pending status without supplying a cancel routine for the irp? If it is, how terrible the system is!
Yes. A cancel request is just a polite request. A lower driver is not
required to honor it. Every good driver WILL handle a cancel request
for an IRP that might take more than a few seconds, but they are not
required to do so.
You’re talking about a 1394 device. The USB host controller has a URB
that causes all requests for a given pipe to be canceled. Do the 1394
host controllers have the same concept?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, thank you very much.
To be honesty, i know just a little about 1394 host controller. For we are only developing the window driver for the device ,we know the data format that the device defined, and we fill cdb member in srb and so on, then pass the irp to the lower. That’s all. Then i will try to find is there any way to do like usb host controller, thanks a again for your suggestion. But i have a question that i think that is very important.
When you according to the ddk, must do this, should do that, at last, problem encountered, then, what your way to solve the problem?
e.g, in this development, we found the driver that microsoft suplied(lower driver) return STATUS_PENDING from iocalldriver, but it can not be canceled, the completion routine for the irp never got invoked. It takes me a lot of time to fix the problem, even so far, i have not found the solution. If i have the source of the lower driver, i promise i fix the problem use much little time:)…