Fact-checked by Grok 2 weeks ago

lspci

lspci is a command-line utility available on various operating systems, including Unix-like systems such as Linux and FreeBSD, and Windows, that displays information about PCI buses in the system and all devices connected to them. By default, it outputs a brief list of devices with their vendor and device identifiers translated into readable names using a PCI ID database. Developed by Martin Mareš and first released in 1997 as part of the PCI Utilities package, lspci relies on the portable libpci library to access PCI configuration registers across multiple platforms, such as Linux, FreeBSD, and Windows. The tool enables users to inspect hardware details like device classes, IRQ assignments, and memory regions, making it essential for system administration, debugging PCI-related issues, and identifying hardware components without proprietary drivers. Key features include verbose output modes (-v, -vv, -vvv) for escalating levels of detail, from basic capabilities to full space dumps in (-x, -xxx), and options to show drivers (-k) or tree-like bus topologies (-t). It supports filtering by bus, , , or (-s, -d), and can query a central PCI ID database online if local data is incomplete (-q). Access to certain advanced functions, such as full configuration space reads, requires privileges due to operating system restrictions. The latest version, 3.14.0 released on June 21, 2025, continues to incorporate updates to the PCI ID list maintained at pci-ids.ucw.cz for accurate recognition.

Introduction

Description

lspci is a command-line utility for operating systems, including , designed to display information about buses and the devices connected to them. It enumerates all PCI devices present in the system, providing details such as device locations, vendor identifiers, device identifiers, and class codes that classify the type of . The utility interrogates the Peripheral Component Interconnect (), a high-speed bus standard that facilitates communication between a computer's and peripheral hardware components. PCI serves as the foundational interconnect for a wide range of devices, including graphics cards, network interface controllers, sound cards, and storage controllers, enabling efficient data transfer and resource sharing within the system architecture. lspci accesses PCI device information via the portable , which abstracts system interfaces; on , this includes /proc/bus/pci or the filesystem (/sys/bus/pci/devices) to retrieve configuration registers and enumerate buses and devices without requiring direct hardware manipulation in most cases. This approach allows it to provide a portable view of the PCI topology across supported operating systems, with some advanced details restricted to privileged users. lspci forms part of the pciutils package, which also includes a library for low-level PCI access used by other tools and applications. Similar utilities exist for other bus standards, such as lsusb for USB devices.

History

lspci was developed by Martin Mareš as part of the pciutils package, a collection of utilities providing portable access to bus configuration registers, with initial development beginning in 1997. The project aimed to offer cross-platform tools for inspecting devices, starting with basic enumeration capabilities in early versions. The first public release, version 1.0, appeared in 1998, introducing lspci as a core utility for listing devices and their details. Key milestones include the release of version 2.1.x series in the late and early , which stabilized the core functionality, followed by version 3.0 in April 2008, which updated the and ABI for better compatibility. In December 2008, the lspci was restructured by splitting it into multiple files to facilitate maintenance. Support for (PCIe) extensions began emerging in 2004 with preliminary decoding in test releases, evolving to include advanced features like link status and capabilities in subsequent versions. Integration with the ID database (pci.ids) has been an ongoing focus, enabling lspci to provide vendor and device names through regular updates maintained collaboratively. The pciutils package, including lspci, is maintained under the GNU General Public License (GPL), allowing free distribution and modification. Contributions primarily involve bug fixes, enhancements for new hardware, and expansions to the device database, with Martin Mareš overseeing releases up to the latest version 3.14.0 in June 2025. Recent maintenance releases, such as 3.13.0 in May 2024, have added decoding for emerging standards like , reflecting the tool's adaptation to modern /PCIe ecosystems.

Installation and Availability

On Linux Distributions

The lspci utility is provided by the pciutils package, which is available in the official repositories of major distributions including , , and . It is typically pre-installed in standard installations of these distributions, as the package contains essential tools for inspecting devices. The pciutils package has been included in major distributions since the early 2000s, reflecting the long-standing need for PCI bus utilities in systems. Version numbers vary by distribution and release; for instance, 24.04 LTS includes version 3:10.0-2build1. If not pre-installed, such as in minimal server setups or containers, the package can be installed using the distribution's . On Debian-based systems like and , run sudo apt install pciutils. On Fedora-based systems, run sudo dnf install pciutils. To verify availability, use which lspci to check if the command is in the , or on Debian-based systems, dpkg -l | [grep](/page/Grep) pciutils to query the package status. For custom requirements, source compilation is an alternative option.

