บั๊กเฟิร์มแวร์ 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) สามารถทำซ้ำได้

[GN⁺]

ความเห็นบน Hacker News

• ทึ่งมากกับการค้นพบ บทความ และข้อเสนอแพตช์นี้ มันแสดงให้เห็นได้ดีว่าพีซีสมัยใหม่ทำงานอย่างไร และเราสามารถขุดลึกเข้าไปได้มากแค่ไหนแม้กระทั่งในส่วนที่ "ซ่อนอยู่" หลังจากเขียนเฟิร์มแวร์แบบ embedded มาหลายปี ผมเคยฝันมาตลอดว่าอยากให้ผู้ใช้ปลายทางค้นพบบั๊กระดับนี้ให้ได้ อยากอยู่ในโลกที่ Asus เชิญผู้ใช้ที่มีพรสวรรค์แบบนี้มาเป็นพนักงานสัญญาระยะสั้น ให้ร่วมงานกับวิศวกรเฟิร์มแวร์สักสองสามวัน จ่ายค่าตอบแทนระดับหลายหมื่นดอลลาร์ และเปลี่ยนเครื่องเป็นโน้ตบุ๊กรุ่นใหม่พร้อม Production BIOS ล่าสุดให้เลย น่าเศร้าที่บั๊กนี้ถูกปล่อยทิ้งไว้นานกว่า 4 ปี

  • การวิเคราะห์สาเหตุทางเทคนิคก็น่าสนใจ แต่ผมก็อยากรู้การวิเคราะห์สาเหตุในเชิงกระบวนการธุรกิจด้วย ถ้าปัญหานี้เกิดซ้ำได้ในวงกว้าง ทำไมมันถึงไม่ถูกรายงานผ่านฝ่ายซัพพอร์ตหรือ RMA กันนะ สงสัยว่าเพราะหลักฐานมีน้อยเกินไปจนโยงกันไม่ออก หรือว่า ASUS สืบสวนแล้วแต่สรุปผิดเอง เช่น โยนว่าเป็นล็อตซิลิคอนเสีย หรือไม่ก็มีหลักฐานพอแล้วแต่เลือกจะเมินมัน ถ้าอาการมันโผล่ชัดหลังใช้งานไม่นาน กระบวนการ QA ตอนนั้นเป็นยังไง ถึงพลาดสิ่งที่เหมือนจะพลาดไม่ได้แบบนี้ไปได้ ตอนนี้เมื่อรู้แล้วก็สงสัยว่าจะมีมาตรการอะไรตามมาบ้าง ถ้าเป็นแบรนด์หรู ก็ต้องจัดการทั้งการแก้ปัญหาและกู้ชื่อเสียงให้เด็ดขาด ไม่งั้นแบรนด์อยู่ไม่รอด ผมเคยซื้อ ROG มาก่อน แต่พอเห็นปัญหาแบบนี้แล้วคงไม่ซื้ออีก คิดอีกที ตัวบั๊กเฟิร์มแวร์นี้เองก็ช็อกมากจริงๆ บั๊กอื่นยังพออธิบายได้ว่าเกิดจากสมมติฐานฮาร์ดแวร์เปลี่ยน หรือจากการเอาโค้ดเก่ากลับมาใช้จนพลาด แต่การไป sleep ใน interrupt นี่หนักมาก ไม่รู้มันผ่าน code review มาได้ยังไง และทดสอบเฟิร์มแวร์กันแบบไหน

  • AML bytecode ของ ACPI เป็นเหมือนดาบสองคม ข้อดีคือมันเปิดทางให้ทำ reverse engineering และให้ผู้ใช้วิเคราะห์กับแก้บั๊กเองได้ แต่ในอีกด้านหนึ่ง มันเป็นสภาพแวดล้อมการเขียนโปรแกรมที่เลวร้าย แถมยังต้องรัน interpreter ที่ค่อนข้างหนักด้วยสิทธิ์สูงสุดของเคอร์เนล จึงอันตรายมาก พวก system integrator มักชอบใช้มันเป็นทางลัด แต่คุณภาพโค้ดก็มักต่ำกว่าที่ควร เวลาต้องเขียนไดรเวอร์ Linux เอง ประสบการณ์ของผมคือเริ่มจากโยนโค้ด ACPI ทิ้งก่อนเสมอ

  • ในฐานะผู้ใช้และโปรแกรมเมอร์ การมีความรู้เชิงช่างแบบนี้เหมือนฝันเลย รู้สึกว่าความเชี่ยวชาญที่ใส่อยู่ในบทความนั้นยอดเยี่ยมมาก ผมเองก็เคยวิเคราะห์ส่วนต่างๆ ของโน้ตบุ๊ก แต่จะไปติดกำแพงตรง ACPI เสมอ ทั้ง dump ตารางและ decompile โค้ดแล้วก็ยังเจอแต่โค้ดหลอก ผมอยากเขียนไดรเวอร์ Linux สำหรับโน้ตบุ๊กตัวเอง แต่สุดท้ายก็ไม่สำเร็จ ขอคารวะคนที่ทำเรื่องแบบนี้ได้จริง

  • สงสัยว่ามีแพตช์แบบไหนออกมาหรือเปล่า หน้า Github ที่ลิงก์ไว้นี่จบแค่ประมาณว่า "ผมเปิดข้อมูลทั้งหมดแล้ว ที่เหลือ Asus ไปแก้เอาเอง" ใช่ไหม

  • เป็นการวิเคราะห์ที่เจ๋งมาก และก็น่าทึ่งที่ Asus ทุ่มเทกับการทำ QA ให้คุณภาพระดับ "ขยะ" แบบนี้… พูดเล่นน่ะ จริงๆ คือแทบไม่ได้พยายามอะไรเลย เลยยิ่งขมขื่น

