Next | Prev | Up | Top | Contents | Index

Memory Parity Workarounds

If you are writing a GIO device driver for Indigo R4000, Indigo2, POWER Indigo2, or Indy systems, please make note of the following changes introduced in IRIX 5.3 (or IRIX 5.2 with Patch4, the Memory Parity Patch).

Beginning with IRIX 5.3, parity checking is enabled on the SysAD bus (see Figure 6-1). Unfortunately, with certain GIO cards, errors can occur if memory reads complete before the Memory Controller (MC) finishes calculating parity.

Figure 6-1 : The SysAD Bus in Context Some GIO cards do not drive all 32 GIO data lines during CPU PIO reads. These reads from the GIO card are either 8-bit (byte) or 16-bit (short word), so the lines are left floating. The problem is that to generate parity bits for the SysAD bus, the Memory Controller (MC) must calculate parity for all 32 bits. Since the calculation must occur before the CPU read completes, it is possible that one (or more) of the floating bits may change while parity is being calculated. Thus, when the CPU read completes, it may receive a parity error on the SysAD bus.

Caution: Even on GIO boards that do not drive all data lines, this problem may not show up on every transaction. It occurs only when one of the floating data lines changes state between the start of the MC parity calculation and the completion of the CPU read. Even if a driver appears to function correctly, the system may panic due to a parity error. If you are writing a driver for a GIO card that does not drive all 32 data lines, even when fewer bits are being read, you must either:

  1. Disable SysAD parity checking completely.
    This reduces the system's ability to recover from a parity error in main memory, but it is both reliable and easy to program. The way to implement this is simply to put a call to disable_sysad_parity() at the beginning of your driver's init (or edtinit) routine before the driver attempts any PIO reads from the GIO device.

  2. Disable SysAD parity checking only when your driver is actually performing PIOs.
    The advantage here is that the software recovery procedures for memory parity errors are almost always in effect, but it requires a bit more work during driver development. Put wrappers around your driver's PIO transactions to disable SysAD parity checking before the transactions and re-enable it after the PIOs complete, as in the following code fragment:

    {

    int was_enabled = is_sysad_parity_enabled();

    if (was_enabled)

    disable_sysad_parity();

    /* do driver PIO transactions */

    if (was_enabled)

    enable_sysad_parity();

    }



Next | Prev | Up | Top | Contents | Index