lspci

What it does

lspci lists all PCI (Peripheral Component Interconnect) devices detected on the system — things like the GPU, network controllers, USB host controllers, SATA controllers, and other hardware connected via the PCI/PCIe bus. It reads this information from the kernel's /sys/bus/pci interface and resolves vendor/device IDs into human-readable names using the pci.ids database. It requires the pciutils package on most distributions.

Beginner examples

• lspci — list every PCI device with a short description
• lspci -v — list devices with additional verbose detail
• lspci -tv — show devices arranged as a tree, reflecting bus/bridge topology
• lspci | grep -i vga — find the graphics device specifically

lspci

Advanced examples

• Show the tree topology with verbose device names: lspci -tv
• Check which kernel driver is bound to the network card: lspci -k | grep -A3 -i ethernet
• Get maximum detail (including vendor-specific capabilities) for deep debugging: lspci -vv
• Inspect a specific device by its bus address (from a plain lspci listing): lspci -s 01:00.0 -vv
• Show both numeric IDs and resolved names, useful when filing driver bug reports: lspci -nn

lspci -k | grep -A3 -i ethernet

Common mistakes

• Running lspci expecting to see USB peripherals (keyboards, mice, flash drives) — those attach via the USB bus and show up in lsusb, not lspci; PCI only covers devices on the PCI/PCIe bus itself (including the USB controller hardware).
• Expecting lspci to work identically on macOS — there's no built-in PCI enumeration tool; system_profiler SPPCIDataType is the closest macOS equivalent.
• Seeing unresolved numeric vendor/device IDs and assuming the hardware is unrecognized/broken, when it may just mean the local pci.ids database is outdated (fixable with sudo update-pciids).
• Forgetting that some detailed output (like -vv register dumps) requires root privileges to fully populate; running as a normal user can silently omit some fields.

Tips

• Use lspci -k first when a piece of hardware "isn't working" — it immediately shows whether any kernel driver is bound at all.
• lspci -tv is the fastest way to understand PCI bus topology, especially on servers with multiple PCIe slots, risers, or passthrough devices in a VM.
• Keep the pciutils package's ID database current with sudo update-pciids so device names resolve correctly, especially on newer hardware.

Best practices

• When troubleshooting hardware detection issues, run lspci -k before jumping to kernel module or driver reinstallation — confirm the device is even visible on the bus first.
• In bug reports or support tickets, include lspci -nn output so both the human-readable name and the exact numeric vendor:device ID are captured unambiguously.
• On virtualized/cloud instances, use lspci to confirm which virtual devices (e.g., virtio-net, virtio-blk) are actually exposed to the guest before debugging performance issues.

Real-world use cases

• Diagnosing why a GPU, network card, or storage controller isn't being recognized by the kernel.
• Confirming which driver is bound to a device before troubleshooting a hardware-specific bug.
• Auditing installed hardware on a new or unfamiliar server, especially bare-metal machines.
• Verifying that a passthrough PCI device is correctly visible inside a virtual machine.

Common interview questions

• How would you check which kernel driver is bound to a specific piece of PCI hardware? lspci -k, which lists the Kernel driver in use: line for each device.
• What's the difference between lspci and lsusb? lspci enumerates devices on the PCI/PCIe bus (GPUs, network cards, storage controllers); lsusb enumerates devices on the USB bus (keyboards, mice, flash drives, USB hubs) — they cover different hardware buses.
• Why might lspci show a device with only numeric IDs instead of a name? The local pci.ids database used to resolve names may be outdated or missing an entry for very new hardware; running sudo update-pciids refreshes it.