Introduction to PCI Express Error Management

PCI Express defines a variety of mechanisms used for checking errors, reporting those errors and identifying the appropriate hardware and software elements for handling these errors.

PCI Express Error Checking Mechanisms

PCI Express error checking focuses on errors associated with the PCI Express interface and the delivery of transactions between the requester and completer functions. Figure 10-1 on page 357 illustrates the scope of the error checking that is the focus of this chapter. Errors within a function that do not pertain to a given transaction are not reported through the error handling procedures defined by the PCI Express specification, and it is recommended that such errors be handled using proprietary methods that are reported via device-specific interrupts. Each layer of the PCI Express interface includes error checking capability as described in the following sections.

Transaction Layer Errors

The transaction layer checks are performed only by the Requestor and Completer. Packets traversing switches do not perform any transaction layer checks. Checks performed at the transaction layer include:

• ECRC check failure (optional check based on end-to-end CRC)

• Malformed TLP (error in packet format)

• Completion Time-outs during split transactions

• Flow Control Protocol errors (optional)

• Unsupported Requests

• Data Corruption (reported as a poisoned packet)

• Completer Abort (optional)

• Unexpected Completion (completion does not match any Request pending completion)

• Receiver Overflow (optional check)

Data Link Layer Errors

Link layer error checks occur within a device involved in delivering the transaction between the requester and completer functions. This includes the requesting device, intermediate switches, and the completing device. Checks performed at the link layer include:

• LCRC check failure for TLPs

• Sequence Number check for TLP s

• LCRC check failure for DLLPs

• Replay Time-out

• Replay Number Rollover

• Data Link Layer Protocol errors

Physical Layer Errors

Physical layer error checks are also performed by all devices involved in delivering the transaction, including the requesting device, intermediate switches, and the completing device. Checks performed at the physical layer include:

• Receiver errors (optional)

• Training errors (optional)

Error Reporting Mechanisms

PCI Express provides three mechanisms for establishing the error reporting policy. These mechanisms are controlled and reported through configuration registers mapped into three distinct regions of configuration space. (See Figure 10-2 on page 360.) The various error reporting features are enabled as follows:

• PCI-compatible Registers (required) — this error reporting mechanism provides backward compatibility with existing PCI compatible software and is enabled via the PCI configuration Command Register. This approach requires that PCI Express errors be mapped to PCI compatible error registers.

• PCI Express Capability Registers (required) — this mechanism is available only to software that has knowledge of PCI Express. This required error reporting is enabled via the PCI Express Device Control Register mapped within PCI-compatible configuration space.

• PCI Express Advanced Error Reporting Registers (optional) — this mechanism involves registers mapped into the extended configuration address space. PCI Express compatible software enables error reporting for individual errors via the Error Mask Register.

The specification refers to baseline (required) error reporting capabilities and advanced (optional) error reporting capabilities. The baseline error reporting mechanisms require access to the PCI-compatible registers and PCI Express Capability registers (bullets 1 and 2 above), while advanced error reporting (bullet 3) requires access to the Advanced Error Reporting registers that are mapped into extended configuration address space as illustrated in Figure 10-2. This chapter details all error reporting mechanisms.

Error Handling Mechanisms

Errors are categorized into three classes that specify the severity of an error as listed below. Note also the specification defines the entity that should handle the error based on its severity:

• Correctable errors — handled by hardware

• Uncorrectable errors-nonfatal — handled by device-specific software

• Uncorrectable errors-fatal — handled by system software

By defining errors into these classes, error handling software can be partitioned into separate handlers to perform the actions required for a given platform. The actions taken based on severity of an error might range from monitoring the effects of correctable errors on system performance to simply resetting the system or PCI Express sub-system in the event of a fatal error.

Note that regardless of the severity of a given error, software can establish a policy whereby any error can be reported to the system (via the Root Complex) for the purpose of tracking and logging. (See page 390 for details.)