PCIe AER Explained: Correctable, Uncorrectable, Fatal, and Non-Fatal Errors

PCI Express Advanced Error Reporting, usually shortened to AER, is an extended PCIe capability for recording and reporting errors associated with PCIe links and transactions. It builds on PCIe baseline error reporting with more detailed status, severity, source, and diagnostic information. Operating systems can use that information to log an event and, for errors that need software involvement, coordinate recovery.

AER is about error handling, not link speed. It does not define whether a device runs at PCIe Gen 3, Gen 4, or Gen 5, how many lanes it negotiates, or how much bandwidth it receives. It is also separate from Active State Power Management (ASPM), which controls supported low-power link states during idle periods.

Linux kernel AER documentation defines correctable errors as errors that the PCIe protocol can recover from without software intervention or loss of data. The AER driver can clear the correctable status and log the event without initiating recovery. Examples exposed by Linux AER counters include Receiver Error, Bad TLP, Bad DLLP, Replay Number Rollover, Replay Timer Timeout, and Advisory Non-Fatal.

That classification describes the handling of the individual PCIe error; it is not a universal health threshold. A single corrected event does not prove that a GPU, SSD, motherboard, riser, cable, CPU, or PSU is failing. Conversely, a large or changing stream of corrected errors can be useful diagnostic evidence when it correlates with a reproducible symptom. There is no source-backed universal count at which every PC should replace a component.

An uncorrectable error is different because functionality is affected. The PCIe hierarchy further classifies these errors by severity. Linux documents a non-fatal error as one where a particular transaction is unreliable while the link remains functional; a fatal error makes the link itself unreliable. Intel platform documentation exposes the corresponding AER severity register, where supported uncorrectable error conditions are classified as fatal or non-fatal.

The words are technical classifications, not predictions about whether Windows will crash or whether a component is permanently damaged. A non-fatal event can still matter to an application or driver, and a fatal AER event can trigger link/device recovery without proving permanent hardware failure. The exact system-visible outcome depends on the error, hierarchy, driver support, firmware, and operating system.

PCIe is a hierarchy. An endpoint such as a GPU, NVMe controller, or network adapter connects through a root port and may also sit behind switches or bridges. Linux documents that when an AER-capable device captures an error, it can send the corresponding PCIe error message toward the root port. The root port records information including error status and the reporting agent’s Requester ID, then can notify software when reporting is enabled.

This topology matters when reading logs. The device named as a root port is often the reporting or collection point for a hierarchy, not necessarily the physical part that caused the underlying electrical, protocol, firmware, or transaction problem. Linux root-port AER counters are explicitly cumulative for error messages reported to that root port and can include messages originating elsewhere in its PCIe hierarchy.

Windows Hardware Error Architecture, or WHEA, is the Windows framework for hardware error reporting. Microsoft documents multiple hardware error sources, including processor and platform sources. PCIe AER is one specific source: Microsoft notes that the Windows PCI bus driver discovers PCIe AER error sources rather than the platform-specific hardware error driver used to discover several other WHEA sources.

That means “WHEA error” and “PCIe AER error” are not interchangeable labels. When diagnosing a Windows event, inspect the actual error record, source, PCIe identifiers, status information, and the circumstances around the failure instead of assuming every WHEA entry is a PCIe problem or every PCIe-related entry identifies one replaceable component.

Linux can provide AER handling through its PCIe AER root driver when the platform grants the operating system control. Current kernel documentation states that firmware and Linux must not both independently handle AER; firmware can grant AER control through ACPI _OSC. When Linux owns AER handling, the kernel can gather error information, report it, and perform recovery actions.

Linux also exposes counters for correctable, non-fatal, and fatal AER events through sysfs on supported devices and root ports. Those counters are useful for establishing whether errors are recurring and where they are being reported, but they still need topology and workload context. The kernel documentation notes that one error message can represent multiple status bits, so even its aggregate counters should not be treated as a universal failure score.

Linux provides a concrete example of how an operating system can react to severity. For an uncorrectable non-fatal event, affected drivers are notified and may be able to recover without a reset; a driver can also request one. For a fatal event, Linux treats the link as unreliable and requires an upstream reset as part of the recovery path.

That behavior should not be generalized into a claim that every operating system uses the same callbacks or presents the same user-visible symptoms. AER defines the PCIe error information and classifications; firmware ownership, operating-system architecture, driver recovery support, and the topology determine how a particular machine handles the event.

When AER evidence appears alongside crashes, device resets, storage errors, link retraining, or another reproducible symptom, preserve the exact log and identify the PCIe topology before changing hardware. Note the device and root-port identifiers, error class, status bits, timestamp, workload, firmware and driver versions, negotiated link state, and whether the event repeats under the same conditions.

Then change one relevant variable at a time. Depending on the affected path, that can mean verifying seating and power connections, removing a riser or adapter for a direct-path test, returning unsupported overclocks or undervolts to defaults, updating documented firmware or drivers, or testing the device in another known-good path. Those are diagnostic experiments, not conclusions embedded in the AER label itself.

Do not disable AER merely to make a log disappear. Suppressing reporting can hide evidence without fixing the condition that generated it. Likewise, do not change PCIe generation, ASPM, BIOS settings, or replace a PSU simply because an internet checklist associates that tweak with a generic AER message. A useful diagnosis requires a repeatable symptom and evidence that the tested change affects it.