Bug firmware ACPI pada laptop gaming Asus

• Pada laptop gaming ASUS ROG, terjadi fenomena latensi DPC ACPI.sys yang menyebabkan penurunan performa serius seperti audio tersendat, mouse membeku, dan kesalahan pemutaran video
• Penyebabnya berasal dari kode ACPI Machine Language (AML) yang tidak efisien atau cacat di dalam firmware (BIOS), sehingga tidak bisa diselesaikan dengan mengganti sistem operasi atau driver
• Event perangkat keras periodik (GPE) dan tugas terkait embedded controller (EC) memonopoli core CPU 0, dan penanganan interupsi yang keliru seperti pemanggilan Sleep() berdampak buruk pada latensi dan respons sistem
• Firmware berulang kali melakukan siklus daya GPU tanpa mengenali mode MUX, yang memicu berbagai gangguan mulai dari sistem membeku sementara hingga blue screen
• Masalah ini telah dilaporkan secara konsisten pada berbagai model laptop gaming ASUS sejak 2021, dan belum ada respons resmi dari ASUS

---

Makna dan latar belakang proyek

Repositori open source ini adalah laporan teknis mendalam yang menganalisis akar penyebab masalah latensi DPC ACPI.sys yang berulang pada laptop gaming ASUS (termasuk seri ROG) di tingkat firmware dan tabel ACPI. Secara khusus, model performa tinggi seperti Zephyrus, Strix, dan Scar sering mengalami stutter, lag, dan error audio bahkan dalam penggunaan dasar seperti menonton YouTube, panggilan suara/video, atau menggerakkan mouse. Berbagai upaya seperti mengganti driver, memasang ulang Windows, atau berpindah ke Linux semuanya tidak menyelesaikan masalah, dan penyebabnya hanya ada pada kode AML yang salah di dalam firmware.

Gejala utama dan hasil pengukuran

• Saat diukur dengan alat seperti LatencyMon, sistem dinilai tidak mampu menangani audio real-time dan tugas lain dengan baik
• Dikonfirmasi bahwa driver ACPI.sys menempati core tertentu (CPU 0) dalam waktu lama pada rutin interupsi dan DPC
  • Latensi interrupt-to-process: maksimum 65,816μs, rata-rata 23.29μs
  • Latensi rutin DPC: maksimum 5,998μs
• CPU 0 digunakan secara eksklusif untuk menangani interupsi selama lebih dari 90 detik, yang menunjukkan bahwa ini bukan kegagalan load balancing, melainkan firmware memang dirancang untuk membebani satu core saja
• Penyebabnya bukan sekadar isu driver Windows, melainkan karena kode AML yang tidak efisien atau cacat di firmware dikirim ke ACPI.sys untuk dieksekusi. Secara khusus, lalu lintas GPE (General Purpose Events) dan Embedded Controller (EC) memicu masalah ini

Analisis detail: pelacakan log ACPI tingkat lanjut dan pola masalah

• Berdasarkan hasil Windows Performance Analyzer dan ETW tracing, fenomena latensi ini terjadi secara berkala setiap 30–60 detik
• Handler utama _GPE._L02 berjalan lama (misalnya 13.6ms), sehingga performa real-time menurun drastis
• Perintah manajemen daya GPU berulang kali terjadi tanpa memedulikan status mode MUX (pemilihan grafis ganda), sehingga upaya perpindahan status yang sebenarnya mustahil terus dicoba bahkan dalam lingkungan di mana hanya dGPU yang terhubung ke display
• Dalam proses ini, terjadi gangguan fatal seperti komputer berhenti dengan blue screen (BSOD) atau thread driver masuk ke kondisi menunggu tanpa akhir

Ekstraksi dan dekompilasi kode firmware

• Analisis dilakukan dengan mengekstrak tabel ACPI menggunakan alat seperti acpidump, iasl, lalu mendekompilasinya
• Handler GPE yang bermasalah secara sederhana adalah
  • _L02: \_SB.PC00.LPCB.ECLV() dipanggil
