Using acpidbg on Ubuntu 18.04 x64 can be quite handy; however, the Linux kernel with ACPI_DEBUGGER is not always available, such as on Ubuntu for ARM. In such cases, acpica also provides a set of utilities, named acpica-tools, for ACPI debugging.
Installing acpica-tools is as easy as the following command:
sudo apt install acpica-tool
The latest source code is available on either acpica.org or github as below, and it can be compiled and installed by “make” followed by “sudo make install“.
The acpica-tools consist of the following utilities: acpibin, acpiexamples, acpihelp, acpisrc, iasl, acpidump, acpiexec, acpinames and acpixtract. This article focuses on how to use iasl, acpidump, acpiexec and acpixtract.
acpidump – collect tables from a running system
acpixtract – extract tables from an acpidump file
acpiexec – emulate ACPI tables from extracted tables
iasl – compile & disassemble ACPI tables
A Case Study – Airplane Mode
The airplane-mode button on laptops usually requires implementation from both system BIOS and an OS driver. More specifically, it requires an ACPI device to be “present” in DSDT (or SSDT) table and a corresponding device driver. The below figure demonstrates how to debug if the airplane mode button fails to work.
Each computer brand has its specific implementation(s) and corresponding device driver(s). Some examples are listed below. Similarly, other driver source code can be found in Linux kernel.
Acer – acer-wireless
ASUS – asus-wireless
Dell – dell-rbtn, intel-hid, intel-vbtn
HP, Xiaomi – hp-wireless
Lenovo – idealpad-laptop, thinkpad_acpi
Let’s use a Dell system as an example but the same technique also applies for others. To understand whether the airplane mode driver is loaded, one can run
As seen above, the “intel-hid” shows up on this particular Dell system.
Let’s assume we already know intel-hid handles airplane mode on this Dell system but it is not loaded for now. Consequently, we may need to debug BIOS ASL/AML code using ACPICA utilities following the below steps.
Find Out ACPI Device’s (intel-hid’s) Hardware ID
A quick online search shows intel-hid.c is for an ACPI device with _HID “INT33D5”.
Extract and Disassemble Tables
Get all tables: sudo acpidump > acpi.log
Extract DSDT and SSDT: acpixtract acpi.log
Disassemble tables: iasl -d *.dat
Check Whether INT33D5 is “Present”
Find INT33D5 in DSDT or SSDT
$ grep INT33D5 *.dsl
dsdt.dsl: Name (_HID, "INT33D5")
Once found, let’s use vi to see more details in DSDT such as the device name (HIDD) as below:
Name (_HID, "INT33D5") // _HID: Hardware ID
// ... skipped
Method (_STA, 0, Serialized) // _STA: Status
If ((OIDE () >= One))
Check Device Status in Method (_STA)
In addition to the device declaration, Linux ACPI device driver is loaded when _STA returns “present”. As in the above ASL code, _STA can be present (return 0x0F) or absent (return Zero). One can continue to trace OIDE() -> OSID() and so on to find out what _STA returns.
Alternatively, using acpiexec is easier.
Evaluate _SB.HIDD._STA with acpiexec
Using acpiexec is the same as acpidbg, but it loads tables from files and runs AML in emulation mode, i.e. it does not touch hardware registers or actual memory.
Load tables: acpiexec *.dat
Find HIDD path: find HIDD
Execute HIDD’s _STA: execute _SB.HIDD._STA
If _SB.HIDD._STA returns 0xF but kernel does not load intel-hid, something is wrong with Linux kernel, ex. intel-hid is not compiled or is blacklisted. In this case, this should be forwarded to a Linux kernel engineer.
If _SB.HIDD._STA returns 0, we can continue to use acpiexec to find out OIDE() returns. In fact, we can use acpiexec to trace _SB._HIDD._STA
Trace _SB.HIDD._STA: debug _SB.HIDD._STA
ACPICA tools are very useful for debugging ACPI bugs, and using it well can save much time. This tutorial touches surface of what ACPICA tools can do and more documents can be found on acpica.org website.