Data Integrity and Error Handling

6.12.5.2XBINIT# Generation

A certain subset of errors within the WXB will always result in the WXB attempting to signal an XBINIT#. Whenever an error occurs that forces an XBINIT#, an internal “override” bit is set as XBINIT# is driven to the bus. While the override bit is set, XBINIT# will no longer be reasserted, even for qualifying errors. This prevents the presence of a single error from causing XBINIT# to be signaled multiple times. Software may also set the override bit and thus prevent XBINIT# from occurring at all. When an XBINIT# is signaled, software should (1) clean up the error, (2) record and clear the error status registers, and (only) then, (3) clear the XBINIT# override bit so that new errors may be signaled. The override bit is always set on a Power Good reset.

Anytime an XBINIT# is signaled by the WXB, the “XBINIT Asserted” bit in the ERRSTS register will be set. Clearing this bit will cause the deassertion of the XBINIT# pin.

Errors that can be caused to signal an SERR# can also be caused to signal an XBINIT# (refer to the “XBINIT Escalation” bit within the ERRCMD register in Section 2).

6.12.6INTRQ# Interrupt

The WXB has an internal mechanism to cause a level interrupt under various error conditions. The signaling of this INTRQ interrupt is directly visible through the INTRQ# pin.

An INTRQ interrupt would generally be an expected outcome anytime that a “less serious” error has occurred. The INTRQ# signal is held asserted as long as the record of the error persists. All the errors that cause such an event are wired together to drive the internal signal. Software is expected to reset the bit causing the interrupt in the First Error or Next Error register where the error is recorded. In addition, software is expected to then clear the “INTRQ Asserted” bit in the ERRSTS register. When this bit is reset, INTRQ# will be deasserted unless there is another error which holds the signal active.

It is possible to configure the WXB to cause all errors to result in an INTRQ# interrupt1. In this way there is some flexibility to have a soft response (i.e. interrupt) for all errors as well as a more harsh response for specific “more serious” errors.

6.12.7Error Determination and Logging

The various error status registers identify which error(s) have occurred. In certain cases key information is logged in conjunction with the error status being set. For example, parity errors log the data and parity for the failing transfer if it is the first error occurrence. Other errors capture the address associated with the particular failure. This information can be used for debug and diagnostic purposes and may be used in system recovery. For instance, if there is an parity error on a data read, and the access can be isolated, instead of restarting the whole system it might be possible to kill only the failing process and allow other users to continue running.

The error log registers are updated at virtually the same time that the associated bit is set in the status register.

1.The single exception to this rule is Hard Fail Completion which will not initiate any sideband error signal (INTRQ#, SERR# or XBINIT#). However, an in-band PCI Target Abort will occur as a result of a Hard Fail Completion.

Intel® 460GX Chipset Software Developer’s Manual

6-29