none
Timeout support in usb vendor request RRS feed

  • Question

  • Hi,

    Currently we have USB vendor request support in our own driver. This vendor request remains in blocking mode until device responds. We want to add timeout feature such that request returns on timeout value if device does not respond.

    We are using _URB_CONTROL_VENDOR_CLASS_REQUEST data structure to build vendor request URB.

    Regards,

    Shafin Vahora

    Software Engineer,

    System Level Solutions(India) Pvt. Ltd.

    Thursday, May 23, 2019 9:44 AM

Answers

  • The timeout is not built into the urb. Rather, your wait for the urb to complete needs to specify the timeout. When the wait times out , you must cancel the urb with IoCancelRequest. Then you must wait indefinitely until the request completes. The same can be done in wdf, but wdf also allows you to specify the timeout when sending the request.

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

    Thursday, May 23, 2019 2:26 PM

All replies

  • The timeout is not built into the urb. Rather, your wait for the urb to complete needs to specify the timeout. When the wait times out , you must cancel the urb with IoCancelRequest. Then you must wait indefinitely until the request completes. The same can be done in wdf, but wdf also allows you to specify the timeout when sending the request.

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

    Thursday, May 23, 2019 2:26 PM
  • Thank You so much for your prompt response.

    Can _URB_CONTROL_TRANSFER_EX structure be used to send vendor request as it provides timeout parameter in it.

    We have one more question. As we see in Intel(R) USB 3.0 eXtensible Host Controller prior to 2016, control transfer automatically times out after 10 sec but in later version it doesn't time out.

    Here are details of host controller which timeouts automatically.

       

    Hardware IDs : PCI\VEN_8086&DEV_8C31&SUBSYS_06121028&REV_04                              PCI\VEN_8086&DEV_8C31&SUBSYS_06121028 PCI\VEN_8086&DEV_8C31&CC_0C0330 
    PCI\VEN_8086&DEV_8C31&CC_0C03

    Version: 2.5.4.40  Date: 2014-04-11

    Hardware IDs : PCI\VEN_8086&DEV_A12F&SUBSYS_079B1028&REV_31 PCI\VEN_8086&DEV_A12F&SUBSYS_079B1028 PCI\VEN_8086&DEV_A12F&CC_0C0330
    PCI\VEN_8086&DEV_A12F&CC_0C03

    Version: 4.0.6.60  Date: 2016-06-20

    Tuesday, May 28, 2019 7:03 AM
  • Yes, you can use _URB_CONTROL_TRANSFER_EX as long as you don't need to support anything older than Vista.

    If Intel added a 10-second control transfer timeout to their XHCI controller, that was their own extension.  It's not part of the USB 3 spec, and you should not rely on it.  Do it the RIGHT way.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Tuesday, May 28, 2019 6:46 PM
  • Thank You.

    I did research in wdm driver api and tried to modify an argument of timeout in KeWaitForSingleObject() function but on build it gives me an error.

    My code:

       ntStatus = IoCallDriver(deviceExtension->TopOfStackDeviceObject, irp);

        if(ntStatus == STATUS_PENDING) {

            KeWaitForSingleObject(&event,
                                  Executive,
                                  KernelMode,
                                  FALSE,
    line no 1891            5000); --> if write this or any value except 0 it gives error on build.

            ntStatus = ioStatus.Status;
        }

    Error:

    bulkpnp.c(1891) : error C2220: warning treated as error - no 'object' file generated Linking Executable - objfre_win7_amd64\amd64\slsusb.sys

    If set timeout value to 0, it doesn't return. What should i specify?

    For more info of KeWaitForSingleObject : https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-kewaitforsingleobject

    Wednesday, May 29, 2019 11:22 AM
  • The timeout is not built into the urb. Rather, your wait for the urb to complete needs to specify the timeout. When the wait times out , you must cancel the urb with IoCancelRequest. Then you must wait indefinitely until the request completes. The same can be done in wdf, but wdf also allows you to specify the timeout when sending the request.

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

    Hi,

    We have tried with wdf, changed timeout parameter from 0 to 5000 and checked that application returns with error in IO operation as device is not sending any data. If timeout value is 0 then application remains in hang state as defined in https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdfrequest/ns-wdfrequest-_wdf_request_send_options

    How this timeout value can be set as per documentation? What other values are?

    I also set DEFAULT_CONTROL_TRANSFER_TIMEOUT value but returns an error: 

    slsusb_devcntrl.c(558) : error C2065: 'DEFAULT_CONTROL_TRANSFER_TIMEOUT' : undeclared identifier
    Wednesday, May 29, 2019 11:41 AM
  • If set timeout value to 0, it doesn't return. What should i specify?

    "If the caller supplies a NULL pointer, the routine waits indefinitely "

    Use a pointer (PLARGE_INTEGER) to negative value for timeout, as documented here.

    -- pa



    • Edited by Pavel A Wednesday, May 29, 2019 7:12 PM
    Wednesday, May 29, 2019 7:09 PM
  • If set timeout value to 0, it doesn't return. What should i specify?

    "If the caller supplies a NULL pointer, the routine waits indefinitely "

    Use a pointer (PLARGE_INTEGER) to negative value for timeout, as documented here.

    -- pa



    Thanks.

    I have added timeout parameter as per suggested and doing research.

    I set this value in KeWaitForSingleObject() but results in blue screen error with "IRQL_NOT_LESS_OR_EQUAL" error.

    liTimeout.LowPart = 400000;
    liTimeout.HighPart = 0;

    Is any parameter value mismatch or need some different value?

    Thursday, May 30, 2019 11:50 AM
  • You still use a positive value for the timeout. Also, check that you are below DISPATCH IRQL when calling KeWaitForSingleObject.

    -- pa

    Thursday, May 30, 2019 12:24 PM