none
Request Cancellation RRS feed

  • Question

  • I am trying to virtualize a composite USB device using a KMDF bus driver on Win 10. The bus driver emulates PnP and the response to each request is obtained from the real device over network. When a request arrives, the bus driver queues the request to a manual queue and when the response comes from the real device, the request is fetched from the manual queue and completed. But it is noted that when the response takes time to arrive from the network, the request on the manual queue is cancelled. I have just overridden EvtIOCancelledOnQueue for manual queue to verify and not implemented any cancellation/competition. Also it is noted on kernel debugger that the USBCCGP::CallDriverSync timed out after 5000 ms. So when the bus driver tries to fetch the request from queue, it is no longer there. How can this be handled? I found one or two similar posts but in a different context. In my case , the request/response process comes to a halt preventing the device from being configured.

    1. If we cancel or complete the request in EvtIOCancelledOnQueue() then is that OK? Wont request will still remain not completed since we have not set the response?

    2. If we cancel/complete the request in above manner, will the USB stack raise the same request again hoping for completion with actual response?

    3. If this timeout value default for USBCCGP? Should the request be necessarily completed before 5 secs?

    Tuesday, July 26, 2016 1:00 PM

Answers

  • 1) you can choose to defer completion if you believe you will be able to complete the request in a reasonable amount of time

    2) no, I don't think there is a retry. on a wired bus, why would a request fail and then succeed the second time?

    3) it is the implementation. on a wired bus, a response of 5sec is overly generous.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 26, 2016 5:38 PM

All replies

  • 1) you can choose to defer completion if you believe you will be able to complete the request in a reasonable amount of time

    2) no, I don't think there is a retry. on a wired bus, why would a request fail and then succeed the second time?

    3) it is the implementation. on a wired bus, a response of 5sec is overly generous.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 26, 2016 5:38 PM
  • Thank you Doron.
    Tuesday, July 26, 2016 5:50 PM
  • I went through deferring request completion scenario. As I mentioned, in my case when a request comes at PDO level in my KMDF bus driver from USBCCGP, it is forwarded to a manual queue in the FDO. When the response comes, the request is fetched from this manual queue and completed. I have a few doubts:

    1. In this scenarion, it is OK to use a time DPC as mentioned here so that the request is completed at that timer interval?

    2. Is it OK to call WdfRequestUnmarkCancelable() on the request before it is forwarded to the manual queue? Will this prevent the request from being cancelled on the manual queue so that the request need not be deferred??

    3. Another similar suggestion I found is about storing the request in a WDFCollection instead of a manual queue . Even if we store the request in a collection, isnt that still cancellable by the framework?


    Wednesday, July 27, 2016 8:24 PM