บั๊กเฟิร์มแวร์ ACPI ในโน้ตบุ๊กเกมมิ่ง Asus

• ในโน้ตบุ๊กเกมมิ่ง ASUS ROG เกิดปัญหา ความหน่วง DPC ของ ACPI.sys ซึ่งทำให้ประสิทธิภาพลดลงอย่างรุนแรง เช่น เสียงกระตุก เมาส์ค้าง และการเล่นวิดีโอผิดพลาด
• สาเหตุมาจาก โค้ด ACPI Machine Language (AML) ที่ไม่มีประสิทธิภาพหรือมีข้อบกพร่องในเฟิร์มแวร์ (BIOS) ทำให้ไม่สามารถแก้ได้ด้วยการเปลี่ยนระบบปฏิบัติการหรือไดรเวอร์
• เหตุการณ์ฮาร์ดแวร์แบบเป็นคาบ (GPE) และงานที่เกี่ยวข้องกับ Embedded Controller (EC) เข้ายึดคอร์ CPU 0 โดยเฉพาะ และ การจัดการอินเทอร์รัปต์ที่ผิดพลาด เช่น การเรียก Sleep() ส่งผลเสียต่อ latency และการตอบสนองของระบบ
• เฟิร์มแวร์ วนลูปวงจรจ่ายไฟ GPU ซ้ำโดยไม่รับรู้โหมด MUX ทำให้เกิดปัญหาตั้งแต่ระบบค้างชั่วคราวไปจนถึงจอฟ้า
• ปัญหานี้ถูกรายงานอย่างต่อเนื่องในโน้ตบุ๊กเกมมิ่ง ASUS หลายรุ่นนับตั้งแต่ปี 2021 และ ยังไม่มีการตอบสนองอย่างเป็นทางการจาก ASUS

---

ความสำคัญและที่มาของโครงการ

รีโพซิทอรีโอเพนซอร์สนี้เป็นรายงานเชิงเทคนิคเชิงลึกที่วิเคราะห์สาเหตุรากของปัญหา ความหน่วง DPC ของ ACPI.sys ที่เกิดซ้ำในโน้ตบุ๊กเกมมิ่ง ASUS (เช่น ซีรีส์ ROG) ในระดับเฟิร์มแวร์และตาราง ACPI โดยเฉพาะรุ่นประสิทธิภาพสูงอย่าง Zephyrus, Strix และ Scar ที่มักพบ อาการสะดุด แล็ก และข้อผิดพลาดด้านเสียง บ่อยครั้ง แม้ในงานใช้งานพื้นฐานอย่างดู YouTube โทรด้วยเสียง/วิดีโอ หรือขยับเมาส์ ปัญหานี้ไม่สามารถแก้ได้ด้วยการเปลี่ยนไดรเวอร์ ติดตั้ง Windows ใหม่ หรือย้ายไปใช้ Linux เพราะต้นเหตุอยู่ที่ โค้ด AML ที่ผิดพลาดภายในเฟิร์มแวร์ เท่านั้น

อาการหลักและผลการวัด

• เมื่อวัดด้วยเครื่องมืออย่าง LatencyMon พบว่าระบบถูกประเมินว่าไม่สามารถรองรับเสียงแบบเรียลไทม์และงานอื่น ๆ ได้
• ยืนยันได้ว่า ไดรเวอร์ ACPI.sys ใช้เวลาบนอินเทอร์รัปต์และ DPC routine ของคอร์บางคอร์ (CPU 0) เป็นเวลานาน
  • ความหน่วง interrupt-to-process: สูงสุด 65,816μs, เฉลี่ย 23.29μs
  • ความหน่วง DPC routine: สูงสุด 5,998μs
