Chipsets & PCIe

PCIe root-port context

A topology and native-service context; bridge class alone does not establish an exact motherboard or port type.

On this page
  1. Overview & identity
  2. Driver & binding
  3. Firmware
  4. Read-only diagnostics
  5. Limitations & related issues
  6. References

Overview & identity

This profile has no exact vendor/device match. The reviewed driver accepts PCI bridge classes but then requires a PCIe root, upstream, downstream or RCEC type. A root port is the platform-facing parent of a link; distinguish it from the GPU or storage endpoint whose error appears later in the report.

This is an explicit class, transport or driver-context profile. It is not an exact numeric product match.

A numeric match establishes a candidate family within the reviewed evidence. Marketing names, board variants, subsystem conditions and successful operation remain separate questions.

Driver & binding

The observed driver name is pcieport. PCIEPORTBUS is built into the kernel when enabled, so a missing loadable module called pcieport is not a failure. Service availability such as AER depends on separate kernel configuration and firmware control, not solely on bridge enumeration.

  • pcieport — kernel driver/module candidate (built-in code is possible)

Detected, bound, operational: learn the difference

Firmware

No host payload established here

No external firmware filename is established by the port-driver sources. System firmware still sets platform policy and can retain control of PCIe services; Linux AER ownership depends on the documented firmware/OS handoff. “No filename” is not a claim that the bridge lacks firmware.

Inspect firmware packaging on your distribution

Read-only diagnostics

Run one displayed command at a time. Replace uppercase placeholders with the affected device, interface or module from your own output. Commands are never executed here. Read-only output can still contain private identifiers.

Read this function and its bound driver

lspci -nnk -s BDF

Replace BDF with the address of the PCIe root-port context function. The summary normally needs no sudo. Numeric ID and the “driver in use” observation are stronger evidence than a descriptive name or candidate-module list.

Confirm the PCI driver owner

readlink /sys/bus/pci/devices/BDF/driver

Use a full domain:bus:slot.function BDF. This normally needs no sudo and only reads a symlink. The last component is the bound driver; no link records an unbound/absent function, not a missing software package.

Read the PCIe capability type and link information

sudo lspci -vv -s BDF

Elevated access may be needed. This reads PCI configuration and does not write settings. sudo is used to obtain capability detail that unprivileged PCI configuration reads may hide. Inspect Root Port/Upstream/Downstream/RCEC type and distinguish LnkCap from LnkSta; a maximum capability is not the negotiated state.

Read the PCI parent/child tree

lspci -t

This topology summary normally requires no sudo. Connect BDF to its parent and downstream functions before interpreting an AER report. A tree is connectivity evidence, not a device performance or link-quality test.

Read current-boot controller messages

journalctl -k -b --no-pager

Keep the first AER event, severity, reporting address and recovery sequence together. Journal access may require local group membership; failure to read it is not controller failure.

Limitations & related issues

Use capability type and topology to confirm that the matched bridge is actually a root port. Corrected AER counts describe observed link events and are not a diagnosis of a defective CPU, board or attached GPU.

These guides are linked for relevant observations, not as known defects of every device in this family.

Choose a hardware diagnostic workflow · Inspect a log excerpt in Fix Lab

References

Source review records a checked implementation or document, not a reproduced hardware test. Version-specific tables do not establish a minimum kernel or guaranteed operation.