Linus Torvalds cùng AI tìm ra lỗi GPU Intel Xe chỉ bằng một dòng mã

Một thay đổi chỉ gồm một dòng mã đã khắc phục lỗi nghiêm trọng trong driver đồ họa Intel Xe trên phần cứng Battlemage G21. Tuy nhiên, để tìm ra dòng mã đó, Linus Torvalds phải trải qua một phiên gỡ lỗi mà ông mô tả là “địa ngục”: 24 phiên bản bản vá thử nghiệm và 18 lần khởi động kernel Linux. Một trợ lý AI đã hỗ trợ đáng kể phần việc lặp đi lặp lại, dù nhiều lần nó khẳng định vấn đề này là bất khả thi và không thể giải quyết.

Một dòng mã đã sửa điều gì?

Lỗi nằm trong cách driver Intel Xe tính ranh giới giữa vùng VRAM thông thường và phần bộ nhớ phẳng dành riêng cho CCS (Compute Command Streamer). Về mặt khái niệm, thao tác căn chỉnh đã được đổi từ:

round_up(value, SZ_128K)

sang:

round_down(value, SZ_128K)

Giải thích đơn giản, giá trị này đánh dấu điểm kết thúc của vùng bộ nhớ mà trình cấp phát VRAM được phép sử dụng. Khi làm tròn giới hạn lên, một khoảng nhỏ nằm giữa ranh giới thực tế và ranh giới sau khi làm tròn có thể bị xem nhầm là bộ nhớ trống. Nhưng khoảng đó thực chất thuộc về siêu dữ liệu nén CCS, không phải VRAM dành cho các cấp phát thông thường. Làm tròn xuống giúp trình cấp phát luôn dừng ở phía an toàn của ranh giới.

Vì sao phép làm tròn sai khiến GPU hỏng dữ liệu?

Khi trình cấp phát coi vùng lưu trữ CCS là VRAM có thể sử dụng, các vùng cấp phát thông thường có thể chồng lấn lên đó và ghi đè siêu dữ liệu mà GPU cần. Dữ liệu liên quan đến bảng trang GPU vì thế có thể bị hỏng, kéo theo hiện tượng hình ảnh lỗi và trình quản lý hiển thị GDM liên tục khởi động lại trên phần cứng Battlemage G21.

Đây không chỉ là một phép tính số học sai. Vấn đề nằm ở ý nghĩa của giá trị: mã nguồn đã căn chỉnh nó như thể đây là địa chỉ bắt đầu, trong khi thực tế nó là một giới hạn cho biết vùng bộ nhớ khả dụng kết thúc ở đâu. Vì vậy, bản sửa cuối cùng rất nhỏ nhưng lại khó phát hiện.

24 bản vá và 18 lần khởi động để thu hẹp nguyên nhân

Torvalds gọi đây là một “phiên gỡ lỗi từ địa ngục”. Ông cùng trợ lý AI liên tục thêm và điều chỉnh các công cụ ghi nhận có mục tiêu, lần theo cách driver tính toán bộ nhớ, rồi đối chiếu vị trí CCS do phần cứng báo cáo với ranh giới mà trình cấp phát VRAM nhận được. Sau 24 phiên bản bản vá gỡ lỗi và 18 chu kỳ khởi động–kiểm thử, lỗi căn chỉnh mới lộ rõ.

Các lần khởi động lại có ý nghĩa quan trọng vì sự cố biểu hiện ở cấp phần cứng và hệ thống hiển thị, chứ không đơn thuần là một dòng mã trông đáng ngờ. Mỗi thử nghiệm giúp loại trừ những nguyên nhân khác và phân biệt lỗi trong hành vi cấp phát bộ nhớ với các vấn đề khác của đồ họa.

AI giúp tăng tốc, nhưng không phải người dẫn đường

