Lỗi firmware ACPI trên laptop gaming Asus

 (github.com/Zephkek)
2 điểm bởi GN⁺ 2025-09-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • 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

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-09-18
Ý kiến trên Hacker News

  • Thật sự là một phát hiện, bài viết và cả đề xuất sửa lỗi đáng kinh ngạc; nó cho thấy rất rõ PC hiện đại hoạt động như thế nào, và người ta có thể đào sâu đến mức nào vào cả những phần “ẩn” Sau nhiều năm viết firmware nhúng, tôi luôn mơ có ngày người dùng cuối phát hiện ra lỗi ở cấp độ này giúp mình Tôi muốn sống trong một thế giới nơi Asus sẽ mời ngay những người dùng tài năng như vậy làm hợp đồng ngắn hạn, cho họ phối hợp với các kỹ sư firmware vài ngày, trả thù lao hàng chục nghìn đô và tặng lại chiếc laptop với BIOS production mới nhất Thật buồn khi lỗi này đã bị bỏ mặc hơn 4 năm

    • Phân tích nguyên nhân kỹ thuật thì thú vị, nhưng tôi cũng tò mò về phân tích nguyên nhân ở góc độ quy trình kinh doanh Nếu vấn đề này tái hiện rộng rãi như vậy, thật khó hiểu vì sao nó không được báo qua hỗ trợ kỹ thuật hoặc RMA Không rõ là vì bằng chứng quá ít nên không ai liên hệ được các triệu chứng với nhau, hay ASUS đã điều tra nhưng đi đến kết luận sai, ví dụ như cho rằng đó là một lô silicon lỗi, hoặc có lẽ họ có đủ bằng chứng nhưng vẫn phớt lờ Nếu đây là hiện tượng lộ ra ngay trong quá trình sử dụng, thì quy trình QA đã diễn ra thế nào, chẳng phải là kiểu vấn đề không thể bỏ sót sao Giờ khi đã biết, tôi tự hỏi họ có thể sẽ làm gì Nếu là một thương hiệu cao cấp, họ phải xử lý dứt điểm cả vấn đề lẫn việc khôi phục danh tiếng thì thương hiệu mới sống sót được Tôi từng mua ROG, nhưng sau khi thấy chuyện này thì có lẽ sẽ không mua nữa Nghĩ lại thì riêng lỗi firmware này thôi đã thật sự gây sốc Những lỗi khác còn có thể giải thích là do giả định phần cứng thay đổi hoặc do tái sử dụng mã cũ, nhưng cách sleep bên trong interrupt thì quá nghiêm trọng Tôi muốn biết làm sao nó lại qua được code review, và họ đã test firmware kiểu gì

    • AML bytecode của ACPI giống như con dao hai lưỡi Điểm hay là nó cho phép reverse engineering và để người dùng tự phân tích, tự sửa lỗi Nhưng đó là một môi trường lập trình kinh khủng, lại còn đòi phải chạy một interpreter khá nặng với đặc quyền cao nhất của kernel nên rất nguy hiểm Các nhà tích hợp hệ thống thường dùng nó cho những trò lách luật kiểu này, và chất lượng mã thì thường dưới xa kỳ vọng Mỗi khi phải tự viết driver Linux, trải nghiệm quen thuộc luôn là bắt đầu bằng việc vứt bỏ đống mã ACPI

    • Với tư cách là một người dùng và lập trình viên, việc có được kiểu hiểu biết này đúng là như mơ Tôi thấy lượng chuyên môn thể hiện trong bài thật đáng nể Tôi cũng từng phân tích nhiều phần của laptop mình, nhưng đến ACPI thì đụng tường; tôi đã dump table và decompile mã, nhưng toàn thấy mã giả Tôi từng muốn tự viết driver Linux cho laptop của mình nhưng đã thất bại Tôi rất kính trọng những người làm được việc như thế này

    • Tôi tò mò không biết rốt cuộc đã có bản sửa nào chưa Trang Github được liên kết có phải chỉ kết thúc ở mức “tôi đã công khai toàn bộ tư liệu rồi, Asus hãy tự sửa đi” không

    • Phân tích thật sự rất ngầu, và thật đáng nể khi Asus đã đầu tư công sức QA cho chất lượng “rác” như vậy… giả vờ nói thế thôi, chứ thực ra họ chẳng hề cố gắng nên càng thấy chua chát

  • Thật đáng kinh ngạc khi một chiếc laptop gaming lại có tình trạng giật nghiêm trọng suốt 4 năm Điều này khiến tôi tự hỏi vì sao người tiêu dùng không ồ ạt trả lại sản phẩm Tôi trích một ví dụ từ bài Reddit được liên kết: “Tôi đã thử mọi thứ mà vẫn không thay đổi gì, đã gửi bảo hành và đang chờ xem kết quả, bên dịch vụ kết luận ‘không có bất thường’, nên cuối cùng tôi đành quen với nó, đeo tai nghe Bluetooth vào và sống chung với việc không còn để ý thấy vấn đề nữa”

    • Cả hai lần dùng laptop gaming của tôi đều có các vấn đề tương tự mà không được giải quyết Một chiếc là Alienware M17 thế hệ đầu, có dual GTX 270M và GPU Nvidia onboard Nó bị stutter và nhiễu âm thanh; tôi chỉ giải quyết được phần nào bằng cách tắt SLI và GPU onboard, rồi dùng một driver kiếm được trên diễn đàn nào đó Về sau có bản vá BIOS cho phép dùng lại SLI, nhưng rốt cuộc vẫn không bao giờ được sửa triệt để và máy sống hết vòng đời như vậy Chiếc thứ hai là laptop ASUS ROG cũng gần như y hệt Tôi cũng không có kiến thức để đào sâu vào mã ACPI nên không thể sửa triệt để LatencyMon đổ lỗi cho nhiều dll khác nhau, và tôi đã thử cải thiện tạm thời bằng cách thay driver Wi‑Fi, tắt dGPU, v.v. Cũng có những điểm kỳ lạ như trong game thì nhiễu lại xảy ra ít hơn Cuối cùng tôi bỏ hẳn việc mua laptop gaming Đọc bài này xong, tôi có cảm giác đến giờ tình hình vẫn chẳng khá hơn bao nhiêu

    • Đây là kết quả của việc ngành công nghiệp máy tính đã dạy người tiêu dùng suốt nhiều thập kỷ rằng “hỏng hóc là trạng thái bình thường” Nếu ở ngành khác thì sản phẩm kiểu này đã bị trả lại hết ngay ngày đầu 35 năm trước thầy giáo tôi từng ví nó như đôi giày có thể nổ ngẫu nhiên lúc bạn buộc dây Dù vậy, hiện nay xu hướng pháp luật bảo vệ người tiêu dùng đang dần được củng cố

    • Lý do tôi mua sản phẩm ASUS (Zenphyrus G14) là vì đã có lúc ASUS gần như độc quyền dùng Ryzen 4xxxHS của AMD Ban đầu máy chạy rất tốt, nhưng sau hai năm thì bắt đầu lộ rõ suy giảm hiệu năng do thermal throttling Việc trét lại thermal pad chỉ giúp được phần nào, còn nguyên nhân gốc thì tôi không tìm ra Tôi cũng kiểm tra cả việc pin xuống cấp, rồi phát hiện ra vấn đề là iGPU luôn chạy full load Khi đặt ưu tiên dGPU thì thời lượng pin ngược lại còn nhỉnh hơn một chút Thêm các lỗi cơ khí tích tụ nữa nên tôi chuyển sang FW16, và không còn ý định mua lại sản phẩm của các thương hiệu laptop gaming nữa Tôi có cảm giác nhà sản xuất hoàn toàn không quan tâm tới người tiêu dùng nên mất luôn động lực mua hàng

    • Lỗi này chỉ xảy ra ở chế độ Ultimate Nó chỉ xuất hiện khi người dùng chủ động chuyển MUX sang dGPU Đây là một tính năng bổ sung quan trọng nếu bạn chủ yếu chơi game bằng màn hình ngoài Ở chế độ Optimus thì màn hình ngoài vẫn hoạt động tốt, chỉ bị giảm nhẹ hiệu năng và mất một số tính năng hiển thị như G-Sync Có lẽ phần lớn người dùng chỉ chạy ở chế độ Optimus nên hầu như không có cơ hội phát hiện lỗi này Cốt lõi vấn đề là Asus đã xuất xưởng tính năng phần cứng bổ sung mà không QA test tử tế Có vẻ họ chỉ có xu hướng test thật kỹ “golden path”

    • Người dùng laptop Windows đã quá chai lì với thực tế là mọi thứ không bao giờ hoạt động hoàn hảo, nên hình thành thói quen cứ chịu đựng sự bất tiện

  • Phần mở đầu bài viết nói có dùng LLM (Large Language Model), và đúng là cảm giác đó lộ ra rất rõ Thông tin thì vững, nhưng cái tông giọng bị làm phẳng quá mức như vậy khiến nó không giống tác phẩm của con người nên tôi không thích Tôi không hiểu vì sao ai cũng cố né tránh những cách diễn đạt mang tính con người hơn

  • Tôi tự hỏi vì sao các reviewer sản phẩm, kể cả những nơi thân thiện với người tiêu dùng và có danh tiếng như rtings hay notebookcheck, lại không nhắc đến trong review ngay cả những nhược điểm mà ai cũng biết Mua sản phẩm vì bị thuyết phục bởi truyền miệng và những bài đánh giá xuất sắc, rồi gặp vấn đề và lên Reddit chỉ thấy phản ứng kiểu “cái nào cũng vậy thôi” thì thật chán nản Tôi thực sự muốn biết vì sao lại có thứ văn hóa đó

    • Để thật sự tìm ra vấn đề, bạn phải để MUX switch ở chế độ dGPU only và chạy LatencyMon hơn 2 phút (Tôi không biết ở chế độ iGPU free pass thì có như vậy không) notebookcheck thực sự có ghi lại chỉ số latencymon và còn nêu rõ là không phù hợp cho audio thời gian thực
      ví dụ review trên notebookcheck Nhưng họ đã không phát hiện được mức latency cực đoan như thế này

    • Nếu muốn nhìn trực diện và nhạy hơn, thì việc xem các trang review đó được ai tài trợ là một hướng suy nghĩ hợp lý

  • Tôi tự hỏi liệu “lập trình viên” đó (dù không hẳn là cách gọi chính xác) có thật sự test đoạn mã sleep trong interrupt hay không, hay nó bị đẩy qua một bộ phận khác vốn chẳng quan tâm Rất có thể họ chỉ thấy bộ test tự động qua là “mặc kệ” Nếu có quy trình dogfooding kiểu Microsoft, tức là để chính lập trình viên dùng sản phẩm của công ty mình trong thực tế, thì có lẽ họ đã gặp hiện tượng này ngay trên laptop của mình và sửa nó rồi

    • Trước đây khi tôi làm contractor firmware cho một công ty phần cứng lớn ở Đài Bắc, tôi đã hình thành thói quen bỏ qua bug hoàn toàn Mỗi lần báo bug thì lại bị mắng vì làm việc ngoài phần được giao Đội phần cứng gọi các lập trình viên firmware/driver/software bằng những danh xưng bề trên và có không khí coi thường phản hồi Nên những câu chuyện như thế này không làm tôi ngạc nhiên

  • Cùng một vấn đề cũng xảy ra trên laptop gaming MSI đời 2019 của tôi (GS65 Stealth) Chỉ trong vòng 1 phút chạy LatencyMon là đã liên tục xuất hiện stutter >10ms Nếu tắt mọi thiết bị ACPI thì stutter biến mất, nhưng đồng thời cũng không dùng được dGPU Tôi nghi ngờ vấn đề này có thể liên quan rộng rãi tới nhiều laptop gaming có dGPU Tôi cũng giới thiệu bài trên diễn đàn MSI về hiện tượng trễ ACPI Tôi khuyên nên tìm kiếm với cụm "nvidia gaming laptop stutter latencymon acpi"

  • Tóm lại: đừng mua laptop gaming ASUS cho đến khi lỗi này được giải quyết hoàn toàn; nếu còn trong thời hạn bảo hành thì nên nộp yêu cầu bảo hành và sẵn sàng theo tới cả Small Claims Court

    • Phần lớn laptop vốn dĩ còn không có chế độ dGPU only là nơi lỗi này lộ ra Thực tế là trên laptop của tôi, tôi chưa từng dùng chế độ dGPU only qua MUX, và chế độ đó chỉ tốn điện hơn mà chẳng được lợi mấy

  • Tôi hiểu vì sao có người lại đẩy mạnh mac sản xuất tại Mỹ Thật khó tin là một vấn đề nghiêm trọng thế này lại bị xuất xưởng suốt gần 4 năm Ít nhất thì tôi đã xác định rõ sau này mình sẽ không mua gì nữa

    • Apple cũng từng có vấn đề tương tự Ví dụ như vụ từ chối lỗi firmware EFI
      bài liên quan

    • Ngay cả với những người ở “ngoài trường biến dạng thực tại”, Apple vẫn rõ ràng có những vấn đề của riêng mình

    • Tôi đã dùng Mac ở công ty suốt 8 năm, nhìn chung chạy ổn, nhưng từng gặp hai rắc rối lớn a) Có lần máy đột nhiên không sạc được nữa, tôi phải tranh thủ chuyển dữ liệu khi pin còn đầy để cứu hộ, và lúc đó rất tiếc vì không có thiết bị lưu trữ tháo rời b) Trong suốt 1 năm, khi bắt đầu stream bằng iTunes thì khoảng 25% xác suất thay vì phát nhạc sẽ phát ra tiếng nhiễu rất nặng; phát lại thì hầu hết là hết Nó bắt đầu ở một phiên bản OS cụ thể và được sửa ở bản tiếp theo, các ứng dụng khác thì không bị như vậy Vì cái nhận thức rằng “mac vốn dĩ hoàn hảo” nên thông tin cũng ít và tôi chỉ biết loay hoay tự xử Nhẹ hơn nữa là nếu mở Outlook rồi đóng nắp laptop thì sẽ bị hao pin và nóng máy Outlook vốn đã nổi tiếng tệ, nhưng trong công ty dùng Exchange thì tôi vẫn nghĩ cứ dùng nó còn hơn

    • Laptop MSI cũng từng có lỗi EFI khiến việc chạy lệnh rm -rf / làm máy không thể khởi động UEFI
      mô tả issue

    • Về câu “đẩy mạnh mac”, tôi muốn hỏi liệu điều đó có đúng cả với game thủ hay người dùng VR không

  • Từ khoảng năm 2015, tôi đã quyết định sẽ không bao giờ mua lại laptop có đồ họa chuyển đổi nữa, và quyết định đó hóa ra rất hiệu quả Mỗi khi thấy các thương hiệu “cao cấp” chỉ đầu tư tiền lẻ cho đội phát triển firmware nhưng lại đốt rất nhiều tiền cho marketing, tôi luôn thấy buồn cười

    • Tôi cũng vậy; sau khi dùng một laptop "Optimus" vào năm 2013, tôi đã thề sẽ không đụng lại nữa Dù phải vất vả hơn với desktop hoặc server, tôi chưa bao giờ hối hận vì cuối cùng đã quay về chỉ dùng iGPU

  • ASUS chỉ cần đầu tư 0.01% ngân sách marketing là đã có thể cải thiện trải nghiệm của hàng triệu người dùng, giảm chi phí đổi trả và nâng cao danh tiếng thương hiệu Hiện tượng này cho thấy nhiều công ty đang vận hành tổ chức sai lầm vì tin nhầm rằng marketing hiệu quả hơn kỹ thuật tốt