Source Compilation

Compiling lspci from source is particularly useful for systems, custom environments, or when distribution-provided packages are outdated, allowing users to obtain the latest features and support for recent hardware standards. The source code for pciutils, which includes lspci, can be downloaded from the official website at http://mj.ucw.cz/sw/pciutils/, mirrored on at ://github.com/pciutils/pciutils, or from the Linux Archives at ://www./pub/software/utils/pciutils/. The latest release as of June 2025 is version 3.14.0, available as a tarball such as pciutils-3.14.0.tar.; verify the PGP signature using the key from http://mj.ucw.cz/pgp.html for authenticity. Building requires a compiler supporting the standard (such as ) and Make; optional dependencies include zlib for compressed ID file support and libresolv for DNS-based ID resolution. No headers are necessary for the basic build, as the utilities operate in user space. To build, extract the tarball, navigate to the source directory, and run make to compile the utilities and library. Then, execute make install (typically as root) to install binaries to /usr/local/bin by default, along with man pages and the pci.ids database; use make PREFIX=/custom/path install to specify an alternative installation prefix, such as /usr for system-wide integration. For packaging, set make DESTDIR=/staging/path install to stage files without installing directly. Custom build options can be set via variables or Makefile edits before running make. For instance, SHARED=yes enables building the libpci (requiring 4.0 or later), while ZLIB=no disables zlib support if unavailable, and DNS=no turns off DNS ID resolution. Run make help in the source directory for a full list of configurable options. To install only the library and headers for development, use make install-lib. The latest source builds support decoding of (PCIe) capabilities up to recent revisions, including PCIe 6.0 features and CXL 3.0, ensuring compatibility with modern hardware configurations. While package managers offer a simpler method for standard distributions, source compilation provides flexibility for tailored deployments.

Usage

Syntax and Options

The lspci command follows the basic syntax lspci [options], where optional flags control the display of device information, and device selection can be specified via certain options to limit output to specific buses or devices. Key options allow customization of verbosity and output format. The -v, -vv, and -vvv flags enable progressively more detailed output: -v provides verbose information on capabilities including driver details, while -vv and -vvv include additional details such as regions and capabilities. The -t option displays devices in a tree format that illustrates the bus hierarchy, including bridges and connected components. For numeric output, -n shows vendor and device IDs as numbers instead of resolved names. Filtering is supported via -d [<vendor>]:[<device>][:<class>[:<prog-if>]], which selects devices by vendor ID, device ID, class code (e.g., ::0200 for Ethernet controllers), or programming interface, all in with wildcard support using *. Device targeting uses -s [[[[<domain>]:]<bus>]:][<slot>][.<fn>], specifying exact locations by , bus, , and function numbers in . Additionally, -i <file> loads a custom ID database file to override the default /usr/share/pci.ids for name resolution. Output formats vary by option. By default, lspci produces a brief list of devices with slot, vendor, and device names. The -m flag generates machine-readable output suitable for parsing by scripts, while -xxx dumps the entire in format (requiring root privileges for full access). The -k option specifically reveals the or in use for each device, available in pciutils version 3.3 and later, alongside 2.6 or newer. Some advanced class filters in -d also require pciutils 3.3 or higher for full functionality.

Interpreting Output

