Lỗi firmware ACPI trên laptop gaming Asus

• Trên các laptop gaming ASUS ROG, hiện tượng độ trễ DPC của ACPI.sys gây ra các vấn đề suy giảm hiệu năng nghiêm trọng như âm thanh bị ngắt quãng, chuột bị khựng và lỗi phát video
• Nguyên nhân xuất phát từ mã ACPI Machine Language (AML) kém hiệu quả hoặc bị lỗi trong firmware (BIOS), nên không thể khắc phục bằng cách thay hệ điều hành hay trình điều khiển
• Các sự kiện phần cứng định kỳ (GPE) và các tác vụ liên quan đến bộ điều khiển nhúng (EC) chiếm dụng riêng lõi CPU 0, và việc xử lý ngắt sai như gọi Sleep() làm ảnh hưởng xấu đến độ trễ và khả năng phản hồi của hệ thống
• Firmware lặp đi lặp lại chu kỳ cấp nguồn GPU mà không nhận biết chế độ MUX, từ đó gây ra nhiều lỗi khác nhau, từ treo hệ thống tạm thời đến màn hình xanh
• Vấn đề này đã được báo cáo nhất quán trên nhiều mẫu laptop gaming ASUS kể từ sau năm 2021, và ASUS vẫn chưa có phản hồi chính thức

---

Ý nghĩa và bối cảnh của dự án

Kho mã nguồn mở này là một báo cáo kỹ thuật chuyên sâu phân tích nguyên nhân gốc rễ của vấn đề độ trễ DPC của ACPI.sys lặp đi lặp lại trên các laptop gaming ASUS (như dòng ROG) ở cấp firmware và bảng ACPI. Các mẫu hiệu năng cao tiêu biểu như Zephyrus, Strix và Scar thường xuyên gặp hiện tượng giật, lag và lỗi âm thanh ngay cả trong các tình huống sử dụng cơ bản như xem YouTube, gọi thoại/gọi video hay di chuyển chuột. Nhiều nỗ lực như đổi driver, cài lại Windows hoặc chuyển sang Linux đều không có tác dụng; nguyên nhân duy nhất nằm ở mã AML sai trong firmware.

Triệu chứng chính và kết quả đo đạc

• Khi đo bằng các công cụ như LatencyMon, hệ thống bị đánh giá là không đủ khả năng xử lý âm thanh thời gian thực và các tác vụ khác
• Xác nhận rằng driver ACPI.sys chiếm dụng một lõi cụ thể (CPU 0) trong thời gian dài ở các routine ngắt và DPC
  • Độ trễ interrupt-to-process: tối đa 65,816μs, trung bình 23.29μs
  • Độ trễ routine DPC: tối đa 5,998μs
• CPU 0 bị dùng riêng để xử lý ngắt trong hơn 90 giây, cho thấy đây không phải lỗi cân bằng tải mà là firmware được thiết kế để chiếm dụng một lõi đơn
• Nguyên nhân không phải chỉ là vấn đề driver Windows, mà bắt nguồn từ việc mã AML kém hiệu quả hoặc lỗi trong firmware được chuyển cho ACPI.sys để thực thi. Đặc biệt, lưu lượng GPE (General Purpose Events) và Embedded Controller (EC) là nguồn gây lỗi

Phân tích chi tiết: truy vết log ACPI nâng cao và mẫu lỗi

• Kết quả từ Windows Performance Analyzer và truy vết ETW cho thấy hiện tượng độ trễ này xảy ra định kỳ theo chu kỳ 30~60 giây
• Trình xử lý sự kiện chính _GPE._L02 chạy rất lâu (ví dụ: 13.6ms), khiến hiệu năng thời gian thực suy giảm nghiêm trọng
• Các lệnh quản lý nguồn GPU liên tục lặp lại bất kể trạng thái chế độ MUX (chọn đa đồ họa), và hệ thống vẫn cố thực hiện chuyển trạng thái vốn không thể xảy ra trong môi trường mà chỉ dGPU được nối với màn hình
• Trong quá trình này, các lỗi nghiêm trọng có thể phát sinh như máy tính bị dừng bằng màn hình xanh (BSOD) hoặc luồng driver rơi vào trạng thái chờ vô hạn

Trích xuất và dịch ngược mã firmware

• Trích xuất bảng ACPI bằng các công cụ như acpidump, iasl rồi dịch ngược để phân tích
• Trình xử lý GPE có vấn đề, ở dạng đơn giản, là
  • _L02: \_SB.PC00.LPCB.ECLV() được gọi
