The ACPI Subsystem – The Bridge Between Firmware and Linux

Introduction: The Invisible Translator

When you press “Sleep” on your laptop, you expect magic: the screen goes dark, fans stop, and later everything returns exactly as you left it. But behind that smooth transition is a delicate dance between your hardware firmware and the Linux kernel.

That dance is choreographed by ACPI — the Advanced Configuration and Power Interface. It’s a set of standards and tables that let your operating system talk to your hardware about power and configuration. Without it, Linux would have no idea how to power down a GPU, save your USB controller’s state, or wake up your system after you close the lid.

Think of ACPI as the bridge between your system’s firmware (BIOS/UEFI) and Linux. On one side, the firmware knows your hardware intimately. On the other, Linux wants to manage power efficiently but needs instructions. ACPI is the dictionary both sides use.

1. Where ACPI Lives: Tables Inside Firmware

When your machine boots, the BIOS/UEFI hands Linux a package of ACPI tables — tiny data structures and bytecode describing your hardware and how to control it. The key ones include:

DSDT (Differentiated System Description Table): The main script of ACPI, describing devices and their control methods.
SSDT (Secondary System Description Table): Adds or overrides parts of DSDT for modularity.
FACP (Fixed ACPI Description Table): Contains fixed hardware info (like power buttons).

These tables live inside firmware. Linux doesn’t invent them — it parses them.

2. The Kernel’s ACPI Interpreter

In the Linux source tree, drivers/acpi/ is where the magic happens. This code loads the ACPI tables at boot and interprets them. Each device described in ACPI (like PCIe slots, Wi-Fi, GPUs, USB hubs) comes with “control methods” — small pieces of ACPI bytecode that tell Linux:

_OFF: How to power down the device.
_ON: How to re-enable the device.
_SST: How to save its state.
_PRW: How and when it can wake up.
_PTS: What to do before entering a sleep state.

Linux uses these to know exactly which registers to write to or which sequence to follow before cutting power. Without this, suspend/resume would be guesswork.

3. A Walk Through Suspend: Step by Step

Let’s trace what happens when you close your laptop lid:

logind → systemd → kernel → pm_suspend()
Your desktop environment tells logind, which notifies systemd, which calls the kernel’s pm_suspend() interface.
kernel → acpi_bus_sleep()
The kernel begins the sleep sequence, calling each device’s _Sx method as defined in ACPI (S3 for suspend-to-RAM, S4 for hibernate).
device drivers → acpi_device_sleep_state()
Each device driver invokes its own callbacks, often using ACPI methods like _OFF or _SST to save device state.
systemd → /usr/lib/systemd/system-sleep/
Before the actual sleep, systemd runs any scripts in this folder. These are hooks for admins to do pre-sleep tasks (like unmounting drives or turning off LEDs).
kernel → freezes user-space
The kernel pauses processes, disables interrupts (IRQs), and tells the memory controller to keep refreshing RAM so your data isn’t lost.
systemd → powers off devices
systemd coordinates with the kernel to turn off display, USB, PCIe, Wi-Fi, GPU — all following the instructions from ACPI tables.
hardware enters S3
Finally, the machine is in low-power sleep. Only RAM and essential wake sources are powered.

4. A Walk Through Resume: Step by Step

Now let’s walk through the reverse — what happens when you open the lid or press the power button:

Wake event → firmware catches it
A keypress, lid-open sensor, USB event, or network packet triggers wake-up. Firmware receives the signal and re-enables power rails.
Power rails restore
CPU cores, PCIe lanes, USB hubs, and the memory controller come back online. RAM was never lost, so the system state is still there.
Firmware hands control back
BIOS/UEFI initializes just enough hardware to let the OS resume, and ACPI tables remind the kernel that this is not a cold boot.
kernel → device wake sequence
The kernel’s ACPI interpreter calls each device’s _ON or resume methods. Drivers run callbacks to reinitialize their hardware.
Memory context intact
Because RAM stayed powered, the kernel verifies state and picks up where it left off. User-space processes remain frozen for the moment.
Interrupts and scheduler restored
The kernel re-enables interrupts, restarts its scheduler, and prepares to thaw processes.
systemd → post-resume scripts
systemd runs scripts in /usr/lib/systemd/system-sleep/ with the post argument. These can restart daemons, reload services, or re-initialize hardware.
User space thaws
The kernel unfreezes user processes. Apps continue exactly where they paused — editors, browsers, terminals, all intact.
Peripherals re-enabled
GPU restores display modes, USB and PCIe devices power back on, Wi-Fi reconnects, Bluetooth and audio return.
Back to desktop
Your login session, lock screen, or desktop appears. To you, it feels instant, but under the hood dozens of layers just worked in sync.

5. Why This Bridge Matters

If any layer here misbehaves — firmware with bad ACPI tables, a driver ignoring _OFF, or a broken system-sleep script — the whole chain breaks. That’s when you see:

Black screen after resume
Console login instead of desktop
Frozen X-server or kernel panic

Understanding ACPI helps you diagnose such problems. For example, if your Wi-Fi dies after resume, it may be the _PRW (power resources for wake) misconfigured in firmware or a driver not restoring state.

6. ACPI in Linux Commands You See

You don’t normally interact with ACPI directly. Instead, you use high-level commands like:

systemctl suspend
systemctl hibernate
systemctl hybrid-sleep

These trigger the chain above, eventually calling ACPI methods at the driver level.

You can inspect what ACPI thinks is available on your system with:

dmesg | grep -i acpi
ls /sys/firmware/acpi/tables

This shows the tables your firmware gave Linux.

7. Best Practices for Reliable ACPI

Keep BIOS/UEFI updated. Many suspend/resume issues vanish after a firmware upgrade.
Use vendor kernels or drivers. Laptop vendors sometimes patch ACPI quirks.
Test suspend/hibernate early. Don’t discover it’s broken when your battery is at 2%.
Check systemd-inhibit --list. Some apps may block suspend.

WHO                          UID  USER  PID  COMM            WHAT                                                     W>
ModemManager                 0    root  5412 ModemManager    sleep                                                    M>
NetworkManager               0    root  5278 NetworkManager  sleep                                                    N>
UPower                       0    root  6690 upowerd         sleep                                                    P>
Unattended Upgrades Shutdown 0    root  6015 unattended-upgr shutdown                                                 S>
GNOME Shell                  1000 pavel 8441 gnome-shell     sleep                                                    G>
pavel                        1000 pavel 8609 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-key G>
pavel                        1000 pavel 8609 gsd-media-keys  sleep                                                    G>
pavel                        1000 pavel 8611 gsd-power       sleep                                                    G>

Conclusion: ACPI as the Silent Hero

The ACPI subsystem is like a backstage crew during a theater performance. You don’t see them, but without them the show collapses. Every time your Linux system suspends or resumes, ACPI tables, kernel interpreters, systemd hooks, and device drivers work in sync to power devices down gracefully and bring them back to life.

By knowing about this bridge, you’re not only better prepared to troubleshoot suspend/resume problems — you also gain a deeper appreciation of the invisible layers that make your Linux machine behave so reliably.