Asus oyun dizüstü bilgisayarlarında ACPI ürün yazılımı hatası
(github.com/Zephkek)- 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
1 yorum
Hacker News görüşleri
Gerçekten şaşırtıcı bir keşif, makale ve düzeltme önerisi; modern PC'lerin nasıl çalıştığını ve “gizli” kısımlarına kadar ne kadar derine inilebildiğini çok iyi gösteriyor Yıllardır gömülü firmware yazan biri olarak, son kullanıcıların bu seviyede hatalar bulmasını hep hayal ettim Asus’un tam da böyle yetenekli kullanıcıları kısa süreli sözleşmeyle davet edip firmware mühendisleriyle birkaç gün çalıştırdığı, on binlerce dolar ödediği ve en güncel production BIOS yüklü yeni bir dizüstü verdiği bir dünyada yaşamak isterdim Bu hatanın 4 yıldan uzun süre göz ardı edilmiş olması üzücü
Teknik kök neden analizi ilginç ama iş süreçleri tarafındaki kök neden analizi de merak uyandırıyor Eğer bu sorun yaygın biçimde yeniden üretilebiliyorsa, teknik destek veya RMA üzerinden nasıl rapor edilmediğini merak ediyorum Kanıt çok az olduğu için ilişkilendirilemedi mi, yoksa ASUS araştırıp yanlış bir sonuca mı vardı (ör. hatalı silikon partisi), ya da yeterli kanıt olmasına rağmen görmezden mi gelindi? Kullanım sırasında hemen ortaya çıkan bir belirtiyse, QA süreci nasıldı; bunun gözden kaçmaması gerekmez miydi? Şimdi öğrenmiş olduklarına göre nasıl bir adım atmaları muhtemel, onu da merak ediyorum Lüks bir markaysan, hem sorunu çözmeyi hem de itibarı onarmayı gerçekten başarman gerekir; yoksa marka ayakta kalamaz Geçmişte ROG almıştım ama bunu gördükten sonra bir daha almam gibi geliyor Tekrar düşününce, bu firmware hatasının kendisi gerçekten şok edici Diğer hatalar değişen donanım varsayımlarıyla ya da eski kodun yeniden kullanılmasıyla açıklanabilir, ama interrupt içinde sleep çağrısı yapmak çok ağır Bunun code review’dan nasıl geçtiğini ve firmware testlerinin nasıl yapıldığını merak ediyorum
ACPI’nin AML bytecode’u iki ucu keskin bıçak gibi Tersine mühendisliğe ve kullanıcıların hataları kendilerinin analiz edip düzeltebilmesine imkân vermesi bir avantaj Ama korkunç bir programlama ortamı ve ayrıca çekirdeğin en yüksek yetkileriyle çalışan oldukça ağır bir yorumlayıcı gerektiriyor; bu da riskli Sistem entegratörleri bu tür hilelere sık sık başvuruyor ama kod kalitesi beklentinin altında Linux sürücüsü yazmaya başladığımda deneyim neredeyse hep ACPI kodunu çöpe atmakla başlıyor
Kullanıcı ve programcı olarak böyle bir birikime sahip olmak adeta hayal gibi Makaledeki uzmanlık bilgisi etkileyici Ben de dizüstümün çeşitli kısımlarını analiz etmeye çalıştım ama ACPI kısmında duvara tosladım; tabloları dump edip kodu decompile ettim ama her şey sahte kod gibiydi Kendi dizüstüm için Linux sürücüsü yazmak istedim ama başaramadım Bunu yapabilen insanlara büyük saygı duyuyorum
Acaba nasıl bir düzeltme çıktığını bilen var mı? Bağlantı verilen Github sayfası “tüm verileri açıkladım, gerisini Asus düzeltsin” diye bitmiyor mu?
Gerçekten harika bir analiz ve Asus’un bu kadar “çöp” kaliteyi QA’dan geçirmeye ne kadar emek verdiği inanılmaz… demek isterdim ama aslında hiç uğraşmamış olmaları acı verici
Bir oyun dizüstüsünde 4 yıl boyunca ölümcül stutter yaşanmış olması şaşırtıcı Tüketicilerin neden ürünü topluca iade etmediğini düşündürüyor Bağlantı verilen Reddit gönderisindeki şu örnek alıntılanıyor: “Her şeyi denedim ama hiçbir şey değişmedi, garantiye gönderdim ve sonucu merak ediyorum; servis sonucu ‘sorun yok’ oldu, ben de zamanla alıştım ve Bluetooth kulaklık kullandığım için artık fark etmiyorum.”
İki gaming laptop deneyimimin ikisinde de benzer sorunlar çözülemedi Biri ilk nesil Alienware M17 idi; çift GTX 270M ve onboard Nvidia GPU vardı Stutter ve ses paraziti oluyordu; SLI ile onboard GPU’yu kapatıp bir forumdan bulduğum sürücüyü kullanarak kısmen çözmüştüm Sonra bir BIOS yamasıyla SLI’ı yeniden kullanabildim ama hiçbir zaman tam çözüm olmadı ve cihazın ömrü doldu İkinci ASUS ROG dizüstümde de neredeyse aynı belirtiler vardı Benim de ACPI koduna inecek bilgim olmadığından tamamen çözemedim LatencyMon çeşitli dll’leri suçluyordu; Wi‑Fi sürücüsünü değiştirmek, dGPU’yu kapatmak gibi geçici iyileştirmeler denedim Garip biçimde oyunlarda parazit daha az oluyordu Sonunda gaming laptop almaktan vazgeçtim Bu makaleyi görünce bugün bile durumun pek iyileşmediği hissine kapıldım
Bilgisayar endüstrisi onlarca yıldır tüketicilere “bozuk çalışmak normaldir” diye öğretti Başka sektörlerde olsa ilk gün hepsi iade edilirdi 35 yıl önce öğretmenim bunu bağcık bağlarken rastgele patlayan ayakkabılara benzetmişti Yine de bugün tüketici koruma yasalarının daha yerleşik hâle geldiği bir dönemdeyiz
ASUS ürünü (Zenphyrus G14) almamın sebebi, bir dönem ASUS’un AMD Ryzen 4xxxHS’i fiilen tek başına benimsemiş olmasıydı Başta performans iyiydi ama iki yıl sonra ısıl kısma nedeniyle düşüş görünmeye başladı Termal pad’i yeniden uygulamak kısmen yardımcı oldu ama kök nedeni bulamadım Pil performansındaki düşüşü de araştırdım; meğer iGPU sürekli tam yükte çalışıyormuş dGPU öncelikli ayarda pil ömrü biraz daha iyi bile oldu Mekanik arızalar da eklenince FW16’ya geçtim ve bir daha gaming laptop markası ürünü almak istememeye başladım Üreticinin tüketiciyi umursamadığı hissi yüzünden satın alma isteğim kayboldu
Bu kusur yalnızca Ultimate modunda ortaya çıkıyor Yani kullanıcı MUX üzerinden açıkça dGPU’ya geçişi seçtiğinde Bu özellik özellikle harici ekranda oyun oynayanlar için önemli bir ek imkân Optimus modunda harici ekran da düzgün çalışıyor ama az miktarda performans kaybı ve bazı ekran özelliklerinde (G-Sync gibi) kısıtlar oluyor Kullanıcıların çoğu muhtemelen sadece Optimus modunda kullandığı için bu kusuru fark etme şansı çok düşük Sorunun özü, Asus’un ek donanım özelliklerini doğru dürüst QA testinden geçirmeden piyasaya sürmüş olması Sanırım sadece “golden path” test ediliyor
Windows dizüstü kullanıcıları, her şeyin kusursuz çalışmamasına o kadar alıştı ki rahatsızlıkları sadece sineye çekiyorlar
Yazının girişinde LLM (Large Language Model) kullanıldığını söylemişlerdi; gerçekten de o tarz çok hissediliyor Bilgi sağlam ama bu aşırı dümdüz ton yüzünden insan işi gibi gelmiyor ve hoşuma gitmiyor Herkesin neden insanı andıran ifadelerden kaçtığını merak ediyorum
Ürün incelemecilerinin, hatta tüketici dostu ve itibarlı rtings ya da notebookcheck gibi sitelerin bile herkesin bildiği bu kusurları neden incelemelerde anmadığını merak ediyorum Ağızdan ağıza yayılan övgülere ve stellar incelemelere kanıp ürünü alıp sonra sorun yaşayınca, Reddit’te de “hepsi böyle” tepkisini görmek can sıkıcı Bu kültürün neden var olduğunu gerçekten merak ediyorum
Sorunu gerçekten görmek için MUX anahtarıyla dGPU only moduna alıp LatencyMon’u 2 dakikadan uzun çalıştırmak gerekiyor (iGPU bypass modunda da böyle mi bilmiyorum) notebookcheck gerçekten LatencyMon değerlerini kaydetmiş ve gerçek zamanlı ses için uygun olmadığını açıkça yazmış
notebookcheck örnek inceleme Ama bu kadar uç gecikme değerlerini fiilen tespit edememişler
Daha doğrudan ve hassas bakarsan, böyle inceleme sitelerinin kimlerden sponsorluk aldığını araştırmak mantıklı olur
O “programcı”nın (tam doğru ifade değil ama) interrupt içinde sleep eden kodu gerçekten test edip etmediğini, yoksa işin bölündüğü başka bir ekipte kayıtsızca geçiştirildiğini merak ediyorum Yalnızca otomasyon testlerinden geçti diye “boş ver” denmiş olması da çok muhtemel Microsoft tarzı dogfooding, yani geliştiricilerin kendi ürünlerini gerçekten kullanması gibi bir süreç olsaydı, muhtemelen kendi dizüstülerinde bu sorunu yaşayıp düzeltirlerdi diye düşünüyorum
Aynı sorun benim 2019 model MSI gaming laptop’umda da (GS65 Stealth) var LatencyMon’u çalıştırdıktan bir dakika dolmadan >10ms stutter sürekli görünmeye başlıyor Tüm ACPI aygıtlarını devre dışı bırakınca stutter kayboluyor ama bu kez dGPU da kullanılamıyor Bunun dGPU’lu çok sayıda gaming laptop’ta yaygın bir sorunla bağlantılı olabileceğinden şüpheleniyorum MSI forumundaki ACPI gecikme başlığı da paylaşılmış “nvidia gaming laptop stutter latencymon acpi” diye aratılması öneriliyor
Özet: ASUS gaming laptop’ları bu kusur tamamen çözülene kadar satın almayın; garanti süresi içindeyse garanti talebi açın ve gerekirse Small Claims Court’a kadar gitmeye hazır olun
İnsanların neden ABD yapımı Mac’leri savunduğunu anlıyorum Böyle ağır bir sorunun neredeyse 4 yıl boyunca sevk edilmiş olmasına inanmak güç Bundan sonra neyi almayacağıma kesin karar verdim
Apple’da da benzer sorunlar oldu Örneğin EFI firmware sorununun inkâr edilmesi vakası vardı
ilgili haber
“Çarpıtma alanı”nın dışındaki kullanıcılar için de Apple’ın kendine özgü sorunları elbette var
İşte 8 yıl Mac kullandım; genel olarak iyi çalışıyordu ama iki büyük sorun yaşadım a) Bir keresinde şarj aniden durdu; batarya doluyken hemen verileri taşıyıp kurtardım, çıkarılabilir depolamayı özledim b) Bir yıl boyunca iTunes ile stream başlatırken yaklaşık %25 olasılıkla müzik yerine korkunç gürültü geliyordu; tekrar başlatınca çoğu zaman düzeliyordu Bu belirli bir OS sürümünde başlamış, bir sonrakinde düzelmişti; başka uygulamalarda hiç olmadı “Mac zaten kusursuzdur” algısı yüzünden bilgi de bulamadım, boşuna uğraştım Daha hafif ama sinir bozucu bir sorun olarak, Outlook açıkken kapağı kapatınca pil tüketimi ve ısınma oluyordu Outlook kötü şöhretli ama Exchange kullanılan bir şirkette yine de onunla yaşamanın daha iyi olduğuna karar veriyorsun
MSI dizüstülerde de EFI hatası yüzünden
rm -rf /komutu çalıştırıldığında UEFI boot edilemez hâle gelme sorunu gerçekten vardısorun açıklaması
“Mac’i savunmak” ifadesiyle, bunun oyuncular veya VR kullanıcıları için de geçerli olup olmadığı soruluyor
2015 civarında switchable graphics dizüstü almamaya kesin karar verdim ve bu karar iyi çıktı “Premium” markaların firmware geliştirmeye kuruş ayırırken pazarlamaya dev bütçeler harcaması bana hep komik gelmiştir
ASUS, pazarlama bütçesinin %0,01’ini bile buna ayırsa milyonlarca kullanıcının deneyimini iyileştirebilir, değişim maliyetlerini azaltabilir ve marka itibarını artırabilirdi Bu durum, birçok şirketin iyi mühendislik yerine pazarlamanın daha verimli olduğuna yanlış biçimde inanıp organizasyonlarını kötü yönettiğinin kanıtı