FREE TOOL · RUNS IN YOUR BROWSER

Decode PCIe Bus Error and AER log lines.

Paste the kernel lines from dmesg or journalctl. See which port reported which device, how serious each error was, which status bits were set or masked, how often they repeat and where to look next.

Answer: A Linux “PCIe Bus Error” line is an Advanced Error Reporting (AER) record. severity=Corrected means hardware fixed it, usually by resending a packet; Uncorrectable (Non-Fatal) means a request failed; Fatal means the link is unreliable. The type and status bits name the layer: Physical and Data Link point at the link, Transaction at a request.

Paste whole blocks: the “error received” line, the PCIe Bus Error line, the status/mask line and the [n] bit lines. Timestamps and journal prefixes are fine; unrelated lines are skipped.

Samples are synthetic and labelled; they are not hardware captures.

Capture the lines

AER messages span several lines, and only the first names AER. Keep the lines that follow each match (-A8) so the status and bit lines come with it.

journalctl -k -b | grep -iE -A8 'aer|pcie bus error|dpc'      # this boot
journalctl -k -b -1 | grep -iE -A8 'aer|pcie bus error|dpc'   # previous boot, after a hang or reset
sudo dmesg -T | grep -iE -A8 'aer|pcie bus error|dpc'         # without a persistent journal
grep . /sys/bus/pci/devices/*/aer_dev_correctable            # counters since boot, per device

The log can be rate-limited; the aer_dev_correctable, aer_dev_nonfatal and aer_dev_fatal counters are not. Read them twice, a few minutes apart, to get a rate.

How to read an AER block

LineWhat it tells you
pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0The port on the left (a root or switch port) received an error message from the device on the right. The port reports; it is not necessarily the cause.
PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)Severity, the kernel’s layer label and whose ID the error belongs to. Kernels from 7.3 drop type= and print agent and layer on each bit line.
device [144d:a808] error status/mask=00000001/00006000Vendor:device ID, then the raw AER status and mask registers. A bit set in both was logged but masked, so it was not reported.
[ 0] RxErr (First)One reported status bit, by number and kernel name. “(First)” is the First Error Pointer, which is meaningful for uncorrectable errors.
TLP Header: 0x00000001 0x0000100f …The header of the packet that failed: request type, requester ID and address. Logged with many uncorrectable errors.
DPC: containment event, status:0x1f01 …Downstream Port Containment disabled the link below this port. Devices behind it are gone until the link is recovered.
SeverityWas data lost?What Linux doesWhen to act
CorrectedNo: hardware retriedLogs it and counts it in aer_dev_correctableWhen the rate is steady or rising, or the link runs below its capability
Uncorrectable non-fatalThat request failedAsks the driver to recover; the driver may see an error or timeoutAlways: find which request failed
Uncorrectable fatalIn-flight data can be lostResets the link, or DPC has already contained itAlways: check power, reset and link stability first

pci=noaer and pcie_aspm=off hide symptoms

Both are common forum answers, and neither repairs anything. pci=noaer turns off the kernel’s AER service: errors still happen on the link, but Linux stops logging them and stops running AER recovery for uncorrectable ones. pcie_aspm=off tells Linux not to touch ASPM at all, leaving whatever firmware configured. On some systems that keeps links out of low-power states and the errors stop, which is a clue about link power-state transitions, not a cure. pci=nommconf also silences AER, because extended config space becomes unreachable.

To test the ASPM idea on purpose, compare the counters with ASPM disabled for one link (the endpoint’s link/l1_aspm file in sysfs, or pcie_aspm.policy=performance) and with it enabled. To read the AER registers themselves, use the PCI config space decoder on an lspci -xxxx dump. For an endpoint that vanishes after the error, start with device missing from lspci; for a link that trains narrow, see link stuck at x1.

Questions

What does “PCIe Bus Error: severity=Corrected, type=Physical Layer” mean?
The receiver on that link saw a bad symbol or framing error (usually RxErr) and hardware recovered by resending the packet. One line is harmless. A steady stream points at signal integrity: seating, riser, slot, link speed or ASPM transitions. Measure the rate with the aer_dev_correctable counters.
Is a corrected AER error harmful?
Not by itself: no data was lost. It matters when the rate is steady or rising, when it started after a hardware change, or when the link also trains below its capability. Replays cost bandwidth, and a marginal link can go on to produce uncorrectable errors.
Which device is at fault: the pcieport or the device in the message?
The pcieport (a root or switch port) received the error message; the address after “error received” is the device that sent it. The function named at the start of the PCIe Bus Error line is the one whose AER registers were read. Physical and Data Link errors involve both ends of the same link.
Do pci=noaer or pcie_aspm=off fix PCIe errors?
No. pci=noaer stops Linux from handling and logging AER, so the errors carry on unseen and uncorrectable ones get no AER recovery. pcie_aspm=off leaves ASPM as firmware set it. If errors stop, link power-state transitions are involved: that tells you where to look, but the link is no healthier.
What does “Multiple Corrected error received” mean?
The port collected more than one error message before Linux read its registers, and only the first source is named. Counting log lines therefore undercounts. The per-device aer_dev_* files in sysfs keep exact counts, even when the log is rate-limited.
What is a DPC containment event?
Downstream Port Containment: the port disabled its link after an uncorrectable error so bad data could not spread. Devices below it disappear until Linux recovers the link. “device recovery failed” means they did not come back without a reset or reboot.
Why does my log say Correctable or “Error message” instead of Corrected?
The wording changed between kernel versions: “Corrected error received” up to about 6.8, “Correctable error message received from” after that, and from 7.3 each bit line also prints its agent and layer. The decoder reads all of these forms.

Sources and scope

Updated . Decoding runs locally in your browser; the pasted text is not uploaded, stored or logged.

Guides that use this tool