Baseline Error Detection and Handling

This section defines the required support for detecting and reporting PCI Express errors. Each PCI Express compliant devices must include:

• PCI-Compatible support — required to support operating environments that have no knowledge of PCI Express.

• PCI Express Error reporting — available to operating environments that do have knowledge of PCI Express.

PCI-Compatible Error Reporting Mechanisms

Each PCI Express must map required PCI Express error support to the PCI-related error registers. This involves enabling error reporting and setting status bits that can be read by PCI-compliant software. To understand the features available from the PCI-compatible point of view consider the error-related bits of the Command and Status registers located within the Configuration header. While the command and status register bits have the PCI name, some of the field definitions have been modified to reflect the related PCI Express error conditions and reporting mechanisms. The PCI Express errors tracked by the PCI-compatible registers are:

• Transaction Poisoning/Error Forwarding (optional)

• Completer Abort (CA) detected by a completer

• Unrecognizable Request (UR) detected by a completer

The PCI mechanism for reporting errors is the assertion of PERR# (data parity errors) and SERR# (unrecoverable errors). The PCI Express mechanisms for reporting these events are via the split transaction mechanism (transaction completions) and virtual SERR# signaling via error messages.

Configuration Command and Status Registers

Figure 10-6 illustrates the command register and the location of the error-related fields. These bits are set to enable baseline error reporting under control of PCI-compatible software. Table 10-3 defines the specific effects of each bit.

Table 10-3. Error-Related Command Register Bits

Name	Description
SERR# Enable	Setting this bit (1) enables the generation of the appropriate PCI Express error messages to the Root Complex. Error messages are sent by the device that has detected either a fatal or non-fatal error.
Parity Error Response	This bit enables poisoned TLP reporting. This error is typically reported as an Unsupported Request (UR) and may also result in a non-fatal error message if SERR# enable=1b. Note that reporting in some cases is device-specific.

Figure 10-7 illustrates the configuration status register and the location of the error-related bit fields. Table 10-4 on page 374 defines the circumstances under which each bit is set and the actions taken by the device when error reporting is enabled.

Table 10-4. Description of PCI-Compatible Status Register Bits for Reporting Errors

