ACPI Debug Playbook
Symptom-driven ACPI debug guide connecting missing devices, driver binding issues, resource conflicts, EC failures, GPIO wake bugs, and power-resource problems.
ACPI debugging is easiest when you start from the symptom, not from the acronym.
Instead of asking “what is _STA?”, ask:
Why did the OS hide this device?
Instead of asking “what is _CRS?”, ask:
Why did the driver bind but fail to receive interrupts?
This playbook maps common symptoms to ACPI checkpoints.
| Item | Value | Note |
|---|---|---|
| Device missing | _STA / _HID / table loading | Check whether the object exists and returns present/enabled. |
| Driver not binding | _HID / _CID | The OS driver may not recognize the ACPI ID. |
| Driver binds but device fails | _CRS | Check bus address, GPIO interrupt, MMIO, IRQ, and controller path. |
| Windows-only behavior | _DSM / _OSI | Vendor method or OS-specific branch may change feature exposure. |
| Battery/thermal/hotkey failure | EC OperationRegion / Field / Notify | Trace EC RAM offsets and SCI query methods. |
| Instant wake | _PRW / GPIO / GPE | Wake source may be enabled, inverted, or uncleared. |
| Resume-only failure | _PS0 / _WAK / PowerResource | Cold boot and resume power paths may differ. |
Playbook 1: device is missing
acpidump + iasl
↓
Find namespace object
↓
Check _HID/_CID
↓
Check _STA return value
↓
Trace variables used by _STA
↓
Check firmware generation policyMost important question: does the OS receive a device that it is allowed to enumerate?
Playbook 2: driver binds, but hardware does nothing
Driver identity OK
↓
Check _CRS
↓
Compare bus/address/GPIO/IRQ with schematic
↓
Check controller path exists
↓
Check polarity/wake flags/resource conflictMost important question: did firmware describe the same electrical connection that exists on the board?
Playbook 3: EC-related failure
Find failing method
↓
Trace fields used by the method
↓
Map fields to EC offsets
↓
Check EC firmware map
↓
Check EC readiness and SCI clearingMost important question: is AML reading the same EC state that EC firmware actually provides?
Playbook 4: sleep/wake failure
Identify target state
↓
Collect wake source
↓
Inspect _PRW / GPIO / GPE
↓
Trace _PSx / PowerResource
↓
Compare cold boot vs resume sequenceMost important question: did the platform enter and leave the low-power state with all wake and power dependencies consistent?
Future Blog Ideas
- How Windows Finds Your Hardware Using ACPI
- Why Your Device Disappears from Device Manager
- OperationRegion Explained Through Real EC Debugging
- DSDT vs SSDT for Firmware Engineers
- Understanding _DSM Through Thunderbolt Debugging
- How Sleep and Resume Really Work
- ACPI Debugging Playbook Every BIOS Engineer Should Know
Related notes
- ACPI Architecture Overview
- ACPI Debug Toolbox
- _STA Deep Dive
- _CRS Deep Dive
- Embedded Controller OperationRegion
- Sleep and Wake
Found this useful?
Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.
Nội dung liên quan
Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.
ACPI Architecture Overview
How firmware describes platform hardware to the operating system through ACPI tables, AML, namespace objects, and device methods.
_STA Deep Dive
A firmware-debug focused explanation of ACPI _STA, using device disappearance and OS enumeration problems as the starting point.
Device Missing Playbook
A practical firmware debug playbook for devices that disappear from the OS, Device Manager, lspci, or ACPI namespace.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.