SystemIO conflicts are not firmware bugs

Matthew Garrett's Blog
Power management, mobile and firmware developer on Linux. Security developer. Ex-biologist. Content here should not be interpreted as the opinion of my employer.

Home

Archives

Search

Links

RSS

Dark Mode

SystemIO conflicts are not firmware bugs

Sep 09, 2026

6 minute read

I’m looking at something entirely unrelated, but tripped over some search results that made me realise that a lot of people still think getting errors like ACPI Warning: SystemIO range 0x0000000000001828-0x000000000000182F conflicts with OpRegion 0x0000000000001800-0x000000000000187F indicate a firmware bug. This is generally untrue. We need to dive a little into what ACPI is to clarify why.
The Advanced Configuration and Power Interface1 specification defines a whole bunch of stuff, but what’s interesting to us here is the hardware abstraction it performs. While PCs are nominally a well-defined platform that’s really not true at the hardware level once you get beyond a certain level of complexity. When you suspend a system you want to power down the hardware in the correct order, for instance, and knowing what that order is requires you to know details about the specific motherboard design. The approach taken in the embedded world is to just bake that knowledge into the OS in some form, which is how we end up with Devicetree. ACPI takes an alternative approach - rather than provide that information as data that has to be consumed by OS drivers, it distributes it as code.
The ACPI Source Language, or ASL, is a simple language that gets compiled into a bytecode that’s then interpreted by the OS at runtime. One of the features of this language is the ability to define “Operation Regions”, effectively structure definitions that describe access to underlying hardware. Let’s imagine a simple device with two exposed registers. The first is an index register - it describes which internal register we want to access. The second is a data register, where reading it gives us the value of the internal register whose address is currently in the index register, and writing to it modifies that register. An example operation region declaration would look something like

1
2
3
4
5
6

OperationRegion(OPR1, SystemIO, 0x400, 0x2)
Field(OPR1, ByteAcc, NoLock, Preserve)
{
INDX, 8
DATA, 8
}

This defines an operation region called “OPR1” at IO port 0x400, 2 bytes long. Inside it are two 8-bit fields, INDX and DATA. These are to be accessed one at a time, do not need the ACPI interpreter to take a global lock when accessing them, and if a subset of the register is modified then the other values should be preserved (irrelevant in this case since the fields are only a byte wide). Now any references to INDX or DATA in this scope will trigger accesses to those registers. So, a method to read the value of register 0x03 would look something like:

1
2
3
4

Method (RD03) {
INDX = 0x3
Return (DATA)
}

ie, set INDX to 3, and then read the value of DATA and return it. But! What if another ACPI method is running at the same time? Let’s say we have one that writes to register 0x05:

1
2
3
4

Method (WR05, 1) {
INDX = 0x05
DATA = Arg1
}

What happens if RD03 executes while we’re part-way through WR05? INDX might get reset to 0x03, and now WR05 will modify register 0x03 instead of 0x05. Oh no! But we can avoid this - we declare a mutex (Mutex (MUTX, 0x00)), and update our methods to be something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Method (RD03) {
Acquire (MUTX, 0xFFFF)
INDX = 0x3
Local0 = DATA
Release (MUTX)
Return (Local0)
}

Method (WR05, 1) {
Acquire (MUTX, 0xFFFF)
INDX = 0x05
DATA = Arg1
Release (MUTX)
}

Each method takes a lock (waiting up to 0xffff milliseconds and then erroring out if it doesn’t), and performs the access. There’s now no chance of a race. Phew!
Now suppose someone writes a Linux driver for this piece of hardware. It accesses the hardware directly, with no knowledge of ACPI. What stops the driver from racing against one of the ACPI access methods? Nothing at all. Oh no! Again! This isn’t hypothetical, by the way - here’s a relatively harmless example, but back in the day we did trip over cases where temperature monitoring chips would be accessed by the firmware and Linux simultaneously and as a result you might end up thinking you’re reading a temperature when you’re actually reading a status flag, resulting in an impossibly high temperature and an immediate thermal shutdown.
In this case, the kernel saves you from this (potentially hardware damaging) outcome by printing a message like ACPI Warning: SystemIO range 0x0000000000000400-0x000000000000401 conflicts with OpRegion 0x0000000000000400-0x0000000000000401 (OPR1), telling you that the kernel has detected that a driver is attempting to allocate IO ports 0x400-0x401, but that there’s an ACPI operation region called OPR1 that is claiming the same addresses. The kernel isn’t in a position to know what type of access the firmware might perform in that region, so assumes that it might be dangerous and blocks the driver from loading.
But all is not lost! The kernel also prints some helpful advice, ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver. And ACPI tables will often actually have a definition that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Device (HDW1)
{
Name (_HID, "VEND0001")
OperationRegion(OPR1, SystemIO, 0x400, 0x2)
Field(OPR1, ByteAcc, NoLock, Preserve)
{
INDX, 8
DATA, 8
}
Mutex (MUTX, 0)
Method (RD03) {
Acquire (MUTX, 0xFFFF)
INDX = 0x3
Local0 = DATA
Release (MUTX)
Return (Local0)
}

Method (WR05, 1) {
Acquire (MUTX, 0xFFFF)
INDX = 0x05
DATA = Arg1
Release (MUTX)
}
}