Error-Related Bit	Description
Detected Parity Error	Set by the interface that receives a Write Request or Read Completion transaction with the poisoned bit set. This action pertains to the requestors, completers, and switches. (This bit is updated regardless of the state of the Parity Error enable bit.)
Signalled System Error	This bit is set by a device that has detected an uncorrectable error and reported it via an error message (requires SERR# enable bit to be set in the Command register to send error message).
Received Master Abort	Set by a requester that receives a completion transaction with Unsupported Request (UR) in the completion status field.
Received Target Abort	Set by a requester that receives a completion transaction with Completer Abort (CA) in the completion status field.
Signalled Target Abort	Set by a completer when aborting a request that violates the device's programming rules.
Master Data Parity Error	Set by a transmitter that initiates or forwards a transaction with the poisoned bit set and to a receiver device that received a completion with the poisoned bit set. This bit is set by a device that either: receives a completion packet that has been poisoned transmits a write packet that has been poisoned

PCI Express Baseline Error Handling

The Baseline capability also requires use of the PCI Express capability registers. These registers include error detection and handling bit fields that provide finer granularity regarding the nature of an error that is supplied with standard PCI error handling.

Figure 10-8 on page 376 illustrates the PCI Express capability register set. These registers provide support for:

• Enabling/disabling error reporting (Error Message Generation)

• Providing error status

• Providing status for link training errors

• Initiating link re-training

Enabling/Disabling Error Reporting

The Device Control and Device Status registers permit software to enable generation of Error Messages for four error-related events and to check status information to determine which type of error has been detected:

• Correctable Errors

• Non-Fatal Errors

• Fatal Errors

• Unsupported Request Errors

Note that the only specific type of error condition identified is the unsupported request (UR). No granularity is provided for determining other types of error conditions that occur. Only the classification of the error is reported within the device status register. Table 10-5 on page 377 lists each error type and its associated error classification.

Table 10-5. Default Classification of Errors

Classification	Name of Error	Layer Detected
Correctable	Receiver Error	Physical
Correctable	Bad TLP	Link
Correctable	Bad DLLP	Link
Correctable	Replay Time-out	Link
Correctable	Replay Number Rollover	Link
Uncorrectable - Non Fatal	Poisoned TLP Received	Transaction
Uncorrectable - Non Fatal	ECRC Check Failed	Transaction
Uncorrectable - Non Fatal	Unsupported Request	Transaction
Uncorrectable - Non Fatal	Completion Time-out	Transaction
Uncorrectable - Non Fatal	Completion Abort	Transaction
Uncorrectable - Non Fatal	Unexpected Completion	Transaction
Uncorrectable - Fatal	Training Error	Physical
Uncorrectable - Fatal	DLL Protocol Error	Link
Uncorrectable - Fatal	Receiver Overflow	Transaction
Uncorrectable - Fatal	Flow Control Protocol Error	Transaction
Uncorrectable - Fatal	Malformed TLP	Transaction

Enabling Error Reporting — Device Control Register

Setting the corresponding bit in the Device Control Register enables the generation of the corresponding Error Message which reports errors associated with each classification. (Refer to Figure 10-9 on page 378.) Unsupported Request errors are specified as Non-Fatal errors and are reported via a Non-Fatal Error Message, but only when the UR Reporting Enable bit is set.

Error Status — Device Status Register

See Figure 10-10 on page 379. An error status bit is set any time an error associated with its classification is detected. These bits are set irrespective of the setting of the Error Reporting Enable bits within the Device Control Register. Because Unsupported Request errors are by default considered Non-Fatal Errors, when these errors occur both the Non-Fatal Error status bit and the Unsupported Request status bit will be set. Note that these bits are cleared by software when writing a one (1) to the bit field.

Link Errors

The physical link connecting two devices may fail causing a variety of errors. Link failures are typically detected within the physical layer and communicated to the Data Link Layer. Because the link has incurred errors, the error cannot be reported to the host via the failed link. Therefore, link errors must be reported via the upstream port of switches or by the Root Port itself. Also the related fields in the PCI Express Link Control and Status registers are only valid in Switch and Root downstream ports (never within endpoint devices or switch upsteam ports). This permits system software to access link-related error registers on the port that is closest to the host.

If software can isolate one or more errors to a given link, one method of attempting to clear a non-correctable error is to retrain the link. The Link Control Register includes a bit that when set forces the Root or Switch port to retrain the link. If transaction (upon completion of the retraining) can once again traverse the link without errors, the problem will have been solved. Figure 10-11 illustrates the Link Control Register and highlights the Retrain Link field that software sets to initiate retaining.

Software can monitor the Link Training bit in the Link Status Register to determine when retraining has completed. Software can also check the Link Training Error bit to verify that link training was successful. Link Training errors are reported via the Fatal Error Message. Figure 10-12 highlights these status bits.

Root's Response to Error Message

When a message is received by the Root Complex the action that it takes when reporting the error message to the host system is determined in part by the Root Control Register settings. Figure 10-13 depicts this register and highlights the three bit fields that specify whether an error should be reported as a fatal System Error (SERR set enables generation of a system error). In x86 systems it is likely that a Non-Maskable Interrupt (NMI) will be signaled if the error is to be reported as a SERR.

The PME Interrupt Enable bit (3) allows software to enable and disable interrupt generation upon the Root Complex detecting a PME Message transaction.

Other options for reporting error messages are not configurable via standard registers. The most likely scenario is that a system interrupt will be signaled to the processor that will call an Error Handler, which may attempt to clear the error condition and/or simply log the error.