Asus gaming laptop ACPI firmware bug

• ASUS ROG gaming laptops में ACPI.sys DPC latency की समस्या के कारण audio कटना, mouse freeze होना, video playback errors जैसी गंभीर performance degradation समस्याएँ होती हैं
• इसका कारण firmware (BIOS) के भीतर inefficient या faulty ACPI Machine Language (AML) code है, इसलिए operating system या driver बदलने से यह ठीक नहीं हो सकता
• Periodic hardware events (GPE) और embedded controller (EC) से जुड़े कार्य CPU 0 core को एकाधिकार में ले लेते हैं, और Sleep() calls जैसी गलत interrupt handling के कारण latency और system responsiveness पर बुरा असर पड़ता है
• firmware MUX mode की पहचान किए बिना GPU power cycling दोहराता रहता है, जिससे system hang से लेकर blue screen तक कई तरह की failures होती हैं
• यह समस्या 2021 के बाद से कई ASUS gaming laptop models में लगातार report की गई है, और ASUS की ओर से कोई आधिकारिक response जारी नहीं हुआ है

---

प्रोजेक्ट का महत्व और पृष्ठभूमि

यह open source repository ASUS gaming laptops (ROG series आदि) में बार-बार होने वाली ACPI.sys DPC latency समस्या के root cause का firmware और ACPI table स्तर पर किया गया एक गहन technical report है। खास तौर पर Zephyrus, Strix, Scar जैसे high-performance models में YouTube देखना, voice/video calls, mouse movement जैसी सामान्य उपयोग स्थितियों में भी stutter, lag, audio errors बार-बार अनुभव किए जाते हैं। driver बदलना, Windows reinstall करना, Linux पर जाना जैसी कई कोशिशें बेअसर रहती हैं, क्योंकि root cause केवल firmware के भीतर मौजूद गलत AML code में है।

मुख्य लक्षण और माप के परिणाम

• LatencyMon जैसे tools से मापने पर यह निष्कर्ष निकलता है कि system real-time audio और अन्य tasks को ठीक से handle नहीं कर पाता
• यह पुष्टि हुई कि ACPI.sys driver interrupts और DPC routines के दौरान एक specific core (CPU 0) को लंबे समय तक व्यस्त रखता है
  • interrupt-to-process latency: अधिकतम 65,816μs, औसत 23.29μs
  • DPC routine latency: अधिकतम 5,998μs
• CPU 0 को 90 सेकंड से अधिक समय तक लगभग exclusively interrupt handling में लगाया जाता है, जो load balancing failure नहीं बल्कि firmware द्वारा single core occupancy के लिए design को दर्शाता है
• root cause कोई साधारण Windows driver issue नहीं, बल्कि firmware में मौजूद inefficient या faulty AML code का ACPI.sys को सौंपा जाना और execute होना है। खासकर GPE (General Purpose Events) और Embedded Controller (EC) traffic समस्या पैदा करते हैं

विस्तृत विश्लेषण: advanced ACPI log tracing और समस्या के पैटर्न

• Windows Performance Analyzer और ETW tracing के परिणाम बताते हैं कि यह latency issue हर 30~60 सेकंड के अंतराल पर नियमित रूप से होता है
• मुख्य event _GPE._L02 handler लंबे समय तक चलता है (उदाहरण: 13.6ms), जिससे real-time performance गंभीर रूप से गिरती है
• GPU power management commands MUX (multi-graphics selection) mode state की परवाह किए बिना बार-बार चलती हैं, और ऐसे environment में भी लगातार state transition attempts होती रहती हैं जहाँ वास्तव में केवल dGPU ही display से जुड़ा होता है
• इस प्रक्रिया में computer blue screen (BSOD) के साथ बंद हो सकता है, या driver threads indefinite wait state में फँस सकते हैं, जिससे गंभीर failures होती हैं

firmware code extraction और decompilation

• acpidump, iasl जैसे tools से ACPI tables निकालकर decompile करके analysis किया गया
• समस्या वाला GPE handler संक्षेप में:
  • _L02: \_SB.PC00.LPCB.ECLV() call
• लेकिन ECLV() method के अंदर:
  • Sleep(25~100ms) जैसी CPU stall calls बार-बार होती हैं
  • EC event queue खाली होने पर भी artificial event generation (self-rearming) होती है, जिससे infinite repeat pattern बनता है
• GPE के अंदर sleep call करना interrupt context में वर्जित माना जाता है, और इससे एक core कई दर्जन ms तक block हो जाता है, जिससे real-time scheduling, input, audio आदि पर बुरा असर पड़ता है

event handling/dispatch और power management logic

• GPE events आगे battery state और GPU power/display switching से जुड़ी wrapper functions को trigger करते हैं
• PWCG(): battery/AC adapter state polling और OS notification signals को दोहराना
• NOD2(): NVIDIA driver को power state re-evaluation notification देना
• सही व्यवहार के लिए MUX mode state (HGMD == 0x03) को जाँचना चाहिए और उसी के आधार पर सही GPU पर काम होना चाहिए, लेकिन वास्तविक code path में यह छोड़ा गया है, जिससे mode की परवाह किए बिना indiscriminate power-cycle commands दोहराई जाती हैं

system/models में एक जैसी खामी

• Scar 15, Zephyrus M16 सहित कई models में event execution time, GPU power cycle interval, और WMI call pattern लगभग एक जैसे देखे गए
• माना जाता है कि Armoury Crate (WMI service) इस समस्या को और खराब कर सकता है

root cause और design failure का सार

• interrupt context की गलत समझ: firmware में GPE method execution के दौरान GPE signal को mask किया जाता है, जिससे ACPI/EC tasks serialize हो जाते हैं, और अंदर के Sleep() calls के कारण latency कई दर्जन ms तक पहुँच जाती है
• गलत interrupt handling: GPE source clear किए बिना infinite self-rearming के कारण repeated GPE trigger होते रहते हैं, मानो periodic timer की तरह
• platform (hardware) state की अनदेखी: MUX mode जाँचे बिना GPU power management commands भेजी जाती हैं
• कुल मिलाकर system real-time guarantee requirements (audio/video आदि) को पूरा नहीं कर पाता, और यह Microsoft के आधिकारिक HLK GlitchFree test में fail होने का कारण बनता है

user reports और issue की निरंतरता

• 2021 से ASUS official forums, Reddit आदि पर यही समस्या बार-बार उठाई गई है
• Strix, TUF, G-series सहित पूरी lineup में symptoms एक जैसे हैं
• 2023~2024 के latest models तक यही defect जारी है, और केवल temporary workarounds उपलब्ध हैं

निष्कर्ष: समस्या का सार और उसके संकेत

• measurement evidence: GPE handler एक core को 13ms से अधिक समय तक block करता है
• code evidence: interrupt handler के अंदर Sleep() स्पष्ट रूप से मौजूद है
• logical evidence: MUX mode check का अभाव
• system evidence: कई models/BIOS में reproduction की पुष्टि
• यह "सिर्फ inefficient interrupt handler के भीतर sleep और GPU state verification की कमी" जैसी दिखने वाली, लेकिन बेहद घातक design error है, जिसके कारण लाखों ASUS laptop users को basic tasks में भी stutter का सामना करना पड़ता है
• इस analysis के समय तक ASUS ने कोई आधिकारिक response या fix plan जारी नहीं किया है

analysis method और reference

• यह report Windows Performance Toolkit, acpidump, iasl जैसे tools से real devices पर data extraction और AML code के direct analysis के आधार पर तैयार की गई है
• सभी प्रमुख evidence (traces, methods, commands) reproducible हैं