• น่าตกใจที่โน้ตบุ๊กเกมมิ่งมีอาการกระตุกหนักแบบนี้ต่อเนื่องมาถึง 4 ปี มันทำให้อยากรู้จิตวิทยาว่าทำไมผู้บริโภคถึงไม่พากันคืนของเป็นจำนวนมาก ขอยกตัวอย่างจากโพสต์ Reddit ที่ลิงก์ไว้: "ลองทุกอย่างแล้วก็ไม่ดีขึ้น ส่งเคลมประกันไปแล้ว รอดูผล สุดท้ายศูนย์บอกว่า ‘ไม่พบความผิดปกติ’ ก็เลยชินกับมันไปเอง ใส่หูฟังบลูทูธแล้วจะได้ไม่สังเกตปัญหา"

  • ประสบการณ์กับโน้ตบุ๊กเกมมิ่งสองครั้งของผมก็ลงเอยแบบปัญหาคล้ายๆ กันและไม่เคยแก้ได้ เครื่องแรกคือ Alienware M17 รุ่นแรก มาพร้อม dual GTX 270M และ Nvidia GPU แบบออนบอร์ด มีอาการกระตุกและเสียงรบกวน ผมปิด SLI กับ GPU ออนบอร์ด แล้วใช้ไดรเวอร์ที่หาเจอจากฟอรัมบางแห่ง ซึ่งช่วยได้แค่บางส่วน หลังจากนั้นมี BIOS patch ออกมาจนกลับมาใช้ SLI ได้ แต่ก็ไม่เคยแก้ได้สมบูรณ์ และสุดท้ายเครื่องก็หมดอายุการใช้งานไป เครื่องที่สองเป็น ASUS ROG ซึ่งก็มีอาการแทบเหมือนกัน ผมเองก็ไม่มีความรู้พอจะขุดเข้าไปถึงโค้ด ACPI เลยแก้ไม่จบ LatencyMon โยนความผิดไปที่ dll หลายตัว ผมก็ลองเปลี่ยนไดรเวอร์ Wi‑Fi ปิด dGPU ฯลฯ เพื่อบรรเทาชั่วคราว ยังมีเรื่องแปลกอีก เช่น ตอนเล่นเกมกลับมีเสียงรบกวนน้อยกว่า สุดท้ายก็เลิกซื้อโน้ตบุ๊กเกมมิ่งไปเลย พออ่านบทความนี้แล้วก็รู้สึกว่าสถานการณ์ทุกวันนี้ก็ไม่ได้ดีขึ้นเท่าไร

  • นี่คือผลจากอุตสาหกรรมคอมพิวเตอร์ที่สอนผู้บริโภคมาหลายสิบปีว่า "ของเสียๆ แบบนี้แหละคือเรื่องปกติ" ถ้าเป็นอุตสาหกรรมอื่น ของแบบนี้คงโดนคืนตั้งแต่วันแรก ครูของผมเมื่อ 35 ปีก่อนเคยเปรียบมันเหมือนรองเท้าที่สุ่มระเบิดตอนผูกเชือก อย่างน้อยตอนนี้ก็เริ่มมีแนวโน้มที่กฎหมายคุ้มครองผู้บริโภคจะเข้มแข็งขึ้น

  • เหตุผลที่ผมซื้อ ASUS รุ่น Zenphyrus G14 ก็เพราะช่วงหนึ่ง ASUS ผูกขาดการใช้ AMD Ryzen 4xxxHS ตอนแรกประสิทธิภาพดีมาก แต่ผ่านไปสองปีก็เริ่มเห็นว่าประสิทธิภาพตกจาก thermal throttling การทา thermal pad ใหม่ช่วยได้แค่บางส่วน และก็ยังหาต้นตอจริงๆ ไม่เจอ ผมยังไล่ดูเรื่องแบตเสื่อมด้วย แต่สุดท้ายพบว่าปัญหาคือ iGPU ทำงานเต็มโหลดตลอดเวลา พอตั้งให้ dGPU เป็นตัวหลัก กลับทำให้อายุแบตดีขึ้นเล็กน้อยเสียอีก พอรวมกับปัญหาเชิงกลที่ตามมา ผมก็ย้ายไปใช้ FW16 และหมดความคิดที่จะซื้อโน้ตบุ๊กแบรนด์เกมมิ่งอีก มันให้ความรู้สึกว่าผู้ผลิตไม่แคร์ผู้บริโภคเลย จนหมดอารมณ์จะซื้อ

  • บั๊กนี้เกิดเฉพาะในโหมด Ultimate เท่านั้น คือจะเกิดก็ต่อเมื่อผู้ใช้สั่งสลับ MUX ไปใช้ dGPU โดยตรงอย่างชัดเจน ฟีเจอร์นี้เป็นส่วนเสริมสำคัญสำหรับคนที่เล่นเกมบนจอนอกเป็นหลัก ในโหมด Optimus จอนอกก็ยังใช้งานได้ปกติ เพียงแต่เสียประสิทธิภาพไปเล็กน้อย และฟีเจอร์จอบางอย่างอย่าง G-Sync จะถูกจำกัด ผู้ใช้ส่วนใหญ่อาจใช้แค่โหมด Optimus ตลอด เลยแทบไม่มีโอกาสรู้ว่ามีข้อบกพร่องนี้อยู่ แก่นของปัญหาคือ Asus ส่งมอบฟีเจอร์ฮาร์ดแวร์เพิ่มเติมออกมาโดยแทบไม่ได้ QA ทดสอบให้ดีพอ ดูเหมือนจะมีแนวโน้มทดสอบแค่ "golden path" ให้ผ่านแน่ๆ เท่านั้น

  • ผู้ใช้โน้ตบุ๊ก Windows ชาชินกับความจริงที่ว่ามันทำงานไม่สมบูรณ์อยู่แล้ว เลยฝึกตัวเองให้ทนกับความไม่สะดวกไปเรื่อยๆ

