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 deviceThe 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
| Line | What it tells you |
|---|---|
pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0 | The 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/00006000 | Vendor: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. |
| Severity | Was data lost? | What Linux does | When to act |
|---|---|---|---|
| Corrected | No: hardware retried | Logs it and counts it in aer_dev_correctable | When the rate is steady or rising, or the link runs below its capability |
| Uncorrectable non-fatal | That request failed | Asks the driver to recover; the driver may see an error or timeout | Always: find which request failed |
| Uncorrectable fatal | In-flight data can be lost | Resets the link, or DPC has already contained it | Always: 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_correctablecounters. - 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=noaerstops Linux from handling and logging AER, so the errors carry on unseen and uncorrectable ones get no AER recovery.pcie_aspm=offleaves 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.
- Linux: PCIe Advanced Error Reporting
- Linux source: drivers/pci/pcie/aer.c (AER message formats and bit names)
- Linux source: drivers/pci/pcie/dpc.c (DPC containment messages)
- Linux ABI: per-device AER counters and rate limits in sysfs
- Linux: kernel parameters (pci=noaer, pcie_aspm, iommu, intel_iommu, amd_iommu)
Guides that use this tool
- GPU passthrough on Proxmox with VFIO: the troubleshooting guide
- lspci explained: read lspci -vvv field by field
- PCIe errors on Linux: AER corrected vs uncorrectable, explained
- PCIe ASPM on Linux: when pcie_aspm=off fixes errors — and what it hides
- XDMA vs QDMA: which AMD PCIe DMA IP — and how to run the XDMA driver on Linux
- PCIe link training, speed and width: why your link is x8, x1 or “downgraded”
- “GPU has fallen off the bus” / Xid 79 on Linux: an AER-first triage
- Mining rig PCIe risers: why x1 is enough — and why your rig still crashes
- Buying a used mining GPU for AI or gaming? Read its PCIe link and error history first