• CPU 0 ถูกใช้จัดการอินเทอร์รัปต์แบบผูกขาดนานกว่า 90 วินาที ซึ่งไม่ได้หมายถึงการโหลดบาลานซ์ล้มเหลว แต่หมายถึง เฟิร์มแวร์ถูกออกแบบให้ยึดคอร์เดียว
• สาเหตุไม่ใช่เพียงปัญหาไดรเวอร์ของ Windows แต่เกิดจาก เฟิร์มแวร์ส่งโค้ด AML ที่ไม่มีประสิทธิภาพหรือมีข้อบกพร่องให้ ACPI.sys รัน โดยเฉพาะทราฟฟิกจาก GPE (General Purpose Events) และ Embedded Controller (EC)

การวิเคราะห์เชิงลึก: การติดตามล็อก ACPI ขั้นสูงและรูปแบบปัญหา

• ผลจาก Windows Performance Analyzer และการทำ ETW tracing แสดงให้เห็นว่าความหน่วงนี้เกิดขึ้นเป็นคาบทุก 30~60 วินาที
• ตัวจัดการเหตุการณ์หลัก _GPE._L02 ใช้เวลารันนานผิดปกติ (เช่น 13.6ms) ส่งผลให้ประสิทธิภาพแบบเรียลไทม์ลดลงอย่างรุนแรง
• คำสั่งจัดการพลังงาน GPU เกิดซ้ำ โดยไม่เกี่ยวกับสถานะโหมด MUX (โหมดเลือกกราฟิกหลายตัว) และยังคงพยายามสลับสถานะที่เป็นไปไม่ได้ แม้ในสภาพแวดล้อมที่เชื่อมต่อจออยู่กับ dGPU เท่านั้น
• ในกระบวนการนี้อาจเกิดความเสียหายร้ายแรง เช่น เครื่องจอฟ้า (BSOD) หรือเธรดของไดรเวอร์ค้างรอแบบไม่สิ้นสุด

การดึงและดีคอมไพล์โค้ดเฟิร์มแวร์

• วิเคราะห์โดยดึงตาราง ACPI แล้วดีคอมไพล์ด้วยเครื่องมืออย่าง acpidump, iasl
• ตัวจัดการ GPE ที่มีปัญหาทำงานโดยสรุปดังนี้
  • _L02: เรียก \_SB.PC00.LPCB.ECLV()
• แต่ภายในเมธอด ECLV() มี
  • การเรียกหยุด CPU ซ้ำ ๆ เช่น Sleep(25~100ms)
  • สร้างเหตุการณ์ขึ้นมาเองแม้คิวเหตุการณ์ EC จะว่างอยู่ (self re-arm) ทำให้เกิดรูปแบบลูปไม่สิ้นสุด
• การเรียก sleep ภายใน GPE เป็นสิ่งที่ไม่ควรทำใน interrupt context และทำให้ คอร์หนึ่งถูกบล็อกนานหลายสิบ ms ส่งผลเสียต่อการจัดตารางแบบเรียลไทม์ อินพุต และเสียง

ลอจิกการจัดการ/dispatch เหตุการณ์และการจัดการพลังงาน

• เหตุการณ์ GPE จะนำไปสู่การเรียกฟังก์ชัน wrapper ที่เกี่ยวข้องกับสถานะแบตเตอรี่และการสลับพลังงาน/การแสดงผลของ GPU
• PWCG(): โพลสถานะแบตเตอรี่/อะแดปเตอร์ AC และส่งสัญญาณแจ้งเตือนระบบปฏิบัติการซ้ำ
• NOD2(): แจ้งไดรเวอร์ NVIDIA ให้ประเมินสถานะพลังงานใหม่
• เดิมควรตรวจสอบสถานะโหมด MUX (HGMD == 0x03) เพื่อให้ทำงานกับ GPU ที่ถูกต้อง แต่ในช่วงการทำงานจริงกลับละเว้นขั้นตอนนี้ ทำให้ มีการสั่ง power cycle แบบหว่านทั่วโดยไม่สนโหมด

ข้อบกพร่องเดียวกันในระดับทั้งระบบ/หลายรุ่น

