Device Missing Playbook
A practical firmware debug playbook for devices that disappear from the OS, Device Manager, lspci, or ACPI namespace.
A device is missing.
That sentence is too vague to debug.
The first job is to classify where it disappeared.
Is the hardware present?
Check SKU, board option, power rail, reset, clock, strap, and cable/module presence.
Does it enumerate in PCI?
Use lspci or PCI config inspection for PCI/PCIe devices.
Does ACPI describe it?
Use acpidump and iasl to inspect Device node, _HID, _CID, _STA, and _CRS.
Are resources valid?
Check IRQ, GPIO, I2C/SPI serial bus, MMIO, BARs, and bridge windows.
Can the OS bind a driver?
Check Hardware Ids, Compatible Ids, INF match, kernel driver, and driver logs.
Does the device work after binding?
Check _DSM, power methods, reset GPIO, EC state, and interrupt delivery.
Fast classification
| Item | Value | Note |
|---|---|---|
| Missing from lspci | PCI enumeration layer | Check link, reset, power, clock, root port policy, lane routing. |
| Missing from ACPI namespace | ACPI generation layer | Check DSDT/SSDT generation, SKU conditions, table override, setup policy. |
| _STA returns 0x00 | Firmware hides device | Check condition variables, GPIO detection, EC flag, and board ID. |
| Unknown Device | Driver identity layer | Check _HID/_CID or PCI IDs and driver package. |
| Driver loads but device dead | Runtime layer | Check resources, interrupts, power methods, _DSM, and hardware state. |
Command path
lspci -nn
sudo acpidump -b
iasl -d DSDT.dat SSDT*.dat
grep -R "DeviceName\|_HID\|_STA\|_CRS" *.dslOn UEFI Shell side:
Shell> drivers
Shell> dh
Shell> devtree
Shell> dmpstoreDebug Diary: I2C touchpad missing
Device Manager: no touchpad
lspci: irrelevant because touchpad is ACPI/I2C, not PCI endpoint
acpidump: Device (TPD0) exists
_TPD0._STA: returns 0x00 on bad BIOS
Field read: board ID condition changed
Root cause: wrong SKU detection path hides deviceThis is the kind of boundary-by-boundary thinking that prevents random driver debugging.
Related notes
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.
Device Manager Through Firmware Engineer Eyes
How to read Windows Device Manager symptoms as ACPI, PCI, resource, and firmware handoff clues.
RWEverything for Platform Debug
How RWEverything can help inspect ACPI, PCI, IO, memory, EC, and MSR state during Windows-side firmware debugging.
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.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.