• บทนำของบทความบอกว่าใช้ LLM (Large Language Model) และก็สัมผัสได้ชัดเจนมากว่าเป็นสไตล์แบบนั้น ข้อมูลแน่นก็จริง แต่โทนที่ถูกทำให้เรียบเกินไปแบบนี้ทำให้งานไม่ดูเหมือนมนุษย์เขียน เลยไม่ค่อยชอบ สงสัยว่าทำไมทุกคนถึงพยายามเลี่ยงการเขียนให้ดูเป็นมนุษย์กันหมด

• ผมสงสัยว่าทำไมคนรีวิวสินค้า แม้แต่เจ้าใหญ่ที่ขึ้นชื่อว่าเป็นมิตรกับผู้บริโภคอย่าง rtings หรือ notebookcheck ก็ไม่พูดถึงข้อเสียที่ใครๆ ก็รู้กันอยู่แล้วในรีวิว พอซื้อสินค้าตามกระแสปากต่อปากและ stellar review แล้วมาเจอปัญหา จากนั้นไปเจอคนใน Reddit ตอบว่า "มันก็เป็นกันแบบนี้ทุกเครื่อง" ก็ได้แต่ขมขื่น อยากรู้จริงๆ ว่าวัฒนธรรมแบบนี้มันเกิดขึ้นได้ยังไง

  • ถ้าจะหาปัญหานี้ให้เจอจริงๆ ต้องตั้ง MUX switch เป็นโหมด dGPU only แล้วเปิด LatencyMon ทิ้งไว้เกิน 2 นาที (ไม่แน่ใจว่าในโหมด iGPU freepass จะเป็นด้วยไหม) notebookcheck มีการบันทึกค่าจาก latencymon ไว้จริง และถึงขั้นระบุว่าไม่เหมาะกับงานเสียงแบบเรียลไทม์
    ตัวอย่างรีวิวจาก notebookcheck แต่ก็ยังตรวจไม่พบ latency สุดโต่งระดับนี้

  • ถ้ามองแบบตรงไปตรงมาและไวต่อประเด็นหน่อย ก็สมเหตุสมผลที่จะเช็กว่าเว็บไซต์รีวิวพวกนั้นได้รับการสนับสนุนจากใคร