which defines an ACPI device and associated methods. The _HID field defines the device type, and a Linux driver can be written that will be automatically loaded if a device with type VEND0001 is seen. That driver can then call ACPI methods associated with the device and access the resources in a way that matches the firmware’s expectations.
(Interested in writing such a driver? I wrote a guide back in 2009)
The firmware did absolutely nothing wrong here2, but trying to load the native driver will generate an error and the internet will tell you that PC firmware developers are incompetent3 and you should pass a kernel argument that overrides this behaviour and it never did them any harm, and it probably won’t do you any harm either but it might and you might never know why your system occasionally wedges or catches fire.

The ACPI spec used to live at acpi.info, but sadly that seems to have vanished some time after UEFI took over stewardship of the spec ↩︎

You might argue that the firmware should simply not do anything at runtime because it is not the firmware’s job to do that, and I do understand that and you can certainly boot with acpi=off if you want to and no ACPI code will be executed at runtime. Let me know how that goes. ↩︎

I’m not going to present an opinion on that here, merely say that this provides no supporting evidence for that assertion ↩︎

©

2026 Matthew Garrett's Blog

Built with Hugo
Theme Stack designed by Jimmy

SystemIO conflicts are not considered firmware bugs. The author argues against the common assumption that errors, such as ACPI warnings about SystemIO range conflicts, necessarily indicate a firmware defect. To understand this, the text delves into the design philosophy of the Advanced Configuration and Power Interface (ACPI) specification and how it contrasts with embedded approaches to hardware abstraction. While ACPI structures information by distributing it as executable code, such as the ACPI Source Language, which is compiled into bytecode interpreted by the operating system, embedded systems typically bake this knowledge directly into the operating system, as seen in Devicetree.

ACPI utilizes Operation Regions to structure definitions that describe access to underlying hardware. This mechanism involves defining access to device registers through indexes and data fields. The text illustrates how these regions define specific memory areas and the fields within them, specifying that some accesses can occur without requiring a global lock, and that modifications to a subset of a register should preserve other values. To manage concurrent access and prevent race conditions between different ACPI methods, the specification incorporates mutexes. Methods are required to acquire a lock before performing access to shared resources and release it afterward, ensuring sequential execution and preventing inconsistencies.

A conflict scenario arises when a native hardware driver interacts directly with hardware registers without being aware of the ACPI methods. This direct interaction leaves the driver vulnerable to racing against ACPI execution paths, which could lead to incorrect data reads—for example, reading a status flag instead of an actual sensor reading, potentially resulting in catastrophic errors like thermal shutdowns. The kernel mitigates this risk by detecting these potential conflicts, such as a driver attempting to access an address claimed by an ACPI operation region. When such a conflict is detected, the kernel blocks the driver execution and issues a warning, indicating the conflict and suggesting the use of available ACPI drivers instead of native ones.

The ACPI structure itself defines devices and their associated methods, which provide a framework for drivers to interact with the hardware in a structured manner. For instance, a device definition specifies an OperationRegion, method definitions, and mutexes. This structure allows a Linux driver to be automatically loaded if the hardware matches a specified type, enabling the driver to call these ACPI methods to access resources in a way that aligns with the firmware’s expectations. Although the author notes that running ACPI code is optional and that the firmware itself is not strictly at fault, attempting to load native drivers without acknowledging the ACPI structure can result in unpredictable and potentially dangerous system states, which the operating system is designed to guard against.