The default output of lspci presents a concise list of PCI devices, formatted as [domain:]bus dev.fn: vendor:device - class description. This structure identifies each device's location on the PCI bus , where the (if present) indicates a multi-domain setup, bus is the bus number in hexadecimal, dev is the device number, and fn is the function number for multi-function devices. The and fields are hexadecimal IDs that map to manufacturer and model names, followed by a brief description of the device's PCI class. Increasing verbosity with the -v option reveals additional capabilities and configuration details for each device, such as (IRQ) assignments, states (e.g., supported D0-D3 power states and wake-up capabilities), and vital product data like serial numbers if available. The -vv level extends this to include configuration space registers, showing and I/O regions, latency timers, and bridge control settings in a parsed, human-readable format. At -vvv, lspci outputs a comprehensive dump of all parsable configuration data, including less critical elements like undefined BARs (base address registers), intended for debugging and requiring familiarity with the specification. The tree format, invoked with -t, displays the PCI bus hierarchy in an indented, tree-like structure, starting from the root bus (typically bus 00) and branching to host bridges, PCI-to-PCI bridges, and endpoint devices, with each level prefixed by bus numbers to illustrate connectivity and downstream devices. This view aids in understanding complex multi-bus systems, such as those with multiple root ports in modern chipsets. Key interpretive elements include vendor and device IDs, which are 16-bit hexadecimal values standardized by the (PCI SIG) and resolved to readable names from the pci.ids database. Class codes, a 24-bit field in the , categorize devices into base class (8 bits, e.g., 0x02 for network controllers), subclass (8 bits, e.g., 0x00 for Ethernet), and programming interface (8 bits for specifics like interface standards); for instance, 0x0300 denotes a VGA-compatible display controller. Revision IDs indicate hardware stepping or revisions, appearing in verbose output to distinguish variants with potential behavioral differences. Subsystem vendor and device IDs provide further identification for OEM customizations, often shown in -v output alongside the primary IDs. lspci's human-readable names for vendors, devices, and classes rely on the pci.ids file, typically located at /usr/share/pci.ids or /usr/local/share/pci.ids, maintained by the ; outdated or missing entries result in numeric IDs without descriptions, signaling the need for an update via tools like update-pciids.

Example Usage

To list all PCI devices in a system, the basic lspci command provides a concise overview of connected hardware. For example, running lspci might produce output such as: 
00:00.0 Host bridge: Intel Corporation 82X38/X48 Express DRAM Controller
00:01.0 PCI bridge: Intel Corporation 82X38/X48 Express PCI Express Root Port 1
00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4
00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5
00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6
00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 1
00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 5
00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Port 6
00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1
00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2
00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3
00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge
00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller
00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller I
00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller
00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller II
01:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 370] (rev a1)
This output varies by hardware configuration. For identifying network hardware along with associated kernel drivers, a verbose listing filtered by keyword can be effective, such as lspci -v | grep -i ethernet. A representative output might include: 
01:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)
        Subsystem: Dell NetXtreme BCM5721 Gigabit Ethernet PCI Express
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f9fe0000 (64-bit, non-prefetchable) [size=8K]
        Memory at f9ff0000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [48] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [d0] Express Endpoint, MSI 00
        Capabilities: [ac] MSI-X: Enable- Count=5 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-18-8b-ff-ff-7b-dc-80
        Kernel driver in use: tg3
        Kernel modules: tg3
Such filtering helps pinpoint Ethernet adapters and their . To focus on specific device classes like graphics cards, the command lspci -d ::0300 targets VGA-compatible controllers (class code 0300). An example output on a with an GPU could be: 
01:00.0 VGA compatible controller: [NVIDIA](/page/Nvidia) Corporation GP106 [[GeForce](/page/GeForce) GTX 1060 6GB] (rev a1)
Here, the device appears with its vendor-specific identifier, such as 10de:1c82 for certain models; actual results depend on the installed hardware. For examining a in a particular slot, use lspci -s 01:00.0 to restrict output to that bus:device. address. Continuing the prior example, this yields: 
01:00.0 VGA compatible controller: [NVIDIA](/page/Nvidia) Corporation GP106 [[GeForce](/page/GeForce) GTX 1060 6GB] (rev a1)
This is useful for isolating information about a known slot without scanning the entire bus. The option lspci -t visualizes the PCIe , showing hierarchical connections like root ports, bridges, and endpoints. A sample output might resemble: 
-[0000:00]--+-00.0  
            +-00.2  
            +-01.0-[01-04]--+-00.0  
            |                \-00.1  
            \-01.1-[02-02]--+-00.0  
                               \-00.2
This structure reveals how devices attach to buses and bridges, aiding in understanding system interconnects. In troubleshooting scenarios, such as debugging unrecognized hardware, highly verbose output for a specific device with lspci -vvv -s 01:00.0 exposes detailed configuration registers. For instance, it might include sections like: 
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1c03 (rev a1) (prog-if 00 [VGA controller])
        Subsystem: NVIDIA Corporation Device 10a2
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at f0000000 (64-bit, prefetchable) [size=32M]
        Expansion ROM at f7000000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 3
             Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0000# PME(D0-,D1-,D2-,D3hot-,D3cold-)
             Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
             Address: 00000000fee00000  Data: 0000
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [250] Power Budgeting <?>
        Capabilities: [2b0] Latency Tolerance Reporting
             Max snoop latency: 0x1ff
             Max no snoop latency: 0x1ff
        Capabilities: [2c0] L1 PM Substates
             L1Sub L1.2: 60 usec, AuxCurrent=0x2ff
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
The -vvv level dumps the full PCI configuration space (requiring root privileges for extended areas), revealing capabilities like and express endpoint details for deeper analysis. Note that outputs assume standard configurations and vary by system hardware, such as an GPU identified by : 10de:1c03.

