Asus oyun dizüstü bilgisayarlarında ACPI ürün yazılımı hatası

• ASUS ROG oyun dizüstü bilgisayarlarında ACPI.sys DPC gecikmesi nedeniyle ses kesilmeleri, fare donmaları, video oynatma hataları gibi ciddi performans düşüşleri yaşanıyor
• Bunun nedeni, ürün yazılımı (BIOS) içindeki verimsiz veya hatalı ACPI Machine Language (AML) kodu; bu sorun işletim sistemi ya da sürücü değiştirerek çözülemiyor
• Periyodik donanım olayları (GPE) ve gömülü denetleyiciyle (EC) ilgili işler CPU 0 çekirdeğini tek başına meşgul ediyor; Sleep() çağrıları gibi hatalı kesme işleme biçimleri gecikme süresini ve sistem tepkiselliğini olumsuz etkiliyor
• Ürün yazılımı, MUX modu algısı olmadan GPU güç çevrimini tekrarlıyor; bu da sistemin geçici olarak duraksamasından mavi ekrana kadar farklı arızalara yol açıyor
• Bu sorun 2021'den beri çeşitli ASUS oyun dizüstü bilgisayar modellerinde tutarlı biçimde rapor ediliyor ve ASUS'tan resmi bir müdahale gelmiş değil

---

Projenin önemi ve arka planı

Bu açık kaynak deposu, ASUS oyun dizüstü bilgisayarlarda (ROG serisi vb.) tekrar tekrar görülen ACPI.sys DPC gecikmesi sorununu ürün yazılımı ve ACPI tablo katmanında inceleyen derinlemesine bir teknik rapor. Özellikle Zephyrus, Strix, Scar gibi yüksek performanslı modellerde YouTube izleme, sesli/görüntülü görüşme, fare hareketi gibi temel kullanım senaryolarında bile takılma, gecikme ve ses hataları sıkça yaşanıyor. Sürücü değişikliği, Windows'u yeniden kurma ya da Linux'a geçme gibi çeşitli denemeler sorunu çözmüyor; neden yalnızca ürün yazılımındaki hatalı AML kodu.

Başlıca belirtiler ve ölçüm sonuçları

• LatencyMon gibi araçlarla yapılan ölçümlerde, gerçek zamanlı ses ve diğer işlerin işlenemediği görülüyor
• ACPI.sys sürücüsünün kesmeler ve DPC rutinleri sırasında belirli bir çekirdeği (CPU 0) uzun süre meşgul ettiği doğrulanıyor
  • Kesme-işlem gecikmesi: en yüksek 65.816μs, ortalama 23,29μs
  • DPC rutini gecikmesi: en yüksek 5.998μs
• CPU 0, 90 saniyeden uzun süre boyunca kesme işlemede tek başına kullanılıyor; bu, yük dengeleme başarısızlığından değil, ürün yazılımının tek çekirdeği işgal edecek şekilde tasarlanmış olmasından kaynaklanıyor
• Sorun basit bir Windows sürücüsü meselesi değil; asıl neden ürün yazılımındaki verimsiz veya hatalı AML kodunun ACPI.sys'e iletilip çalıştırılması. Özellikle GPE (General Purpose Events) ve Embedded Controller (EC) trafiği probleme yol açıyor

Ayrıntılı analiz: gelişmiş ACPI günlük izleme ve sorun kalıpları

• Windows Performance Analyzer ve ETW izleme sonuçları, bu gecikmenin düzenli olarak 30–60 saniyelik aralıklarla ortaya çıktığını gösteriyor
• Ana olay olan _GPE._L02 işleyicisi uzun süre çalışıyor (örneğin 13,6 ms) ve bu da gerçek zamanlı performansı ciddi biçimde düşürüyor
• GPU güç yönetimi komutları, MUX (çoklu grafik seçimi) modunun durumundan bağımsız olarak tekrar tekrar çalışıyor; gerçekte yalnızca dGPU'nun ekrana bağlı olduğu ortamlarda imkânsız olan durum geçişleri sürekli deneniyor
• Bu süreçte bilgisayar mavi ekranla (BSOD) kapanabiliyor ya da sürücü iş parçacıkları sonsuz bekleme durumuna girerek kritik arızalara neden olabiliyor

Ürün yazılımı kodunun çıkarılması ve dekompilasyon

• ACPI tabloları acpidump, iasl gibi araçlarla çıkarılıp decompile edilerek analiz edildi
• Sorunlu GPE işleyicisi basitçe şu çağrıyı yapıyor:
  • _L02: \_SB.PC00.LPCB.ECLV() çağrısı
