Home / Alt manpages / proc_pci(5)

  • proc_pci(5)
  • File format
  • linux

Check PCI Procfs Availability Without Confusing Old and New Interfaces

You will establish whether the legacy /proc/pci file exists, inspect the replacement PCI procfs interface when it does not, and record 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 require root.

This guide 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. The distinction matters: this is a description of an old, optional interface, not a command that enables PCI support.

1. Check the legacy file directly

Start with the path named by the manual page. Use a test rather than assuming that 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 that 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.

Checkpoint: if your check prints /proc/pci exists, read it without modifying anything:

$ 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 manual records the interface's history. It became optional in Linux 2.2 when CONFIG_PCI_OLD_PROC was introduced, was enabled again in Linux 2.4, and was deprecated in Linux 2.6. It was still available with CONFIG_PCI_LEGACY_PROC, then was removed altogether from Linux 2.6.17 onwards.

That history gives a more useful interpretation of the first check. A missing /proc/pci normally means the running kernel does not provide the legacy interface. It does not mean that 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 that 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.

5. Handle common diagnosis mistakes

Do not use sudo as the first response to a missing /proc/pci. Elevated privileges cannot recreate an interface removed by the kernel. Use root only when a separate, device-specific inspection command reports that its own access policy requires it.

Do not create a file called /proc/pci elsewhere and call it a repair. Applications that require the old format need to be updated or run with a kernel that deliberately provides the legacy interface, which is a kernel selection and compatibility decision. It is not a safe runtime tweak.

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. This preserves the difference between missing legacy data and an empty or unreadable current view.

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.

Done means

  • You checked /proc/pci instead of assuming it exists.
  • You recorded the running kernel version alongside the result.
  • You distinguished a missing legacy interface from missing PCI hardware.
  • You checked /proc/bus/pci/devices as the replacement procfs view.
  • You inspected binary device entries only when a specific device required investigation.
  • You made no changes to kernel configuration, device state, services or files under /proc.