Torvalds sử dụng AI như một đối tác tương tác trong quá trình gỡ lỗi. Công cụ này hỗ trợ đề xuất cách chèn thông tin chẩn đoán, lần theo các đường đi trong mã nguồn và phân tích kết quả của từng thử nghiệm. Nhờ đó, phần công việc lặp lại trong việc kiểm tra các giả thuyết được rút ngắn.

Nhưng AI không phải một nguồn thẩm quyền đáng tin cậy tuyệt đối. Theo Torvalds, trợ lý này nhiều lần kết luận rằng vấn đề là không thể giải quyết và đề nghị chuyển sang viết báo cáo. Ông mới là người chọn thử nghiệm tiếp theo, nhận ra cách diễn giải nào sai và hiểu ý nghĩa của độ lệch trong mô hình bộ nhớ của trình cấp phát.

Đây là điểm đáng chú ý nhất của câu chuyện: AI tạo ra các khả năng và xử lý phần cơ học; chuyên gia cung cấp bối cảnh, sự kiên trì, các phép thử có thể bác bỏ giả thuyết và phán đoán cuối cùng.

Bản sửa đã được đưa vào đâu?

Torvalds tự viết và commit bản sửa driver Intel Xe vào nhân Linux upstream. Các thông tin hiện có cho biết những nhánh kernel stable còn được duy trì và chịu ảnh hưởng dự kiến sẽ nhận thay đổi này qua quy trình backport thông thường. Tuy vậy, các nguồn được cung cấp chưa xác nhận chắc chắn những phiên bản stable cụ thể hoặc ngày phát hành tương ứng.

Vì thế, chưa nên khẳng định bản sửa đã có mặt trong một phiên bản cụ thể chỉ dựa trên dữ liệu hiện tại. Người dùng phần cứng bị ảnh hưởng nên theo dõi thông báo từ nhà phát hành Linux hoặc đội ngũ bảo trì kernel để xác nhận bản cập nhật chứa bản sửa.

Bài học rộng hơn về AI trong phát triển kernel

Sự việc không phải là lời chứng thực chung cho mã kernel do AI tạo ra. Đây là ví dụ hẹp hơn và có cơ sở hơn: một chuyên gia có thể dùng AI để tăng tốc vòng lặp gỡ lỗi khó, đồng thời vẫn tự chịu trách nhiệm về giả thuyết, thiết kế thử nghiệm, việc xem xét và bản vá cuối cùng.

Điều đó rất khác với việc gửi hàng loạt bản vá hoặc báo cáo lỗ hổng do AI tạo ra mà không được kiểm thử và không có người hiểu rõ để giải thích. Các nhà phát triển kernel từng mô tả làn sóng bản gửi do máy tạo ra như một “cuộc tấn công dồn dập”, trong khi các đội ngũ bảo trì subsystem staging và networking cũng cho biết họ ngày càng phải xử lý nhiều bản vá giá trị thấp hoặc thiếu bối cảnh.

Con số thường được nhắc đến về mức tăng 2.700% cần được xem xét thận trọng. Những nguồn được cung cấp không làm rõ phương pháp đo, khoảng thời gian hay chính xác con số này nói về toàn bộ bản gửi, một subsystem hay một nhóm bản vá nào. Kết luận được hỗ trợ tốt hơn là: AI đã làm giảm chi phí tạo mã và báo cáo, nhưng chi phí xem xét và phân loại chúng vẫn do các maintainer con người gánh chịu.

Torvalds cũng từng cho rằng Linux không phản đối AI một cách tuyệt đối, đặc biệt khi AI được dùng cho những việc như xem xét mã nguồn. Phiên gỡ lỗi Intel Xe cho thấy ranh giới thực tế: AI hữu ích khi nằm trong một quy trình kỹ thuật có kỷ luật, nhưng không thể thay thế kiến thức về subsystem, kiểm thử có thể tái lập và trách nhiệm của con người đối với kết quả.

Bản vá cuối cùng chỉ có một dòng. Thành tựu thực sự là biết phải sửa dòng nào — và không dừng lại khi trợ lý AI nói rằng không thể tìm ra câu trả lời.