Filter
Top Products
Data Integrity and Error Handling
6-26 Intel® 460GX Chipset Software Developer’s Manual
6.12 WXB Data Integrity and Error Handling
6.12.1 Integrity
Error handling in the context of a chipset component requires observing the error, containing it,
notifying the system, and recovery or system restart. Different platforms have different
requirements for error handling. A server is generally most interested in containment. It attempts to
stop bad data before it reaches the network or the disk. On the other hand, workstations with
graphics may be less interested in containment. If the screen blips for one frame and the blip is
gone in the next frame, the error is transient and may not even be noticed.
The WXB accommodates both philosophies by allowing certain errors to be masked off
completely, or by turning them into simple interrupts instead of signalling SERR# or XBINIT#.
Certain errors can only be directed to cause an XBINIT#.
In general the WXB will report errors upon their observation. In the case of data parity errors on
data transiting the WXB, however, the reporting can be deferred until the data is actually used. In
the case of data heading inbound to memory, this could result in deferring the reporting of the error
until it is read from memory or completely if the data is never used.
6.12.2 Data Parity Poisoning
When data is received by the WXB that is in error, it will be passed on to the next interface with
bad (or “poisoned”) parity. Data received over the PCI bus that has bad parity will always be sent
on to the chipset core with bad parity.
Note: There is no mode in the WXB to forward good parity if the data was received as bad. If the data
comes in with bad parity it is always
sent out with bad parity.
Note: When addressed to the IHPC, outbound writes containing data with bad parity will be “dropped on
the floor.”
6.12.3 Usage of First Error and Next Error Registers
When an error is identified, and it is the first occurrence of an error, it is latched into the “First
Error” register (see FEPCI register). If an error has been previously identified (and not cleared),
the associated First Error bits will already be set. In such a case, subsequent errors of any type will
be recorded through “Next Error” registers.
Since the system really only needs to know if just one error has occurred or many, setting a First
Error bit does not affect the Next Error bits. If there is another error of any type, including a second
occurrence of the first error, then the appropriate Next Error bit is set. Software can read both First
Error and Next Error registers to determine a complete error status.
In general, as much information as possible is logged for the first error encountered; data, address,
and/or command information are captured if available. This allows better isolation of errors and
possible recovery.
Note: Multiple errors occurring in (nearly) the same cycle may result in multiple bits being set in the First
Error register.