• Ancak ECLV() yöntemi içinde:
  • Sleep(25~100ms) gibi CPU'yu durduran çağrılar tekrar ediyor
  • EC olay kuyruğu boş olsa bile yapay olarak olay üretiliyor (kendi kendini yeniden kurma), böylece sonsuz tekrar kalıbı oluşuyor
• GPE içinde uyku çağrıları yapmak, kesme bağlamında kaçınılması gereken bir davranış; bir çekirdeğin onlarca ms boyunca bloke olmasına ve gerçek zamanlı zamanlama/giriş/ses işlemlerinin olumsuz etkilenmesine yol açıyor

Olay işleme/dağıtımı ve güç yönetimi mantığı

• GPE olayları, pil durumu ile GPU güç/ekran geçişleriyle ilgili sarmalayıcı işlev çağrılarına bağlanıyor
• PWCG(): pil/AC adaptör durumunu yokluyor ve işletim sistemine tekrar tekrar bildirim sinyali gönderiyor
• NOD2(): NVIDIA sürücüsüne güç durumunu yeniden değerlendirmesi için bildirim yapıyor
• Doğru GPU üzerinde işlem yapmak için MUX modu durumunun (HGMD == 0x03) kontrol edilmesi gerekirken, ilgili bölümde bu atlanıyor ve moddan bağımsız ayrım gözetmeyen güç çevrimi komutları tekrar tekrar yürütülüyor

Sistem ve modeller genelinde aynı kusur

• Scar 15, Zephyrus M16 ve başka birçok modelde olay çalışma süresi, GPU güç çevrimi periyodu ve WMI çağrı kalıbı neredeyse aynı şekilde gözlemleniyor
• Armoury Crate'in (WMI hizmeti) bu durumu daha da kötüleştirdiği düşünülüyor

Kök neden ve tasarım başarısızlığının özeti

• Kesme bağlamının yanlış anlaşılması: Ürün yazılımı, GPE yöntemi çalışırken GPE sinyalini maskeleyerek ACPI/EC işlerini seri hale getiriyor; içerideki Sleep() çağrıları da gecikmeyi onlarca ms'ye çıkarıyor
• Kesmelerin hatalı işlenmesi: GPE kaynağını temizlemeden sonsuz kendi kendini yeniden kurma ile tekrarlayan GPE'ler oluşturuluyor (periyodik zamanlayıcı gibi çalışıyor)
• Platform (donanım) durumunun farkında olmama: MUX modunu kontrol etmeden GPU güç yönetimi komutları gönderiliyor
• Genel olarak gerçek zamanlı garanti gereksinimleri (ses/video vb.) karşılanamıyor ve bu durum Microsoft'un resmi HLK GlitchFree testinden kalma nedeni oluyor

Kullanıcı raporları ve sorunun sürekliliği

• 2021'den bu yana ASUS resmi forumlarında, Reddit'te ve başka yerlerde aynı sorun tekrar tekrar gündeme getiriliyor
• Strix, TUF ve G serisi dâhil tüm ürün ailesinde belirtiler tutarlı
• 2023–2024'ün en yeni modellerinde bile aynı kusur sürüyor; yalnızca geçici geçici çözümler var

Sonuç: sorunun özü ve çıkarımlar

• Ölçüm kanıtı: GPE işleyicisi bir çekirdeği 13 ms'den uzun süre bloke ediyor
• Kod kanıtı: Kesme işleyicisi içinde açıkça Sleep() bulunuyor
• Mantıksal kanıt: MUX modu kontrolü yok
• Sistem kanıtı: Birden fazla model ve BIOS'ta yeniden üretim doğrulandı
• "Sadece verimsiz kesme işleyicisi içi uyku çağrıları ve GPU durumunun kontrol edilmemesi" gibi basit ama ölümcül bir tasarım hatası yüzünden, milyonlarca ASUS dizüstü bilgisayar kullanıcısı en temel işlerde bile takılmalar yaşıyor
• ASUS, bu analizin yapıldığı tarihe kadar resmi bir yanıt ya da düzeltme planı açıklamış değil

Analiz yöntemi ve referanslar

• Bu rapor, Windows Performance Toolkit, acpidump, iasl gibi araçlarla gerçek cihazlardan veri çıkarılması ve AML kodunun doğrudan analiz edilmesiyle hazırlandı
• Tüm temel kanıtlar (izler, yöntemler, komutlar) yeniden üretilebilir