Home / Alt manpages / pci.ids(5)

  • pci.ids(5)
  • File format
  • linux

Decode lspci Output with the pci.ids Database

pci.ids is the file that turns lspci's cryptic hex codes into the vendor and device names you actually recognise. This guide uses it to explain real lspci output, inspect a genuine record, and understand the file's hierarchy before you consider updating it. Examples match pciutils 3.10.0, installed here as package version 1:3.10.0-2build1. Allow about fifteen minutes; you need a shell and the pciutils package, and every step here is unprivileged.

pci.ids is a lookup list, not a hardware configuration file. Your PCI hardware reports numeric identifiers; the PCI utilities use this text database to turn them into readable names. Edit a name and you change the display text, not the device, the driver, or the kernel configuration.

1. Confirm the database and the utility

The installed list normally lives at /usr/share/misc/pci.ids. Check the package and the file before you trust anything it tells you:

$ dpkg-query -W -f='${Package} ${Version}\n' pciutils
pciutils 1:3.10.0-2build1
$ command -v lspci
/usr/bin/lspci
$ ls -l /usr/share/misc/pci.ids
-rw-r--r-- 1 root root ... /usr/share/misc/pci.ids

Size, owner and timestamp will differ machine to machine. What matters is that the package is installed, lspci resolves, and the list actually exists. On another distribution, swap in its own package query command, but keep the file path from the installed pci.ids(5) documentation in mind.

Checkpoint

If the file is missing, stop here and repair or reinstall the package through your normal package manager. Don't fake a replacement in /usr/share/misc just to make a later command look like it worked.

2. Compare numeric IDs with their readable form

Ask lspci for both the names and the raw numeric IDs:

$ lspci -nn | head -n 3
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:591f] (rev 05)
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04)
00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] (rev 31)

Your hardware will produce different lines entirely. In a record like [8086:5912], 8086 is the vendor ID and 5912 the device ID; the bracketed 0300 is the class and subclass pair that lspci shows alongside it. The database supplies names for these numbers; it never discovers or changes them.

Don't trust the first match in a copied log as proof your current machine has that device. Re-run lspci -nn on the machine you're actually investigating, then use the exact hex values from that fresh output.

3. Find the vendor and device records

Read-only searches are the quickest way to connect output to file. Use fixed strings and tabs so a device line never gets confused with a vendor line:

$ grep -n '^8086 ' /usr/share/misc/pci.ids
27868:8086  Intel Corporation
$ grep -n $'^\t5912 ' /usr/share/misc/pci.ids
35156:	5912  HD Graphics 630

The file uses four hex digits, followed by one or more spaces. Vendor lines start at column one; a device line starts with one TAB and belongs to the vendor above it. Names run to the end of the line, so never split one on spaces when writing a parser.

A search can return more than one hit, because the same device number can appear under different vendors. Keep the vendor context and match the whole pair from lspci, never the device number alone.

4. Read subsystems without losing the hierarchy

A subsystem identifies the assembly around a device, such as an add-in card built around an Ethernet controller. Its record carries two TAB characters, then a subsystem vendor ID and subsystem ID:

$ sed -n '27860,27875p' /usr/share/misc/pci.ids
...
8086  Intel Corporation
	0001  82371AB/EB/MB PIIX4 ISA
	...
		1028 00b4  OptiPlex GX1
...

The exact nearby entries vary by database version, so treat those ellipses as a visual cue, not text to paste. The shape that matters is: vendor, then a one-TAB device, then a two-TAB subsystem. A subsystem line's first four-digit value must name a vendor listed elsewhere in the file; the second is the subsystem ID, with the name filling out the rest of the line.

Subsystem meaning is device-dependent. Don't assume a subsystem ID means the same thing for a different device just because the digits look familiar.

5. Interpret class and programming-interface records

Class data lives separately from vendor and device data. A class starts with C, one space, and a two-digit hex class ID; its subclass takes one TAB, its programming interface two:

$ sed -n '37940,37948p' /usr/share/misc/pci.ids
C 03  Display controller
	00  VGA compatible controller
		00  VGA controller
	01  XGA controller

For the earlier 0300 example, 03 selects the display-controller class and 00 its VGA-compatible subclass. A programming interface is an extra two-digit value where that subclass defines one. This is why a class lookup is never written as a vendor/device record, and why indentation carries real meaning here.

The file also holds device-independent subsystem groups starting with S, which reuse an already-listed subsystem vendor and then list one-TAB subsystem entries. Not every useful record sits under a device.

6. Validate a local copy before proposing a change

Leave the package-managed file alone while you experiment. Copy it somewhere temporary, inspect the copy, then clean up:

$ workdir=$(mktemp -d)
$ cp -- /usr/share/misc/pci.ids "$workdir/pci.ids"
$ grep -n '^8086 ' "$workdir/pci.ids"
27868:8086  Intel Corporation
$ rm -- "$workdir/pci.ids"
$ rmdir -- "$workdir"

That final cleanup is safe because it only touches a directory you just created; never substitute a broader path for $workdir. To propose a missing ID, keep the surrounding vendor and device context and match the documented indentation exactly. Review the change as data first: a stray typo can make a name disappear or attach a subsystem to the wrong parent.

Warning

Do not edit /usr/share/misc/pci.ids in place as a quick fix. It's package-managed data, and the next package update can wipe out a local edit without warning. If the list is missing an identifier, the manpage points contributors at the PCI ID database, pci-ids.ucw.cz. Updating the installed list with update-pciids is a system change: review the command and your distribution's package policy first, and reach for elevated privileges only if your installation actually requires them.

7. Recheck after an update

Once your package manager or approved process has updated the list, repeat the same read-only checks. Compare the file's version header, then reverify the exact record you care about:

$ sed -n '1,8p' /usr/share/misc/pci.ids
$ grep -n '^8086 ' /usr/share/misc/pci.ids
$ lspci -nn | grep -F '[8086:5912]'

A newer list can improve a displayed name without changing lspci's numeric IDs at all. If a name is still missing, check that you searched the file the installed utilities actually use, and that vendor and device values were copied in the right order. Use lspci -q for an online database query, as pci.ids(5) documents; treat network results as a separate source from the local, reproducible file.

Done means

  • Version confirmed. The installed pciutils version and the /usr/share/misc/pci.ids path are known.
  • ID matched properly. An lspci -nn line was matched by its full vendor and device pair, not a device number alone.
  • Hierarchy understood. Vendor, device, subsystem and class records are distinguished by leading text and TAB indentation.
  • Changes tested safely. Any proposed edit was tried in a temporary copy, leaving the package-managed file untouched.
  • Update verified. After an approved update, the file header, the exact record, and lspci output were all rechecked.