Chipsets & PCIe

PCIe switch-port context

Follow an upstream/downstream switch path before attributing a negotiated link or AER event to an endpoint.

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

Overview & identity

This is a generic PCIe bridge/driver context, not an exact switch-vendor ID. The kernel port probe includes upstream and downstream PCIe types. A multi-hop tree can contain separate links with different speeds and widths; a switch function and the downstream GPU are distinct PCI functions.

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

pcieport is the port owner when the built-in port-bus driver binds. AER and downstream containment are services of the hierarchy and are not GPU drivers. Read both sides of the relevant link; the endpoint maximum is not a measurement of the switch uplink or a guarantee of the current negotiated path.

  • 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 switch-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

A bridge-class hit also covers devices that are not this kind of switch. No vendor, board model, riser design or PCIe generation is inferred without explicit capability and device evidence from the pasted report.

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.