Home / Alt manpages / proc_dma(5)

  • proc_dma(5)
  • File format
  • linux

Read ISA DMA Channel State from /proc/dma

Old hardware sometimes still leans on legacy ISA DMA, and /proc/dma is the quickest way to see which channels the kernel currently thinks are in use. This guide inspects which ISA DMA channels the running Linux kernel currently reports as registered, without touching hardware or kernel configuration. The useful result is a short, point-in-time listing such as 4: cascade. Allow about five minutes. You need a shell account that can read procfs; root is normally unnecessary.

What this file tells you

/proc/dma is a procfs status file for ISA direct memory access channels. The local proc_dma(5) page describes it as a list of registered ISA DMA channels in use. It is an observation of the running kernel, not a configuration file and not a complete inventory of every modern bus or device.

The manpage installed here comes from Linux man-pages 6.7, package version 6.7-2. The kernel running this machine is 6.8.0-139-generic. That combination matters when comparing output with another host: the file reflects the host kernel and its drivers, while the wording comes from the man-pages package.

1. Read the current listing

Run this as your ordinary user:

cat /proc/dma

On this machine the output is:

 4: cascade

The number before the colon is the DMA channel, and the text after it is the registered owner or description. Here, channel 4 is the cascade channel used to connect the two parts of the traditional ISA DMA controller. Spacing at the start of a line is harmless; preserve the value after the colon when recording or comparing results.

Checkpoint

You're done with the inspection when cat exits successfully and you've captured the output. Do not edit the path with a text editor: procfs presents kernel state through a virtual file interface, so there is no normal file to save over.

2. Check whether the result is empty

An empty result is still a result. It means the running kernel hasn't exposed a registered ISA DMA channel in this view at that moment. It doesn't prove every device is absent, that PCI devices are broken, or that DMA is disabled globally. Many current systems don't use legacy ISA DMA for their main devices at all.

Use a command that makes the exit status and byte count visible:

if [ -r /proc/dma ]; then
    bytes=$(wc -c < /proc/dma)
    printf 'readable, %s bytes\n' "$bytes"
    cat /proc/dma
else
    printf '%s\n' '/proc/dma is not readable' >&2
    exit 1
fi

Expected output for the example host is similar to:

readable, 12 bytes
 4: cascade

The byte count can differ, since kernels and procfs formatting can change. Treat it as a diagnostic, not a stable interface contract.

3. Compare two readings safely

Because this is live kernel state, a driver can register or release a channel between two reads. If you're investigating a report, take two readings and compare them without modifying the system:

cat /proc/dma
sleep 1
cat /proc/dma

For a compact comparison, capture each read in temporary files under /tmp:

first=$(mktemp /tmp/proc-dma.XXXXXX)
second=$(mktemp /tmp/proc-dma.XXXXXX)
trap 'rm -f "$first" "$second"' EXIT
cat /proc/dma > "$first"
sleep 1
cat /proc/dma > "$second"
diff -u "$first" "$second"

No output from diff means the two snapshots matched. A difference means the reported registrations changed during the interval; it doesn't by itself identify which driver was responsible.

4. Put an unexpected line in context

First, check the kernel release and the procfs mount before comparing a host with documentation or a support ticket:

uname -r
findmnt -T /proc/dma -o TARGET,FSTYPE,OPTIONS
cat /proc/dma

findmnt is a separate util-linux command and may not be installed on a very small system. If it's missing, mount | grep ' on /proc ' is a less precise fallback. Neither command changes state.

Do not infer ownership of a channel from a nearby device name, and don't treat the file as a replacement for PCI or platform-bus diagnostics. If the question concerns a particular device, use that device's documented diagnostic interface as well. /proc/dma only reports the ISA DMA registrations described by proc_dma(5).

Common traps

  • Trying to write the file. Do not use redirection, tee or an editor against /proc/dma. Reading it is the supported operation described by the manpage; a failed write does not repair or reassign a channel.
  • Adding sudo automatically. Reading normally needs no elevated privilege. If access is denied, check the procfs mount and local policy first: elevation won't make an unregistered ISA channel appear.
  • Expecting a device list. The output is a channel-registration list, not a general hardware inventory. An empty file can be normal on hardware that doesn't use ISA DMA.
  • Parsing the text as a permanent API. Scripts should tolerate no lines, multiple lines and formatting changes. Do not hard-code channel 4 as proof that a particular device is working.

Done means

  • Read /proc/dma without changing system state.
  • Recorded the kernel release alongside the snapshot.
  • Can distinguish an empty listing from an unreadable procfs path.
  • Didn't overreach: no unsupported claims about non-ISA devices.