• สงสัยว่า "โปรแกรมเมอร์" คนนั้น (แม้จะไม่ใช่คำที่ตรงนัก) เคยทดสอบโค้ดที่ sleep อยู่ใน interrupt ด้วยตัวเองหรือเปล่า หรือเป็นเพราะงานถูกแยกเป็นไซโลจนอีกแผนกก็ปล่อยผ่านแบบไม่สนใจ มีโอกาสสูงว่าแค่ผ่าน automated test แล้วก็ "ช่างมัน" ถ้ามีกระบวนการแบบ dogfooding ของ Microsoft คือให้นักพัฒนาใช้สินค้าตัวเองจริงๆ ก็น่าจะมีใครสักคนเจออาการนี้บนโน้ตบุ๊กตัวเองแล้วแก้ไปแล้ว

  • เมื่อก่อนตอนผมรับงานเฟิร์มแวร์ให้บริษัทฮาร์ดแวร์ใหญ่แห่งหนึ่งในไทเป ผมก็ซึมซับนิสัยการเมินบั๊กมาเหมือนกัน ถ้ารายงานบั๊กเข้าไป จะโดนดุว่ามัวแต่ไปยุ่งกับเรื่องนอกเหนือจากงานที่ได้รับมอบหมาย ทีมฮาร์ดแวร์เรียกนักพัฒนาเฟิร์มแวร์/ไดรเวอร์/ซอฟต์แวร์ด้วยสรรพนามเชิงดูถูก และบรรยากาศก็เป็นแบบที่ไม่รับฟัง feedback อยู่แล้ว เลยไม่ได้รู้สึกว่าเรื่องแบบนี้น่าแปลกใจอะไร

• ปัญหาเดียวกันนี้เกิดกับโน้ตบุ๊กเกมมิ่ง MSI ปี 2019 ของผม (GS65 Stealth) ด้วย เปิด LatencyMon ไม่ถึง 1 นาทีก็มีอาการกระตุกเกิน 10ms โผล่มาต่อเนื่อง ถ้าปิดใช้งานอุปกรณ์ ACPI ทั้งหมด อาการกระตุกจะหายไป แต่ก็จะใช้ dGPU ไม่ได้ด้วย ผมสงสัยว่าปัญหานี้อาจเกี่ยวข้องอย่างกว้างขวางกับโน้ตบุ๊กเกมมิ่งหลายรุ่นที่มี dGPU มีการแนะนำโพสต์นี้ด้วย: โพสต์ในฟอรัม MSI เรื่องอาการหน่วงจาก ACPI และแนะนำให้ลองค้นหา "nvidia gaming laptop stutter latencymon acpi"

• สรุป: อย่าซื้อโน้ตบุ๊กเกมมิ่ง ASUS จนกว่าข้อบกพร่องนี้จะถูกแก้จนหมดจริง และถ้ายังอยู่ในประกันก็ควรยื่นเคลม รวมถึงเตรียมใจไปถึง Small Claims Court ด้วย

  • โน้ตบุ๊กส่วนใหญ่ไม่มีโหมด dGPU only ซึ่งเป็นโหมดที่ทำให้บั๊กนี้แสดงอาการออกมาตั้งแต่แรกด้วยซ้ำ ที่จริงแล้วบนโน้ตบุ๊กของผมเองก็ไม่เคยใช้โหมด dGPU only ผ่าน MUX เลย เพราะมันกินไฟมากขึ้นและแทบไม่ได้อะไรตอบแทน

