Read Linux's I/O Memory Map Safely with /proc/iomem

Chasing a PCI resource conflict usually starts with one question: what does the kernel actually think owns this address range. /proc/iomem answers it directly. By the end of this guide you can inspect the live I/O memory map, follow its parent-and-child layout, and tell a genuinely useful map apart from output that has been deliberately restricted. It takes about five minutes and needs only an ordinary shell account; reading /proc/iomem does not normally need sudo.

1. Check that the file exists

/proc is a kernel-provided pseudo-filesystem, not a directory of ordinary files on disk. This particular file can be missing on a system without the relevant proc entry, or when procfs is not mounted at all. Check it before trying to interpret anything in it:

test -r /proc/iomem && echo "readable: /proc/iomem" || echo "not readable: /proc/iomem"

Expected output on a usual Linux installation:

readable: /proc/iomem

If it says the file is not readable, check the mount first:

findmnt /proc

An absent or unmounted procfs is an environment problem, not a malformed memory map. Do not create a regular file at /proc/iomem: procfs entries come from the kernel and cannot be patched into existence that way.

2. Read the live map

Print the file directly. This has no device-side effect and changes no kernel setting:

cat /proc/iomem

A machine with visible resource addresses might produce output shaped like this:

00000000-00000fff : Reserved
00001000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
  000a0000-000bffff : framebuffer
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM

Exact ranges, names and indentation belong to the running kernel and hardware in front of you. Treat the values as an observation, never as a portable configuration file: a reboot, a firmware change, a virtual machine reconfiguration or a driver change can all alter them.

3. Read the indentation as ownership

Each line names a resource range followed by an owner label. A line with leading spaces is a child of the nearest less-indented entry above it. In the example, framebuffer sits inside the video RAM range, which is exactly what makes this output useful when you need to see which kernel component has claimed part of a larger region.

Keep the raw hierarchy while you search. For a quick view of entries mentioning RAM or PCI, use:

grep -E 'System RAM|RAM buffer|PCI|Reserved' /proc/iomem

That filter is only a convenience. It strips away the context indentation gives you, so go back to the full output before deciding a resource is free or conflicting.

4. Verify what your host actually exposes

Some kernels or execution environments restrict the address information this file shows. On this host, for example, the structure and labels are present but every printed range reads 00000000-00000000. That is valid, observable output, but it is not a usable physical address map.

Check the first few lines without assuming non-zero addresses will be available:

sed -n '1,20p' /proc/iomem

If the ranges come back zeroed, do not conclude the machine has no RAM, PCI devices or firmware regions. It only means this view is restricted or sanitised in the current environment, which could come from the kernel, a security policy, a virtual machine boundary, or the host providing the environment. Switching to sudo is not a guaranteed remedy here, and this file is not a request to disable any security control.

5. Avoid the common file-size trap

Because this is a pseudo-file, its metadata is not a reliable description of how much text it will return. For example:

stat -c 'mode=%A size=%s bytes' /proc/iomem
wc -l < /proc/iomem

It is completely normal for stat to report a size of zero while reading the file still returns plenty of lines. Use the actual read, not the reported byte count, to test whether a map is available. If you need to keep an audit snapshot, save it explicitly and record the kernel and machine context alongside it:

snapshot="/tmp/iomem-$(date +%Y%m%d-%H%M%S).txt"
cat /proc/iomem > "$snapshot"
uname -a
printf 'saved %s\n' "$snapshot"

This only writes under /tmp. Remove the snapshot later with rm -- "$snapshot" once you no longer need it, and do not treat a saved map as proof of current state after a reboot or hardware change.

6. Keep the boundary clear

/proc/iomem is for inspection only. It does not allocate memory, reserve a range, bind a driver or change firmware. Do not edit it with a text editor, redirect output back into it, or treat a label such as Reserved as permission to reuse that range: resource ownership is enforced by the kernel and drivers, never by the text you happen to see.

For a driver or hardware investigation, compare this map against the relevant kernel logs and device-specific interfaces, then reproduce the observation after making the relevant change. One line in this file can never prove a device is healthy or that a physical address is safe to touch.

Done means