Filter
Top Products
Intel® 460GX Chipset Software Developer’s Manual 6-29
Data Integrity and Error Handling
6.12.5.2 XBINIT# 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.6 INTRQ# 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# interrupt
1
. 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.7 Error 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.