Such asynchronous requests may include asynchronous write, read, or lock requests (REQUEST_ASYNC_WRITE, REQUEST_ASYNC_READ, or REQUEST_ASYNC_LOCK, respectively).
The Microsoft Legacy IEEE 1394 stack may time out the asynchronous request even though the asynchronous response packet that matches a pending asynchronous request had been successfully received by the IEEE 1394 host controller into the asynchronous response received packet buffer. When this problem occurs, the matching asynchronous response packet is not the first of two or more unprocessed packets in the asynchronous response received packet buffer. This condition would typically occur if two or more asynchronous response packets are received in very quick succession.
Under various conditions (such as when a buffer boundary is crossed upon processing the first packet), the Microsoft Legacy OHCI 1394 host controller driver (Ohci1394.sys) may exit the asynchronous response handler DPC (Delayed Procedure Call) routine without processing all received packets. These received asynchronous response packets will not be processed by the asynchronous response handler until another asynchronous response packet is received by the host controller. If another asynchronous response is not received for more than 2.2 seconds after the original asynchronous request was transmitted, the original asynchronous request times out, while the matching asynchronous response packet remains unprocessed in the asynchronous response received packet buffer.
Note: 2.2 seconds is the timeout value used by the Microsoft Legacy IEEE 1394 stack for asynchronous requests.
- Ensure a minimum delay between back-to-back asynchronous response packets sent from the attached IEEE 1394 device, so that only one asynchronous response packet is received/processed per invocation of the Microsoft asynchronous response handler DPC.
This workaround would require a change in the behavior of the attached IEEE 1394 device that may not be possible to implement in all affected cases.
- Ensure a maximum delay between subsequent asynchronous response packets sent from the attached IEEE 1394 device, so that a subsequent invocation of the Microsoft asynchronous response handler DPC occurs to cause processing of previously-received asynchronous response packets before a pending Asynchronous Request times out.
This workaround would require a change in the behavior of the IEEE 1394 client driver for the attached IEEE 1394 device. Such a change could be implemented by setting a timer for each asynchronous request submitted to the Microsoft 1394 stack. The duration of such a timer would typically be a few hundred milliseconds. The timer would be cancelled when the asynchronous request is completed. If this timer expires, the IEEE 1394 client driver could submit an "inconsequential" asynchronous request (one that has no actual effect on the node) such as a Quadlet Read from a hardware address on the attached IEEE 1394 device. The returned data can be ignored, but the asynchronous request would cause an asynchronous response to be returned from the attached IEEE 1394 device, invoking the asynchronous response handler, and causing any previously-received asynchronous response packets to be processed from the asynchronous response received packet buffer.
This workaround should allow the previous asynchronous request to be completed with the proper matching asynchronous response packet.
This problem has not been reported to occur on the Microsoft IEEE 1394 stack for Windows 7 and later (KMDF-based).
For more information on asynchronous requests for IEEE 1394 devices, see the following topics in the Microsoft Windows Driver Kit (WDK) online documenation:
Sending Asynchronous I/O Request Packets on the IEEE 1394 Bus
REQUEST_ASYNC_WRITE Control Code
REQUEST_ASYNC_READ Control Code
REQUEST_ASYNC_LOCK Control Code
Raksta ID: 2519460. Pēdējo reizi pārskatīts: 2011. gada 18. marts. Pārskatījums: 1