Related Tools

For Other Buses

The primary analog to lspci for USB buses is the lsusb command, which lists USB connected to the system and provides details on bus , and product IDs, and descriptors. Similar to lspci, lsusb supports options for customized output; for instance, the -v flag enables to display comprehensive configuration and interface descriptors, while -t shows a of the USB . This tool is particularly useful for diagnosing USB host controllers and peripherals, revealing the hierarchical structure of hubs and attached rather than the flat enumeration of PCI slots seen in lspci output. Unlike , which typically involves fixed slots enumerated at boot, USB buses emphasize dynamic host controllers and hot-pluggable devices, with lsusb querying the via the filesystem (/sys/bus/usb/devices) and udev's hardware database for enriched details like human-readable names. The older /proc/bus/usb interface, once used for similar purposes, has been deprecated in favor of for better integration with modern device management. lsusb is included in the usbutils package, maintained as part of the USB project. To reflect changes from hot-pluggable devices, lsusb must be rerun after connection or disconnection—a capability enabled by the system's hotplug mechanisms but requiring manual invocation, similar to lspci for static scanning. For other non-PCI buses, tools like lsblk provide insights into block devices across various interfaces such as , , or NVMe, displaying a tree of disks, partitions, and filesystems without focusing solely on bus hardware. Similarly, the lspcmcia command, now deprecated due to the obsolescence of PCMCIA () technology in favor of more modern standards like ExpressCard, was historically used to list and inspect PCMCIA sockets and inserted cards.

Comprehensive Hardware Tools

In addition to specialized tools like lspci, several comprehensive hardware utilities on systems aggregate information from multiple sources, including PCI devices, to provide a broader overview of system hardware. These tools are particularly useful for system inventory, diagnostics, and scripting, as they probe diverse components such as (Desktop Management Interface), USB, and data, unlike lspci's exclusive focus on the PCI bus. hwinfo is an open-source tool developed by the project that probes and reports on all detectable hardware in the system. It generates detailed output on components like CPUs, , , and peripherals, with a dedicated PCI section accessible via the --pci flag, which lists devices in a format similar to lspci but includes additional details such as driver modules and interrupt assignments. Beyond PCI, hwinfo excels in sensor monitoring and information, making it valuable for troubleshooting thermal issues or configurations. Lshw (Hardware Lister) offers a hierarchical, tree-like representation of hardware, categorizing devices by class with options like -C network to filter for network interfaces or -C display for graphics cards, including PCI-based ones. It supports output formats such as JSON or XML via -o json or -o xml, facilitating integration into scripts or automated reports, and aggregates data from sources like /proc, sysfs, and PCI configuration spaces. Full access to certain details, such as exact memory configurations or firmware versions, typically requires root privileges, as non-privileged runs may omit sensitive or kernel-restricted information. For concise overviews, the -short option produces a compact list suitable for quick inventory checks. While both tools overlap with lspci in PCI enumeration, they differ in scope and origin: hwinfo, tied to 's ecosystem, emphasizes real-time probing and extensibility through its libhd library, whereas lshw is a portable, standalone utility designed for cross-distribution use with a focus on structured, parseable output. These aggregators enable holistic hardware audits without needing multiple single-bus tools, such as lsusb for USB devices.

Alternatives on Other Platforms

Windows

