Check /proc/pci Without Guessing at PCI Support

You expect /proc/pci to exist because an old how-to says so, and its absence looks like a broken PCI bus when it is really just a retired interface. This guide checks whether the legacy file exists, inspects the replacement PCI procfs interface when it does not, and records a useful diagnosis without changing kernel or device state. Allow about ten minutes.

You need a shell and read access to /proc; the normal checks do not need root. This follows the installed proc_pci(5) page from the manpages package, version 6.7-2. The running test machine uses Linux 6.8.0-139-generic.

1. Check the legacy file directly

Start with the path named by the manual page. Use a test rather than assuming a failed read means the machine has no PCI devices:

$ if [ -e /proc/pci ]; then
>     printf '%s\n' '/proc/pci exists'
> else
>     printf '%s\n' '/proc/pci is absent'
> fi
/proc/pci is absent

On this host, that is the expected result. The absence of /proc/pci is not evidence the PCI bus is empty. The file is a legacy listing of PCI devices found during kernel initialisation and their configuration, and modern kernels can remove it altogether.

$ sed -n '1,20p' /proc/pci

Keep the captured output with your diagnostic if an older application specifically requires this format. Do not write to the path and do not create a substitute file in /proc.

2. Understand why the file may be missing

The interface has a history worth knowing before you trust the first check's result:

• Became optional in Linux 2.2, when CONFIG_PCI_OLD_PROC was introduced.
• Was enabled again in Linux 2.4.
• Was deprecated in Linux 2.6, though still available with CONFIG_PCI_LEGACY_PROC.
• Was removed altogether from Linux 2.6.17 onwards.

A missing /proc/pci normally means the running kernel does not provide the legacy interface. It does not mean PCI support is absent, that a device driver has failed, or that installing the manpages package would create the file: the package supplies documentation, not a kernel interface.

Record the kernel version before comparing reports from different machines:

$ uname -sr
Linux 6.8.0-139-generic

The version is useful context, but it is not a complete test of a kernel configuration. Treat the filesystem check as the authority for what this running kernel actually exposes.

3. Inspect the replacement procfs interface

The proc_pci(5) page points readers towards /proc/bus/pci. Check that directory and its device listing:

$ ls -ld /proc/bus/pci /proc/bus/pci/devices
dr-xr-xr-x 4 root root 0 Sep 26 12:23 /proc/bus/pci
-r--r--r-- 1 root root 0 Sep 26 12:23 /proc/bus/pci/devices
$ sed -n '1,12p' /proc/bus/pci/devices
0000    8086591f    0               0               0
0010    80865912    b          ee000004               0
00a0    8086a12f    7c         ef020004               0

Your rows will differ. The important result is that the replacement interface is present and readable, not that a particular vendor ID, address or driver name appears. Do not copy the sample rows into a report as if they identify your hardware.

For a machine-readable existence check, keep the test narrow:

if [ -r /proc/bus/pci/devices ]; then
    printf '%s\n' 'PCI procfs device listing is readable'
else
    printf '%s\n' 'PCI procfs device listing is unavailable' >&2
    exit 1
fi

This is still only a procfs check. It does not identify every driver problem, prove a device is usable, or replace a tool that decodes PCI configuration for administrators.

4. Check a device-specific entry when needed

The directory can also contain entries grouped by PCI bus and device. List the entries before choosing one, because the names are hardware-dependent:

$ find /proc/bus/pci -maxdepth 2 -type f -print | sed -n '1,12p'
/proc/bus/pci/00/00.0
/proc/bus/pci/00/02.0

Read an entry only when you have a specific device to investigate:

$ od -Ax -tx1 -N 64 /proc/bus/pci/00/00.0
000000 86 80 1f 59 06 00 10 00 00 00 00 06 00 00 00 00
000010 ...

The output is binary configuration data, so od is a safer inspection command than opening it in a text editor. The exact bytes depend on the device. Reading it does not change the device, but avoid turning a broad hardware inventory into an uncontrolled loop on a production host.

Common traps

• Reaching for sudo first. Elevated privileges cannot recreate an interface removed by the kernel. Use root only when a separate, device-specific inspection command reports its own access policy requires it.
• Faking a fix. Do not create a file called /proc/pci elsewhere and call it a repair. Applications that need the old format have to be updated or run with a kernel that deliberately provides the legacy interface, which is a kernel selection and compatibility decision, not a safe runtime tweak.
• Conflating missing legacy data with an empty PCI bus. If a script currently treats a missing /proc/pci as "no PCI", change the condition to report the interface as unavailable, then check /proc/bus/pci/devices separately.

These examples are read-only, so there is no service restart or configuration rollback. If you have redirected output to a report file, remove or replace that report using your normal document-retention process: nothing in /proc needs undoing.