Incorrect data received via Isochronous transfer from IEEE 1394 device on a computer with 4GB or more memory

Source: Microsoft Support

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.

When you are transferring Isochronous data from a device connected to an IEEE 1394 bus, the transferred data may appear to be incorrect (corrupted) or be received later than it was sent by the IEEE 1394 device.� The symptoms of this problem may appears as glitches in or repeated sections of audio or video streaming data.

This problem only occurs under the following conditions:

• The Isochronous data is received by a computer with at least 4GB of physical memory, or with physical memory located at physical addresses above 4GB.
• The computer is running a version of Windows that support more than 4GB of physical memory.

This problem does not occur on computers with physical memory located at physical addresses entirely below 4GB, or running a version of Windows that does not support more than 4GB of physical memory.

This problem may occur if the IEEE 1394 client driver that receives the Isochronous data transfer incorrectly accesses the buffers used to receive the transferred data.

This problem only occurs under the following conditions:

• The Isochronous data is received by a computer with at least 4GB of physical memory, or with physical memory located at physical addresses above 4GB.
• The computer is running a version of Windows that support more than 4GB of physical memory.

Under these conditions, Windows uses System Map Registers to translate (buffer) transfers to or from physical addresses above 4GB for Direct Memory Access (DMA) transfers performed by a 32-bit DMA controller, such as used in OHCI-compliant IEEE 1394 host controllers.�

If the buffer provided by the IEEE 1394 client driver for such transfers is located at a physical address above 4GB, Windows allocates an intermediate "bounce" buffer, located at a physical address below 4GB, that can be accessed by the 32-bit DMA controller.� Windows will copy the data between these buffers either before or after the DMA transfer is performed by the DMA controller (the IEEE 1394 host controller), depending on the direction of the transfer.� If data is being sent to the IEEE 1394 bus, the data is copied from the buffer provided by the IEEE 1394 client driver to the bounce buffer before the transfer is performed by the IEEE 1394 host controller.� If data is being received from the IEEE 1394 bus, the data is copied from the bounce buffer to the buffer provided by the IEEE 1394 client driver after the transfer is performed by the IEEE 1394 host controller.

If the buffer provided by the IEEE 1394 client driver to receive the transferred Isochronous data (described by the MDL field in the ISOCH_DESCRIPTOR for this buffer) is accessed before Windows has finalized the DMA transfer and copied the contents from the bounce buffer, the buffer provided by the IEEE 1394 client driver will not contain the correct data.� The DMA transfer is only finalized by the system during processing of a REQUEST_ISOCH_DETACH_BUFFERS request by the Microsoft IEEE 1394 driver stack.� The contents of the buffer described by the MDL field in the ISOCH_DESCRIPTOR cannot be assumed to be correct until the REQUEST_ISOCH_DETACH_BUFFERS request has completed.

To resolve this issue, IEEE 1394 client drivers performing Isochronous data transfers must not examine or process the buffer described by the MDL field in the ISOCH_DESCRIPTOR until that ISOCH_DESCRIPTOR has been detached from the Isochronous Resource by submitting a REQUEST_ISOCH_DETACH_BUFFERS request to the Microsoft IEEE 1394 driver stack and waiting for the REQUEST_ISOCH_DETACH_BUFFERS request to complete.� When control has been returned to the completion routine specified in the IRP used to submit the REQUEST_ISOCH_DETACH_BUFFERS request, the contents of the buffer can be assumed to be valid and examined or otherwise processed.

To work around this issue and avoid the use of intermediate "bounce" buffers altogether, an IEEE 1394 client driver may be able to allocate memory for its buffers at physical addresses below 4GB using the following approach:

1. Use the MmAllocateContiguousMemory routine to allocate a block of memory, specifying a HighestAcceptableAddress value of less than 4GB.
2. Divide this block of memory into individual buffers for Isochronous transfers, and create a MDL for each ISOCH_DESCRIPTOR to describe the portion of that block to be used for each transfer.

For more information, see:

Memory Limits for Windows Releases�http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
Map Registers�http://msdn.microsoft.com/en-us/library/ms796332.aspx
REQUEST_ISOCH_DETACH_BUFFERS�http://msdn.microsoft.com/en-us/library/ms789435.aspx
ISOCH_DESCRIPTOR�http://msdn.microsoft.com/en-us/library/ms789565.aspx

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE �MATERIALS�) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.