• เข้าใจคนที่เชียร์ mac จากอเมริกาเลย ไม่น่าเชื่อว่าปัญหาร้ายแรงขนาดนี้จะถูกส่งมอบต่อเนื่องมานานเกือบ 4 ปี อย่างน้อยตอนนี้ผมรู้ชัดแล้วว่าอนาคตจะไม่ซื้ออะไร

  • Apple เองก็เคยมีปัญหาคล้ายกัน ตัวอย่างเช่นเคยมีกรณีปฏิเสธปัญหา EFI firmware
    บทความที่เกี่ยวข้อง

  • สำหรับผู้ใช้ที่อยู่นอก "สนามบิดเบือนความจริง" ปัญหาภายในของ Apple เองก็มีอยู่ชัดเจน

  • ผมใช้ Mac ของบริษัทมาประมาณ 8 ปี โดยรวมถือว่าใช้ได้ดี แต่ก็เคยเจอปัญหาใหญ่สองอย่าง a) อยู่ๆ ก็ชาร์จไม่เข้า ครั้งนั้นตอนแบตยังเต็มอยู่เลยรีบย้ายข้อมูลออกมาเพื่อกู้สถานการณ์ ทำให้นึกเสียดายที่ถอดสตอเรจออกไม่ได้ b) อยู่ช่วงหนึ่งประมาณ 1 ปี เวลาเริ่มสตรีมผ่าน iTunes จะมีโอกาสราว 25% ที่แทนจะได้ยินเพลงกลับกลายเป็นเสียง noise รุนแรง แต่กดเล่นใหม่ก็มักหาย มันเริ่มเกิดใน OS เวอร์ชันหนึ่ง แล้วหายในเวอร์ชันถัดไป และไม่เคยเกิดกับแอปอื่น เพราะภาพจำว่า "Mac เดิมทีก็สมบูรณ์แบบอยู่แล้ว" เลยแทบไม่มีข้อมูลให้ค้น ต้องลองผิดลองถูกเองเยอะมาก ยังมีปัญหาที่เบากว่านั้น เช่น ถ้าเปิด Outlook แล้วปิดฝาแล็ปท็อป เครื่องจะกินแบตและร้อนขึ้น แม้ Outlook จะชื่อเสียอยู่แล้ว แต่ในบริษัทที่ใช้ Exchange ก็ทำให้รู้สึกว่ายังไงก็ต้องทนใช้มันต่อไป

  • โน้ตบุ๊ก MSI ก็เคยมีปัญหา EFI bug ที่ทำให้เมื่อรันคำสั่ง rm -rf / แล้วเครื่องบูต UEFI ไม่ได้จริง
    คำอธิบายปัญหา

  • คำว่า "เชียร์ Mac" นี่หมายความว่าใช้กับเกมเมอร์หรือผู้ใช้ VR ได้ด้วยหรือเปล่า

• ตั้งแต่ราวปี 2015 ผมก็ตัดสินใจว่าจะไม่ซื้อโน้ตบุ๊กแบบ switchable graphics อีกเลย และการตัดสินใจนี้ก็ได้ผลดีมาก เวลามองแบรนด์ "พรีเมียม" ที่ลงทุนกับคนทำเฟิร์มแวร์แค่เศษเงิน แต่ทุ่มงบมหาศาลกับการตลาดทีไร ก็รู้สึกขำทุกครั้ง

  • ผมเองก็เคยใช้โน้ตบุ๊ก "Optimus" ในปี 2013 แล้วสาบานว่าจะไม่แตะมันอีก ถึงจะต้องลำบากไปใช้เดสก์ท็อปหรือเซิร์ฟเวอร์มากขึ้น แต่สุดท้ายก็ไม่เคยเสียใจที่ลงเอยด้วยการใช้แต่ iGPU

• ASUS ถ้าลงทุนเพียง 0.01% ของงบการตลาด ก็อาจปรับปรุงประสบการณ์ของผู้ใช้ได้หลายล้านคน ลดต้นทุนการเปลี่ยนสินค้า และยกระดับชื่อเสียงแบรนด์ได้ ปรากฏการณ์แบบนี้เป็นหลักฐานว่าหลายบริษัทบริหารองค์กรผิดทาง เพราะเชื่อผิดๆ ว่าการตลาดมีประสิทธิภาพมากกว่าวิศวกรรมที่ดี