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)
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.
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 BDFReplace 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/driverUse 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 BDFElevated 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 -tThis 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-pagerKeep 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.
- PCIe AER reports corrected or uncorrected errors · First documented next step
- IOMMU blocks an invalid device DMA access · First documented next step
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.
- Linux PCIe port probe and class table
Reviewed upstream source
lines 685–701, 775–793 - Linux PCIe port/service configuration
Reviewed upstream source
lines 5–6, 29, 122 - Linux PCIe AER guide
Project or distribution documentation
lines 45–66 - Linux PCI class constants
Reviewed upstream source
lines 62–64, 90