• Namun di dalam metode ECLV()
  • Pemanggilan penghentian CPU seperti Sleep(25~100ms) berulang kali
  • Event dibuat secara artifisial meski antrean event EC kosong (self-rearm), menciptakan pola pengulangan tanpa akhir
• Pemanggilan sleep di dalam GPE adalah tindakan yang dilarang dalam konteks interupsi, sehingga satu core bisa terkunci selama puluhan ms dan berdampak buruk pada penjadwalan real-time, input, audio, dan lain-lain

Logika pemrosesan/distribusi event dan manajemen daya

• Event GPE berlanjut ke pemanggilan fungsi pembungkus terkait status baterai serta peralihan daya/display GPU
• PWCG(): polling status baterai/adaptor AC dan pengulangan sinyal notifikasi ke OS
• NOD2(): memberi tahu driver NVIDIA untuk mengevaluasi ulang status daya
• Seharusnya sistem memeriksa status mode MUX (HGMD == 0x03) agar beroperasi pada GPU yang benar, tetapi pada bagian aktual langkah ini diabaikan sehingga perintah power cycle dikirim berulang kali tanpa pandang mode

Cacat yang sama di seluruh sistem/model

• Pada banyak model seperti Scar 15 dan Zephyrus M16, waktu eksekusi event, siklus power GPU, dan pola pemanggilan WMI teramati hampir identik
• Diduga Armoury Crate (layanan WMI) semakin memperburuk fenomena ini

Akar masalah dan ringkasan kegagalan desain

• Salah memahami konteks interupsi: firmware mem-mask sinyal GPE saat metode GPE dijalankan, sehingga pekerjaan ACPI/EC diserialkan, dan pemanggilan internal Sleep() membuat latensi mencapai puluhan ms
• Penanganan interupsi yang salah: tanpa membersihkan sumber GPE, firmware terus melakukan self-rearm tanpa akhir dan memicu GPE berulang (berperan seperti timer periodik)
• Tidak mengenali status platform (hardware): perintah manajemen daya GPU dikirim tanpa memeriksa apakah mode MUX aktif atau tidak
• Secara keseluruhan, ini gagal memenuhi kebutuhan jaminan real-time (audio/video, dll.) dan menjadi penyebab gagal pada uji resmi Microsoft HLK GlitchFree

Laporan pengguna dan keberlanjutan isu

• Sejak 2021, fenomena yang sama terus diangkat di forum resmi ASUS, Reddit, dan tempat lain
• Gejalanya konsisten di seluruh lini produk termasuk Strix, TUF, dan seri G
• Cacat yang sama tetap ada hingga model terbaru 2023–2024, dan hanya tersedia solusi sementara

Kesimpulan: hakikat masalah dan implikasinya

• Bukti pengukuran: handler GPE mengunci satu core selama lebih dari 13ms
• Bukti kode: ada Sleep() yang secara eksplisit dipanggil di dalam interrupt handler
• Bukti logika: tidak ada pemeriksaan mode MUX
• Bukti sistem: reproduksi terkonfirmasi di banyak model/BIOS
• Kesalahan desain yang sederhana tetapi fatal—"sleep di dalam interrupt handler yang tidak efisien dan GPU state yang tidak diperiksa"—membuat jutaan pengguna laptop ASUS mengalami gangguan bahkan pada pekerjaan dasar
• Hingga saat analisis ini dibuat, ASUS belum mengumumkan rencana respons/perbaikan resmi

Metode analisis dan referensi

• Laporan ini disusun melalui ekstraksi data pada perangkat nyata dan analisis langsung kode AML menggunakan alat seperti Windows Performance Toolkit, acpidump, dan iasl
• Semua bukti utama (trace, metode, perintah) dapat direproduksi