PCIe Chapter 12: Error Evidence, Reporting, and Containment

Preserve evidence along an error-reporting path

AER (Advanced Error Reporting) supplies error status, reporting controls and related records. Follow normal error reporting before comparing masked errors and DPC containment. Chapter 5 provides transaction context and Chapter 7 provides notification context.

DPC

Downstream Port Containment

Specification route: Classification in Figure 6-1 → status, mask and severity → reporting in Figure 6-3 → root records → preservation and clearing → DPC.

Connect evidence from the Function to the Root

Correctable Errors can be recovered by the protocol but may affect performance. Uncorrectable Errors affect functionality and are classified Non-Fatal or Fatal. Non-Fatal does not establish successful work, and Fatal does not directly diagnose a failed chip. AER adds detailed status, masks, severity, and logs to baseline reporting; absence of AER does not imply absence of all reporting.

Inspect source Status, the Mask/Severity/Device Control settings at detection, valid Header Logs, and then Root Error Status/Source ID. Check DPC separately if containment is possible. Later configuration reads do not automatically reconstruct earlier settings. Sources: §6.2.1–§6.2.4 (pp.669–679), Figure 6-1 (p.670).

Two status bits, one unmasked error

Traverse Extended Capabilities on 03:00.0 and use Figure 7-154 to identify AER ID=0x0001. This example has base=0x100, Version=2, Next=0; Base 6.0 does not imply this Function implements all Flit features. Earlier records were cleared, settings remained unchanged, and forwarding along the path is enabled.

0x00044000 & ~0x00040000 = 0x00004000: only the recorded Timeout is unmasked. A masked error can set Status but does not generate its Error Message or update the Header Log, TLP Prefix Log, or FEP. Fatal severity does not override masking. Under these assumptions, Timeout produces ERR_NONFATAL according to Severity and Device Control. These are configured values, not reset defaults.

The complete path also includes Bridge forwarding, Root primary-interface transmission controls, and interrupt conditions. Follow Figure 6-3 through the path. Unsupported Request and Advisory Non-Fatal errors have additional rules; the example's arithmetic is not a general reporting algorithm.

Validate the log before decoding the transaction

FEP=14 is valid because Status bit 14 is set. Completion Timeout Header Log Capable bit 12 supports recording the timed-out Request. Multiple Header Recording bits 9 and 10 are clear; there is no Flit or Prefix support. The example has four DWORDs of log capacity but uses a three-DWORD Header.

The Request covers 0x40001000–0x400010FF, or 256 bytes. It is the Request that did not complete in time, not a timed-out Completion. Figure 7-161 places Header byte 0 at bits 31:24 for DWORD reads; do not reverse these values again. Flit logs require Logged TLP was Flit Mode, Header Log Size, Logged TLP Size, and Type/OHC interpretation.

OHC

Orthogonal Header Content

This locates a transaction and its timeout, not the responsible Endpoint, Completer, Link, or platform component. It cannot be assigned to the masked Malformed TLP event, which did not create this log.

The Root Source ID identifies the first reporter

The Root interrupt message number is 0 and primary-interface transmission conditions are satisfied. Source ID identifies the Endpoint reporting Timeout, not the physical cause. A second message in the same category sets Multiple without replacing the first Source ID.

Root Status updates independently of Root Error Command/Root Control, but still requires applicable primary-interface transmission enables. CPU interrupt delivery additionally requires vector and routing evidence. Sources: Figures 7-162–7-164/Tables 7-142–7-144 (pp.1123–1127).

Preserve correlated records before clearing

The author recommends saving status, configuration, FEP, valid logs, and Root/DPC evidence while checking for concurrency. Separate register reads are not automatically an atomic snapshot. Clearing the status indicated by FEP can advance hardware to another log, destroying the original association if done before capture.

With Multiple Header Recording enabled and valid FEP, the specification recommends processing records through FEP rather than clearing unrelated status; it lists an exception for masked errors known to lack recorded headers. PCI Status and AER Status are also cleared independently. Sources: §6.2.4.2 (pp.679–681, footnote 108), §6.2.7.1 (p.691).

DPC can contain the error before its original message reaches the Root

Now consider a separate event on Switch Downstream Port 02:01.0, with DPC base=0x300 and no RP Extensions.

Enable=10b triggers on a local unmasked Uncorrectable Error or a received ERR_NONFATAL/ERR_FATAL. Reason=01b makes Source ID meaningful here; Reason=00b would not. The triggering message is discarded at the Port rather than forwarded to the Root. This example enables DPC interrupts but not DPC ERR_COR, so the earlier Root value 0x24 is not an expected companion snapshot.

Why does the Link remain down after acknowledging the interrupt?

Figure 7-300 places DPC Trigger Status in bit 0 and DPC Interrupt Status in bit 3. Both clear on a write of 1, but they have different effects: bit 3 handles interrupt status; bit 0 keeps containment active. Clearing bit 0 permits the Link Training and Status State Machine (LTSSM) to leave Disabled and return to Detect to attempt Link establishment.

Who responds to a new Memory Read during containment?

Follow §2.9.3, Transaction Layer Behavior During Downstream Port Containment. Assume the Root Complex sends a new, valid Memory Read targeting a BAR in 03:00.0 through 02:01.0. It is submitted for downstream transmission after the Port is already in DPC. The Port discards this Request and generates an error Completion.

BAR

Base Address Register

Figure 7-299 and Table 7-263 determine the status: DPC Control=0x000A has DPC Completion Control, bit 2, cleared, so the response is Completer Abort (CA). Setting that bit instead selects Unsupported Request (UR). The Completion's Completer ID identifies Downstream Port 02:01.0, which terminates this Request. The earlier DPC Error Source ID of 03:00.0 identifies the sender of the message that triggered containment.

CA in this scenario comes from the Port's DPC handling; it does not establish that the Endpoint accepted or executed the read. A Request transmitted before containment, whose Completion is prevented from returning by DPC, is a different case. Without the Root Port Extensions completion-synthesis mechanism in this example, its Requester may encounter Completion Timeout. Track termination of the new Request separately from completion of earlier work.

What remains after containment is released?

Table 7-264 requires the Port to leave DPC and the LTSSM to transition to Detect when DPC Trigger Status clears. Training is only being attempted. Software still observes Link and Data Link recovery, honors the applicable §6.6.1 timing for the first Configuration Read following Conventional Reset, and restores configuration and driver operation. Chapter 9 covers the reset and readiness conditions.

Release changes log interpretation too: DPC Trigger Reason is invalid when DPC Trigger Status is clear, so analyze this event using the saved snapshot. Once release requirements are met, the specification permits clearing Trigger Status regardless of other status bits associated with the triggering event. Clearing every error record is therefore not a prerequisite for release. Rebuilding device work, resolving earlier outstanding data and restoring application service still require device, driver and platform recovery procedures.

Check the evidence limits