• Nhưng bên trong phương thức ECLV() thì có
  • Lặp lại các lệnh dừng CPU như Sleep(25~100ms)
  • Tự tạo sự kiện ngay cả khi hàng đợi sự kiện EC trống (tự tái kích hoạt), tạo ra mẫu lặp vô hạn
• Việc gọi sleep bên trong GPE là hành vi bị cấm trong ngữ cảnh ngắt, khiến một lõi bị chặn hàng chục ms, ảnh hưởng xấu đến lập lịch thời gian thực, đầu vào, âm thanh, v.v.

Logic xử lý/phân phối sự kiện và quản lý nguồn

• Sự kiện GPE dẫn đến việc gọi các hàm bao liên quan đến trạng thái pin và chuyển đổi nguồn GPU/màn hình
• PWCG(): polling trạng thái pin/bộ đổi nguồn AC và lặp lại tín hiệu thông báo cho hệ điều hành
• NOD2(): thông báo cho driver NVIDIA đánh giá lại trạng thái nguồn
• Lẽ ra phải kiểm tra trạng thái chế độ MUX (HGMD == 0x03) để tác động đúng GPU, nhưng trong đoạn thực tế bước này bị bỏ qua, khiến các lệnh chu kỳ nguồn được lặp lại bừa bãi bất kể chế độ nào

Cùng một lỗi trên toàn hệ thống/nhiều mẫu máy

• Trên nhiều mẫu như Scar 15 và Zephyrus M16, thời gian thực thi sự kiện, chu kỳ nguồn GPU và mẫu gọi WMI được quan sát gần như giống hệt nhau
• Có suy đoán rằng Armoury Crate (dịch vụ WMI) làm hiện tượng này trầm trọng hơn

Tóm tắt nguyên nhân gốc rễ và thất bại trong thiết kế

• Hiểu sai ngữ cảnh ngắt: firmware che tín hiệu GPE trong lúc thực thi phương thức GPE, khiến tác vụ ACPI/EC bị tuần tự hóa, và việc gọi Sleep() bên trong làm độ trễ tăng lên hàng chục ms
• Xử lý ngắt sai: lặp GPE bằng cơ chế tự tái kích hoạt vô hạn mà không xóa nguồn GPE (đóng vai trò như bộ hẹn giờ định kỳ)
• Không nhận biết trạng thái nền tảng (phần cứng): gửi lệnh quản lý nguồn GPU mà không kiểm tra chế độ MUX
• Nhìn chung, hệ thống không đáp ứng yêu cầu đảm bảo thời gian thực (âm thanh/video, v.v.), và trở thành nguyên nhân không vượt qua bài kiểm thử chính thức HLK GlitchFree của Microsoft

Báo cáo người dùng và tính dai dẳng của lỗi

• Từ năm 2021, cùng một hiện tượng liên tục được nêu trên diễn đàn chính thức của ASUS, Reddit và các nơi khác
• Triệu chứng nhất quán trên toàn bộ dòng sản phẩm, bao gồm Strix, TUF và G-series
• Lỗi tương tự vẫn tồn tại tới các mẫu mới nhất 2023~2024, chỉ có giải pháp vòng tránh tạm thời

Kết luận: bản chất của vấn đề và hàm ý

• Bằng chứng đo đạc: trình xử lý GPE khóa một lõi trong hơn 13ms
• Bằng chứng mã: có lệnh Sleep() rõ ràng bên trong trình xử lý ngắt
• Bằng chứng logic: thiếu kiểm tra chế độ MUX
• Bằng chứng hệ thống: đã xác nhận tái hiện trên nhiều mẫu máy/BIOS
• Đây là một lỗi thiết kế đơn giản nhưng chí mạng: “sleep kém hiệu quả trong trình xử lý ngắt và không xác minh trạng thái GPU”, khiến hàng triệu người dùng laptop ASUS gặp giật lag ngay cả với tác vụ cơ bản
• Tính đến thời điểm phân tích này, ASUS vẫn chưa đưa ra kế hoạch phản hồi/sửa lỗi chính thức

Phương pháp phân tích và tham khảo

• Báo cáo này được xây dựng bằng cách trích xuất dữ liệu trên thiết bị thực và phân tích trực tiếp mã AML bằng các công cụ như Windows Performance Toolkit, acpidump và iasl
• Mọi bằng chứng chính (trace, phương thức, lệnh) đều có thể tái hiện