IEEE 1394 Asynchronous Request May Time Out Due to Dropped Response from Remote Node

When an IEEE 1394 device is connected to a computer running Windows and asynchronous data transfers are being performed between the host computer and the device, an asynchronous data transfer requested by the host computer may complete with an error status of 0xC00000B5 (STATUS_IO_TIMEOUT). The asynchronous request may time out even though an IEEE 1394 bus trace shows that a valid asynchronous response was received from the device and successfully acknowledged by the host computer with an "ack_complete" code.

Such asynchronous requests may include asynchronous write, read, or lock requests (REQUEST_ASYNC_WRITE, REQUEST_ASYNC_READ, or REQUEST_ASYNC_LOCK, respectively).

This problem is caused by a problem in the Microsoft IEEE 1394 stack for Windows XP (also known as the Microsoft Legacy IEEE 1394 stack).

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.

It may be possible to work around this problem by one or both of the following methods:

1. 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.
2. 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 been confirmed to occur on Microsoft Windows XP. However, it is also expected to occur on Windows Server 2003, Windows Vista, and Windows Server 2008, all of which use the Microsoft Legacy IEEE 1394 stack (WDM-based).

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 (http://msdn.microsoft.com/en-us/library/ff538087(VS.85).aspx)
REQUEST_ASYNC_WRITE Control Code (http://msdn.microsoft.com/en-us/library/ff537636(VS.85).aspx)
REQUEST_ASYNC_READ Control Code (http://msdn.microsoft.com/en-us/library/ff537634(VS.85).aspx)
REQUEST_ASYNC_LOCK Control Code (http://msdn.microsoft.com/en-us/library/ff537633(VS.85).aspx)

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.