Asus gaming laptop ACPI firmware bug

 (github.com/Zephkek)
2 पॉइंट द्वारा GN⁺ 2025-09-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-09-18
Hacker News राय

  • यह वाकई चौंकाने वाली खोज, लेख और fix proposal है; यह शानदार ढंग से दिखाता है कि आधुनिक PC कैसे काम करते हैं, और कोई व्यक्ति उन 'छिपे हुए' हिस्सों तक कितना गहराई से जा सकता है वर्षों तक embedded firmware लिखते हुए, मैं हमेशा चाहता था कि कोई end user इस स्तर का bug ढूँढ निकाले मैं ऐसी दुनिया में रहना चाहूँगा जहाँ Asus ऐसे प्रतिभाशाली user को तुरंत short-term contract पर बुलाए, firmware engineers के साथ कुछ दिन काम कराए, उसे दसियों हज़ार डॉलर के बराबर सम्मान दे, और उसके laptop को नए production BIOS के साथ बदल दे यह दुखद है कि यह bug 4 साल से भी ज़्यादा समय तक पड़ा रहा

    • तकनीकी root cause analysis दिलचस्प है, लेकिन business process के angle से root cause analysis भी जानना चाहूँगा अगर यह समस्या इतनी व्यापक रूप से reproduce होती है, तो यह tech support या RMA के ज़रिए report क्यों नहीं हुई, यह सवाल है क्या सबूत इतने कमज़ोर थे कि लोग चीज़ों को आपस में जोड़ ही नहीं पाए, या ASUS ने जाँच के बाद गलत निष्कर्ष निकाला, जैसे कि खराब silicon batch, या फिर पर्याप्त सबूत होते हुए भी उसे नज़रअंदाज़ किया गया अगर यह इस्तेमाल के तुरंत बाद दिखने वाली समस्या थी, तो QA process कैसी थी; क्या यह ऐसी चीज़ नहीं थी जिसे मिस करना मुश्किल होना चाहिए था अब जब बात सामने आ गई है, तो वे क्या कार्रवाई करेंगे, यह जानने की उत्सुकता है अगर यह luxury brand होता, तो brand को बचाने के लिए उसे problem resolution और reputation recovery दोनों पक्के तौर पर करने पड़ते मैंने पहले ROG खरीदा था, लेकिन यह देखने के बाद शायद दोबारा नहीं खरीदूँगा फिर सोचने पर लगता है कि यह firmware bug अपने आप में ही बेहद चौंकाने वाला है दूसरे bugs को कभी hardware assumptions बदलने या पुराने code reuse की गलती माना जा सकता है, लेकिन interrupt के अंदर sleep डालना बहुत गंभीर बात है यह code review से कैसे निकल गया, और firmware testing आखिर कैसे की गई, यह समझना मुश्किल है

    • ACPI का AML bytecode दोधारी तलवार जैसा है अच्छी बात यह है कि reverse engineering संभव है और user खुद bug का analysis करके fix भी कर सकता है लेकिन यह बहुत खराब programming environment है, और इसमें एक काफ़ी भारी interpreter को kernel के highest privilege पर चलाना पड़ता है, जो ख़तरनाक है system integrators अक्सर ऐसी तरकीबों के लिए इसका इस्तेमाल करते हैं, और code quality अक्सर उम्मीद से कम होती है जब भी Linux driver खुद बनाना पड़ता है, अनुभव यही रहता है कि शुरुआत ACPI code फेंकने से करनी पड़ती है

    • एक user और programmer के रूप में इस तरह का know-how होना किसी सपने जैसा है लेख में जो expertise है, वह सचमुच प्रभावशाली है मैंने भी laptop के कई हिस्सों का analysis किया है, लेकिन ACPI हिस्से पर आकर हमेशा अटक गया; tables dump कीं, code decompile किया, लेकिन सब कुछ dummy code ही निकला मैं अपने laptop के लिए Linux driver खुद बनाना चाहता था, लेकिन असफल रहा जो लोग इस तरह का काम कर लेते हैं, उनके लिए बहुत सम्मान है

    • यह जानने की जिज्ञासा है कि आखिर कौन-सा fix निकला क्या linked Github page बस इस बात पर खत्म नहीं होता कि "सारी जानकारी public कर दी गई है, अब Asus fix करे"?

    • यह सचमुच शानदार analysis है, और Asus ने ऐसी ‘कचरा’ quality को QA करने में कितनी मेहनत की होगी... ऐसा कहने का मन होता है, लेकिन कड़वा सच यह है कि शायद उन्होंने कोई मेहनत की ही नहीं

  • यह हैरान करने वाला है कि gaming laptop में 4 साल तक गंभीर stutter रहा यह भी सोचने पर मजबूर करता है कि consumers ने product को बड़े पैमाने पर वापस क्यों नहीं किया linked Reddit post का उदाहरण दिया गया है: “सब कुछ ट्राई कर लिया लेकिन कुछ बदला नहीं, warranty में भेजा है और नतीजे का इंतज़ार है; service result में ‘कोई समस्या नहीं’ बताया गया, तो अब आदत पड़ गई है और Bluetooth earphones लगाकर समस्या महसूस ही नहीं होती”

    • gaming laptop के साथ मेरे दोनों अनुभवों में ऐसे ही unresolved issues रहे एक first-generation Alienware M17 था, जिसमें dual GTX 270M और onboard Nvidia GPU था उसमें stutter और audio noise आते थे, और SLI तथा onboard GPU disable करके, किसी forum से मिला driver इस्तेमाल करने पर आंशिक राहत मिली थी बाद में BIOS patch आया जिससे SLI फिर उपयोग हो पाया, लेकिन पूरी तरह fix कभी नहीं हुआ और product की life खत्म हो गई दूसरा ASUS ROG laptop भी लगभग वैसी ही समस्या वाला था मेरे पास भी ACPI code में गहराई तक जाने की जानकारी नहीं थी, इसलिए मैं भी इसे पूरी तरह fix नहीं कर पाया LatencyMon ने कई dlls को issue assign किया, और मैंने Wi‑Fi driver बदलने, dGPU disable करने जैसी अस्थायी कोशिशें कीं अजीब बात यह थी कि games में noise उल्टा कम होता था आखिरकार मैंने gaming laptop खरीदना ही छोड़ दिया यह लेख देखकर लगता है कि आज भी हालात बहुत बेहतर नहीं हुए हैं

    • computer industry ने दशकों तक consumers को यह सिखाया है कि ‘टूटी हुई चीज़ का सामान्य होना’ स्वीकार कर लो किसी और industry में होता तो पहले दिन ही सब वापस हो जाता 35 साल पहले मेरे एक teacher ने इसकी तुलना ऐसे जूतों से की थी जो फीते बाँधते समय random तरीके से फट जाएँ फिर भी अब consumer protection laws की दिशा बेहतर होती दिख रही है

    • मैंने ASUS product (Zenphyrus G14) इसलिए खरीदा था क्योंकि एक समय ASUS के पास AMD Ryzen 4xxxHS का लगभग exclusive उपयोग था शुरुआत में performance अच्छी थी, लेकिन दो साल बाद thermal throttling के कारण performance गिरावट साफ़ दिखने लगी thermal pad दोबारा लगाने से थोड़ी मदद मिली, लेकिन root cause नहीं मिला मैंने battery degradation भी जाँची, लेकिन पता चला कि iGPU हमेशा full load पर चल रहा था और वही समस्या की वजह थी dGPU preferred पर सेट करने से उल्टा battery life थोड़ी बेहतर हो गई फिर mechanical defects भी जुड़ गए, तो मैं FW16 पर चला गया और अब दोबारा किसी gaming laptop brand का product खरीदने का मन नहीं है ऐसा लगता है कि manufacturer को consumers की कोई परवाह ही नहीं, और इससे खरीदने की इच्छा खत्म हो जाती है

    • यह defect सिर्फ Ultimate mode में होता है यानी तभी जब user ने MUX में explicitly dGPU पर switch किया हो यह feature उन लोगों के लिए खास महत्व रखता है जो external display पर ज़्यादा gaming करते हैं Optimus mode में भी external display ठीक चलता है, बस थोड़ी performance loss और कुछ display features, जैसे G-Sync, की सीमाएँ रहती हैं बहुत संभव है कि ज़्यादातर users सिर्फ Optimus mode में ही laptop चलाते हों, इसलिए उन्हें इस defect के बारे में पता ही न चलता हो असली समस्या यह है कि Asus ने अतिरिक्त hardware functionality का QA test ठीक से किए बिना shipment कर दिया इसे ‘golden path’ ही ठीक से test करने वाली प्रवृत्ति कहा जा सकता है

    • Windows laptop users अब इस बात के इतने आदी हो चुके हैं कि सब कुछ perfectly काम नहीं करेगा, कि वे असुविधा को बस सह लेते हैं

  • लेख की शुरुआत में कहा गया था कि LLM (Large Language Model) इस्तेमाल किया गया है, और उसका style सचमुच बहुत साफ़ महसूस होता है जानकारी मज़बूत है, लेकिन यह ज़रूरत से ज़्यादा समतल tone इसे मानवीय लेखन जैसा नहीं लगने देती, इसलिए अच्छा नहीं लगता समझ नहीं आता कि सब लोग human-sounding expression से इतना बचने की कोशिश क्यों कर रहे हैं

  • यह बात समझ नहीं आती कि product reviewers, यहाँ तक कि consumer-friendly और प्रतिष्ठित rtings या notebookcheck जैसी जगहें भी, उन कमियों का ज़िक्र review में क्यों नहीं करतीं जिन्हें सब जानते हैं word of mouth और stellar reviews देखकर product खरीदो, फिर समस्या झेलो, और Reddit पर बस यही सुनो कि "सबके साथ ऐसा ही होता है" — यह काफ़ी कड़वा अनुभव है सच में जानना चाहता हूँ कि ऐसी culture बनी ही क्यों है

    • असली समस्या पकड़ने के लिए MUX switch को dGPU only mode पर रखकर LatencyMon को 2 मिनट से ज़्यादा चलाना पड़ता है (iGPU bypass mode में भी ऐसा होता है या नहीं, यह पता नहीं) notebookcheck ने वास्तव में LatencyMon values record की थीं, और यह तक लिखा था कि यह real-time audio के लिए उपयुक्त नहीं है
      notebookcheck उदाहरण review लेकिन इस स्तर की extreme latency उन्हें भी नहीं मिली

    • अगर थोड़ा और सीधे और संवेदनशील ढंग से देखें, तो यह जाँचना तर्कसंगत है कि ऐसे review sites को funding कहाँ से मिलती है

  • यह जानने की जिज्ञासा है कि उस “programmer” (तकनीकी रूप से शायद सही शब्द नहीं) ने interrupt के अंदर sleep करने वाला code खुद कभी test भी किया था या नहीं, या फिर काम के बँटे होने के कारण किसी दूसरे विभाग ने लापरवाही से उसे जाने दिया बहुत संभव है कि automated tests पास होते ही उन्होंने सोचा हो, “अब इसे भूल जाओ” अगर Microsoft-style dogfooding, यानी developers द्वारा अपने ही products का वास्तविक इस्तेमाल, जैसी प्रक्रिया होती, तो शायद वे अपने laptop पर यह समस्या देखकर इसे fix कर देते

    • पहले मैंने Taipei की एक बड़ी hardware company के लिए firmware contract work किया था, और वहाँ bugs को नज़रअंदाज़ करना लगभग आदत जैसा था अगर आप bug report करते, तो आपको यह कहकर डाँटा जाता कि आपने तय काम छोड़कर दूसरी चीज़ों में समय क्यों लगाया hardware team, firmware/driver/software developers को हीन संबोधन से बुलाती थी, और feedback भी अनसुना कर दिया जाता था इसलिए ऐसी कहानी सुनकर बिल्कुल आश्चर्य नहीं होता

  • यही issue मेरे 2019 MSI gaming laptop (GS65 Stealth) में भी है LatencyMon चलाने के 1 मिनट के भीतर ही >10ms stutter लगातार दिखने लगता है सारे ACPI devices disable कर दूँ तो stutter गायब हो जाता है, लेकिन साथ ही dGPU भी इस्तेमाल नहीं हो पाता शक है कि यह समस्या dGPU वाले कई gaming laptops में काफ़ी व्यापक रूप से जुड़ी हो सकती है MSI forum ACPI latency post भी साझा किया गया "nvidia gaming laptop stutter latencymon acpi" खोजने की सलाह दी गई

  • सार: ASUS gaming laptop तब तक न खरीदें जब तक यह defect पूरी तरह fix न हो जाए; और अगर warranty period के भीतर हैं, तो warranty claim करें, और ज़रूरत पड़े तो Small Claims Court तक जाने के लिए भी तैयार रहें

    • ज़्यादातर laptops में तो वह dGPU only mode होता ही नहीं जिसमें यह bug सामने आता है सच कहूँ तो मैंने अपने laptop में भी MUX के ज़रिए dGPU only mode कभी इस्तेमाल नहीं किया; उसमें बस power consumption बढ़ती है और फ़ायदा बहुत कम है

  • अब समझ आता है कि लोग US-made mac को क्यों push करते हैं यह मानना मुश्किल है कि इतनी गंभीर समस्या लगभग 4 साल तक shipment में रही कम से कम अब यह तय है कि आगे क्या नहीं खरीदना है

    • Apple के साथ भी ऐसे issues रहे हैं उदाहरण के तौर पर EFI firmware issue denial का मामला था
      संबंधित लेख

    • "reality distortion field" के बाहर के users के लिए भी Apple की अपनी समस्याएँ साफ़ दिखाई देती हैं

    • मैंने काम पर 8 साल तक Mac इस्तेमाल किया, और कुल मिलाकर अनुभव अच्छा रहा, लेकिन दो बड़े troubles हुए a) एक बार charging अचानक बंद हो गई, तो जब तक battery भरी हुई थी मैंने तुरंत data migrate करके recovery की; उस समय removable storage की कमी बहुत खली b) 1 साल तक iTunes में streaming शुरू करते समय लगभग 25% संभावना रहती थी कि music की जगह तेज़ noise बजे; दोबारा play करने पर ज़्यादातर ठीक हो जाता था यह किसी खास OS version से शुरू हुआ और अगले version में ठीक हुआ; दूसरी apps में ऐसा नहीं हुआ ‘mac तो हमेशा perfect होता है’ वाली धारणा की वजह से जानकारी भी नहीं मिली और बस बेकार troubleshooting करनी पड़ी कम गंभीर लेकिन परेशान करने वाली बात यह भी थी कि Outlook खोलकर laptop का ढक्कन बंद कर देने पर battery drain और heat बढ़ जाती थी Outlook की reputation खराब है, फिर भी Exchange company में लोग सोचते हैं कि वही इस्तेमाल करना बेहतर है

    • MSI laptops में भी EFI bug के कारण rm -rf / चलाने पर UEFI boot unbootable होने की वास्तविक समस्या रही है
      issue विवरण

    • “mac को push करने” वाली बात पर सवाल है कि क्या वही तर्क gamers या VR users पर भी लागू होता है

  • 2015 के आसपास से ही मैंने तय कर लिया था कि दोबारा switchable graphics laptop नहीं खरीदूँगा, और यह फ़ैसला सही निकला यह हमेशा हास्यास्पद लगता है कि ‘premium’ brands firmware development staff पर बेहद कम निवेश करते हैं, लेकिन marketing पर बेहिसाब पैसा खर्च करते हैं

    • मैंने भी 2013 में एक "Optimus" laptop इस्तेमाल किया था और कसम खाई थी कि दोबारा नहीं लूँगा desktop या server इस्तेमाल करने की मेहनत ज़रूर बढ़ी, लेकिन आखिरकार सिर्फ iGPU पर रहने का मुझे कभी पछतावा नहीं हुआ

  • ASUS अगर अपनी marketing budget का सिर्फ 0.01% भी लगा देता, तो लाखों users का अनुभव बेहतर हो सकता था, replacement costs घट सकती थीं, और brand reputation भी सुधर सकती थी यह इस बात का सबूत है कि कई companies संगठन को इस गलत विश्वास पर चलाती हैं कि अच्छी engineering से ज़्यादा marketing प्रभावी है