Modern high-performance components—such as dedicated graphics cards, NVMe solid-state storage drives, and 10/25/100GbE enterprise network interfaces—rely on the Peripheral Component Interconnect Express (PCIe) bus to transfer data to the processor and system memory. When assembling a new system or diagnosing workstation stutter, verifying that hardware operates at its advertised PCIe generation and link width is essential. The lspci utility in Linux provides low-level hardware diagnostics to audit both the maximum capabilities of the device and its current negotiated bus bandwidth.
Understanding PCIe Generations, Link Widths, and Bandwidth Bottlenecks
PCIe interfaces communicate across bidirectional serial links referred to as lanes (typically x1, x4, x8, or x16). Each successive generation effectively doubles throughput per lane (from PCIe 3.0 at 8 GT/s to PCIe 4.0 at 16 GT/s and PCIe 5.0 at 32 GT/s). However, hardware occasionally falls back to lower transfer modes due to motherboard slot bifurcation conflicts, improper mechanical seating, dust obstruction in PCIe pins, or aggressive PCIe Active State Power Management (ASPM) power-saving profiles. Using lspci allows you to differentiate between intentional power management and physical bandwidth degradation.
Locating Your Target Peripheral Device Index
First, list the connected PCI devices to identify the domain, bus, slot, and function numbers (the BDF identifier) of your target hardware:
lspci -nn | grep -E "VGA|Non-Volatile"
The command filters the hardware table to show your GPU or NVMe storage controller alongside its PCI slot identifier:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD104 [GeForce RTX 4070] [10de:2786]
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/980 [144d:a80a]
In this example, the graphics card resides at slot 01:00.0 and the primary NVMe SSD resides at 04:00.0.
Inspecting PCIe Link Capabilities vs Link Status
To inspect link negotiation, run lspci with verbose output (-vv) filtered specifically for your device using the -s parameter. Root privileges are required to parse low-level hardware registers:
sudo lspci -s 01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
The terminal outputs two diagnostic lines that reveal everything about the bus negotiation:
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us
LnkSta: Speed 16GT/s (ok), Width x16 (ok)
Interpreting LnkCap and LnkSta Outputs
Evaluating hardware health depends on comparing these two parameters:
- LnkCap (Link Capabilities): Reports the physical maximum specification designed into the device controller and supported by the motherboard traces. In the example above,
Speed 16GT/scorresponds to PCIe Gen 4, andWidth x16indicates 16 physical lanes. - LnkSta (Link Status): Reports the actual real-time connection state negotiated between the motherboard chipset and the card.
- If
LnkStamatchesLnkCap(e.g.Speed 16GT/s, Width x16), the device operates at maximum theoretical performance. - If
LnkCapreportsWidth x16butLnkStaindicatesWidth x8orWidth x4, the card is either seated in an electrical x4/x8 secondary slot, shares PCIe lanes with an active M.2 drive, or suffers from poor mechanical contact.
- If
Differentiating ASPM Power-Saving from Hardware Faults
Modern graphics cards frequently downclock their PCIe bus interface when idle on the desktop to save energy, dropping from PCIe 4.0 x16 down to PCIe 1.1 x16 or PCIe 2.0 x8. To confirm whether a lower reported speed is simply dynamic power-saving:
- Launch a lightweight 3D render test or compile job that stresses the GPU.
- While the workload runs, re-execute:
sudo lspci -s 01:00.0 -vv | grep "LnkSta:" - If the link status immediately scales up to full rated speed and width under load, ASPM dynamic throttling is functioning normally. If the width remains crippled at x4 or x8 under load, inspect BIOS slot bifurcation settings or reseat the card physically.