3 ratings:

4.33 out of 5

Rate this Document

Why am I Getting "PCI-MXI-2 Error -1073807298 or System Hang" with VXI?

Hardware: VXI/VME/MXI>>MXI Interfaces>>PCI-MXI-2

Problem:
Why am I getting the error "PCI-MXI-2 Error -1073807298 or a System Hang" with VXI?

Solution:
The lock-up behavior is exposed when both a VXI block move and VXI single-cycle accesses are attempted simultaneously, creating a deadlock. This lock-up behavior occurs randomly and may never occur on some test systems. If the problem is observed, the steps listed below can be taken to avoid it.

The problem is exposed by a chip called the "MITE" PCI communication chip changing from revision A to revision B to follow PCI specification changes. The older revision A MITE would issue a retry command a maximum of 64 times. After 64 attempts, the PCI-MXI-2 would timeout and discard the block move in progress. This resolved the deadlock situation described above. Typically the block move will return the error -1073807298 or 0xBFFF003E with the message “Could not perform operation because of I/O error.”

The newer rev. B MITE was updated to follow the PCI specification requiring continual retries. This exposed a potential deadlock between the SyncMXI and PCI protocols.


There are two methods to fix the issue:

1. Remove or Replace Single-Cycle Access Functions with Block Moves
   
   If your VXI/VME system can be changed so that single-cycle accesses are removed or replaced with block moves this issue will not occur. For example, single-cycle accesses (i.e. peek/poke or viIn/viOut) would be replaced with block moves (i.e. viMoveIn/viMoveOut)
   
   
2. Disable SyncMXI
   
   The permanent resolution of the problem is achieved by disabling use of the SyncMXI protocol during block moves. Disabling the SyncMXI protocol results in a slower protocol during block moves. While the overall maximum speed of data transfers on the MXI bus is reduced, the deadlock is prevented because the slower protocol does not completely lock down the MXI bus during block moves.
   
   The SyncMXI protocol can be disabled either in your software by using an unexposed attribute in NI-VISA or by changing a registry key in Windows:
   
   
   Disable SyncMXI with a NI-VISA Attribute:
   
   In standard C notation, the SyncMXI protocol can be disabled for any VISA session for a VXI/VME device using the function call: viSetAttribute (viSession, 0x3FFF0161, 0x0). In LabVIEW the same function can be called using a call library node into the visa32.dll. Refer to the example program attached below to see how to use a call library node to make the same call in LabVIEW to disable SyncMXI.
   
   Note: This attribute must be set on a per session basis for any VXI session where block move transfers will be used. VISA sessions using only standard register accesses or the word serial protocol do not need to be changed since SyncMXI is not used for those protocols. The attribute only needs to be set once per VISA session and the setting will persist for multiple block moves. The code changes are compatible with older versions of the PCI-MXI-2 containing the rev. A MITE and newer versions of the PCI-MXI-2 containing the rev. B MITE.
   
   Disable SyncMXI by Changing a Registry Key in Windows:
   
   This method will only work on systems with NI-VXI 3.3 or higher for Windows. To disable SyncMXI from the registry, follow these steps:
   
   Note: We recommend that you backup your registry before attempting to edit it. If possible, use solution 1.
   
   
   1. Open the registry editor at Start >> Run and type "regedit."
   
   
   2. Go to the location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXI\
   
   
   3. At that location, you will see several subfolders named board0, board1, etc. If you only have one VXI device, expect to see only board0.
   
   
   4. Highlight the "board" folder that applies to your MXI-2 card (not the folder named "PCI-MXI-2", but the one named "board0" for example). On the right window pane, you will see many keys that can be adjusted. Change the value of the key "UseSyncMXI" from 0x1 to 0x0 by double clicking on the key.
   
   
   This will disable SyncMXI for all devices behind that MXI-2 bridge. Note that if you have more than one board folder showing up, i.e. board0 and board1, you can remove your other MXI boards from the system to determine which board maps to which registry entry. You can then disable the SyncMXI for the board that remains. You could also change the UseSyncMXI keys to 0x0 for every system in the registry.

Expansion on Why the Deadlock Occurs:

When a block move (or viMoveIn/viMoveOut) is in progress, the MXI bus is locked down to maximize speed using the SyncMXI protocol. The MXI bus cannot be co-opted by any other type of access at this time. If single-cycle access, a peek/poke (or viIn/viOut) command to the VXI/VME bus is attempted by the host before the block move completes (for example, attempting to send a VXI/VME word serial command), the command will attempt to complete, fail because the MXI bus is locked down for the already in progress block move, and continuously retry.

The single-cycle command blocks further access to the PCI bus by the PCI-MXI-2 preventing completion of the block move. Meanwhile, the single-cycle command is being blocked by the locked-down MXI bus block move in progress. Since each command is waiting on the other to complete, a deadlock situation occurs. The limited retries in the rev A MITE eventually stopped this deadlock by not retrying indefinitely. When the MITE rev A stops retrying, this could cause an error to be returned from transfers that were actually successful, but does avoid a perpetual deadlock.

Related Links:
Product Manuals: Getting Started with Your PC-Based MXI-2 Interface for Windows

Attachments:





Report Date: 05/25/2004
Last Updated: 04/28/2006
Document ID: 39OA8QJT

Your Feedback!	Poor  |  Excellent							Yes	No
Document Quality?							Answered Your Question?
	1	2	3	4	5
Document needs work? Please tell us why.
Please Contact NI for all product and support inquiries.