On Windows, there is no direct equivalent to the Linux lspci command for listing PCI devices, as the operating system relies on its integrated (PnP) Manager to handle hardware enumeration and device management. The Manager, introduced with , uses bus drivers like Pci.sys to detect and configure devices during system startup or hot-plug events, assigning device instance IDs that begin with "PCI" for identification. The primary graphical interface for viewing devices is , accessible via the devmgmt.msc or the . devices appear categorized under sections such as System devices (for controllers and bridges), Network adapters (for Ethernet or cards), or Display adapters (for GPUs), with expandable entries showing vendor and device details. Right-clicking a device in opens its Properties dialog, where the Driver tab displays installed driver details, including version, date, and provider, allowing users to update, roll back, or uninstall drivers as needed. For command-line enumeration, the built-in pnputil utility can list PCI devices using the syntax pnputil /enum-devices /bus [PCI](/page/PCI), which outputs device instance IDs, status (e.g., OK or Error), and class information for all devices on the PCI bus. Alternatively, the WMI Command-line tool (wmic), available up to , queries the Win32_PnPEntity class with wmic path Win32_PnPEntity where "DeviceID like '%PCI%'" get Name,DeviceID to retrieve names and IDs of PCI-related hardware. However, wmic has been deprecated and is removed by default in version 25H2 (released in 2025) and later, as well as in 2025; it can be installed as a Feature on Demand if needed, but is recommended for new scripting. Another command-line option is DevCon.exe, a utility from the (WDK), which provides detailed management including enumeration. For example, devcon hwids PCI lists hardware IDs for all PCI devices, offering functionality similar to lspci for identifying vendors and devices. DevCon must be downloaded separately as part of the WDK. PowerShell provides a modern scripting alternative through the Get-PnpDevice cmdlet, which can filter present PCI devices with Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -like "PCI*" }, returning like status, , friendly name, and instance ID for automation tasks. This leverages the (WMI) infrastructure, enabling detailed queries via the CIM cmdlets for integration with enterprise management tools.

Unix-like Systems

On Unix-like systems outside of Linux, such as BSD variants, macOS, and Solaris, lspci-like functionality for enumerating PCI devices is provided through native command-line tools that interface with the operating system's layers, though these tools often emphasize broader system configuration or device tree exploration rather than PCI-specific details alone. In BSD variants, tools vary by system. For , the pciconf utility serves as the primary equivalent to lspci, offering a to the bus via the pci(4) mechanism for querying device information. The -lv option provides verbose output similar to lspci -v, displaying details such as device class, vendor ID, device ID, and subsystem information for all devices on the system; for example, running pciconf -lv lists entries like vgapci0@pci0:0:2:0 with associated driver and resource details. This tool leverages the underlying device tree infrastructure, with related functionality accessible via devinfo(8) for a hierarchical view of all devices, including nodes. For , pcidump displays device addresses, vendor, and product names. In , pcictl provides similar bus manipulation and listing capabilities. Ports of the pciutils package, including lspci, are available for these systems. For SCSI-attached devices, which may appear under the bus, uses camcontrol from the Common Access Method () subsystem to manage and query SCSI targets, such as with camcontrol devlist to enumerate connected drives and their bus paths. macOS, built on a Darwin foundation with the IOKit framework for kernel-level hardware access, lacks a native lspci equivalent but provides PCI enumeration through system_profiler and ioreg commands in the Terminal. The system_profiler SPPCIDataType command generates a detailed report of PCI devices, including slot locations, speeds, and connected peripherals, akin to a basic lspci output; for instance, it might show entries like "Slot: PCI Slot 0, Type: PCIe, Speed: 8 GT/s, Width: x16" for graphics cards or network adapters. For a tree-structured view of the hardware hierarchy, ioreg -p IODeviceTree displays the IOKit registry, allowing users to navigate PCI nodes under the root device tree, such as filtering for "pci" to reveal bus addresses and compatible drivers. Users seeking closer lspci parity can install the pciutils package via Homebrew, which ports the Linux toolset including lspci for direct compatibility, though it requires building against macOS's libpciaccess or similar libraries. Solaris offers less PCI-centric tools, focusing instead on general system configuration and dynamic reconfiguration, with prtconf -vp providing verbose output that includes PCI device paths, node names, and properties like assigned memory ranges. For example, prtconf -vp might reveal PCI slots under /devices with details such as "reg: 00.0.0" for bus-device-function addressing and driver bindings, though it encompasses the entire device tree rather than isolating PCI. The cfgadm command complements this for hot-pluggable PCI/PCIe devices, listing attachment points and status (e.g., cfgadm -lac shows connected PCI slots with types like "pcie"), but it primarily targets reconfiguration rather than comprehensive enumeration. These tools reflect Solaris's emphasis on enterprise hardware management over standalone PCI diagnostics.