• ในหลายรุ่น เช่น Scar 15 และ Zephyrus M16 พบว่าเวลาในการรันเหตุการณ์ รอบของ power cycle GPU และรูปแบบการเรียก WMI แทบเหมือนกัน
• คาดว่า Armoury Crate (บริการ WMI) ทำให้อาการนี้แย่ลงอีก

สรุปสาเหตุรากและความล้มเหลวในการออกแบบ

• เข้าใจ interrupt context ผิด: เฟิร์มแวร์ mask สัญญาณ GPE ระหว่างรันเมธอด GPE ทำให้งาน ACPI/EC ถูกบังคับให้ทำแบบอนุกรม และการเรียก Sleep() ภายในทำให้เกิดความหน่วงนานหลายสิบ ms
• จัดการอินเทอร์รัปต์ผิดพลาด: กระตุ้น GPE ซ้ำแบบ self re-arm ไม่สิ้นสุดโดยไม่ล้างแหล่งกำเนิด GPE (ทำหน้าที่เหมือนไทเมอร์แบบเป็นคาบ)
• ไม่รับรู้สถานะแพลตฟอร์ม (ฮาร์ดแวร์): ส่งคำสั่งจัดการพลังงาน GPU โดยไม่ตรวจสอบว่ากำลังอยู่ในโหมด MUX ใด
• โดยรวมแล้วไม่สามารถตอบโจทย์การรับประกันแบบเรียลไทม์ (เช่น เสียง/วิดีโอ) และเป็นสาเหตุที่ไม่ผ่านการทดสอบ Microsoft HLK GlitchFree อย่างเป็นทางการ

รายงานจากผู้ใช้และความต่อเนื่องของปัญหา

• ตั้งแต่ปี 2021 เป็นต้นมา มีการรายงานอาการเดียวกันซ้ำ ๆ ในฟอรัมทางการของ ASUS, Reddit และที่อื่น ๆ
• อาการสอดคล้องกันในทั้งไลน์ผลิตภัณฑ์ รวมถึง Strix, TUF และ G series
• แม้แต่รุ่นใหม่ในช่วงปี 2023~2024 ก็ยังมีข้อบกพร่องเดิมอยู่ และมีเพียงวิธีหลบเลี่ยงชั่วคราวเท่านั้น

บทสรุป: แก่นของปัญหาและนัยสำคัญ

• หลักฐานจากการวัด: ตัวจัดการ GPE บล็อกหนึ่งคอร์นานเกิน 13ms
• หลักฐานจากโค้ด: มีการเรียก Sleep() อย่างชัดเจนภายใน interrupt handler
• หลักฐานจากตรรกะ: ไม่มีการตรวจสอบโหมด MUX
• หลักฐานจากระดับระบบ: ยืนยันการเกิดซ้ำได้ในหลายรุ่น/หลาย BIOS
• นี่คือข้อผิดพลาดในการออกแบบที่ดูเรียบง่ายแต่ร้ายแรง คือ "มี sleep อยู่ใน interrupt handler ที่ไม่มีประสิทธิภาพ และไม่มีการตรวจสอบสถานะ GPU" ส่งผลให้ผู้ใช้โน้ตบุ๊ก ASUS หลายล้านคนประสบอาการสะดุดแม้แต่กับงานพื้นฐาน
• จนถึงเวลาที่มีการวิเคราะห์นี้ ASUS ยังไม่ประกาศแผนรับมือหรือแก้ไขอย่างเป็นทางการ

วิธีการวิเคราะห์และข้อมูลอ้างอิง

• รายงานนี้ได้ข้อสรุปจากการดึงข้อมูลบนเครื่องจริงและวิเคราะห์โค้ด AML โดยตรง ด้วยเครื่องมืออย่าง Windows Performance Toolkit, acpidump และ iasl
• หลักฐานสำคัญทั้งหมด (trace, method, command) สามารถทำซ้ำได้