SystemIO conflicts are not firmware bugs

# SystemIO conflicts are not firmware bugs Source: [https://codon.org.uk/~mjg59/blog/p/systemio-conflicts-are-not-firmware-bugs/](https://codon.org.uk/~mjg59/blog/p/systemio-conflicts-are-not-firmware-bugs/) 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 Interface](https://uefi.org/specifications)[1](https://codon.org.uk/~mjg59/blog/p/systemio-conflicts-are-not-firmware-bugs/#fn:1)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](https://devicetree.org/)\. 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](https://bugzilla.kernel.org/show_bug.cgi?id=13620)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](https://lwn.net/Articles/367630/)back in 2009\) The firmware did absolutely nothing wrong here[2](https://codon.org.uk/~mjg59/blog/p/systemio-conflicts-are-not-firmware-bugs/#fn:2), but trying to load the native ddriver will generate an error and the internet will tell you that PC firmware developers are incompetent[3](https://codon.org.uk/~mjg59/blog/p/systemio-conflicts-are-not-firmware-bugs/#fn:3)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\.