ACPI Lỗi / Exeptions, tại sao họ spam, làm thế nào để biết và sửa nó?

Tôi đã có những lỗi này làm ô nhiễm dmesg của tôi:

[21720.400079] ACPI Error: [\_TZ_.THRM] Namespace lookup failure, AE_NOT_FOUND (20130328/psargs-359)
[21720.400093] ACPI Error: Method parse/execution failed [\_GPE._L1C] (Node f584ec80), AE_NOT_FOUND (20130328/psparse-537)
[21720.400112] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L1C] (20130328/evgpe-580)
[21960.800116] ACPI Error: [\_TZ_.THRM] Namespace lookup failure, AE_NOT_FOUND (20130328/psargs-359)
[21960.800130] ACPI Error: Method parse/execution failed [\_GPE._L1C] (Node f584ec80), AE_NOT_FOUND (20130328/psparse-537)
[21960.800149] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L1C] (20130328/evgpe-580)

Điều này xảy ra vô hạn. Tôi đã thử từng từ khóa và không tìm thấy bất cứ điều gì liên quan từ xa. Điều này xảy ra trong mỗi phân phối tôi cố gắng. Làm cách nào để chẩn đoán nguồn gốc của tin nhắn?

Sau khi làm ô nhiễm vòng tin nhắn, tôi không tìm thấy bất kỳ vấn đề nào khác liên quan đến vấn đề này.

linux-kernel logs acpi

— Bà mẹ
nguồn

Tôi có cùng một vấn đề. Trong trường hợp của tôi, tôi đoán đó là do thẻ không dây của tôi. Tôi có một rtl8188eetài xế theo lspci -k, còn bạn thì sao?

— auraham

@auraham không có gì giống như vậy, hệ thống của tôi là một máy tính để bàn. Không có không dây. Một HP Pavilion a1104x nếu bạn tò mò.

— Braiam

Tôi có vấn đề này như nhau. Trong trường hợp của tôi, nó thực sự đã ảnh hưởng tiêu cực đến hệ thống của tôi, bởi vì nó đã làm đầy thư mục / var / log của tôi đến một điểm mà phân vùng gốc của tôi được lấp đầy hoàn toàn.

— Aaron Franke

Bug đã báo cáo cho các nhà phát triển hạt nhân ở đây: bugzilla.kernel.org/show_orms.cgi?id=188331

— Aaron Franke

Những cảnh báo này được kích hoạt do lỗi phần sụn. Hãy thử một phiên bản BIOS mới hơn để hy vọng sửa các lỗi này. Nếu bạn không có quyền truy cập vào BIOS mới hơn, bạn có thể thử ghi đè DSDT / SSDT của mình bằng các bảng bị thay thế / xóa mã bị lỗi.

Nó dường như không có hại, có lẽ đó là một số kiểm tra sức khỏe / van tiết lưu nhiệt được gọi sau mỗi 240 giây (4 phút).

Đối với các chi tiết kỹ thuật, các thông báo này bắt nguồn từ lõi ACPI. Các \_GPE._Lxxphương thức là các ngắt kích hoạt mức nếu tôi nhớ chính xác và được kích hoạt bởi phần cứng (không phải Linux). Rõ ràng các phương thức cụ thể này cố gắng đánh giá một số phương thức hoặc đối tượng \_TZ.THRMkhông thành công vì phạm vi ACPI này không tồn tại.

— Lekensteyn
nguồn

BIOS được cập nhật với phiên bản mới nhất từ OEM ... và "ghi đè" có vẻ nguy hiểm, tôi có nên sử dụng hướng dẫn này không? Ngoài ra, nếu tôi thay đổi DSDT / SSDT thì chỉ cần khắc phục sự cố hoặc có một số phương pháp để làm cho nó thực hiện những gì nó phải làm? Ngoài ra, có vẻ như tôi nên xây dựng lại kernel của mình ...

— Braiam

@Braiam Trang đó nhìn tổng thể tốt, nhưng tôi khuyên bạn không nên ghi đè toàn bộ DSDT / SSDT trừ khi thực sự cần thiết (trong trường hợp của bạn chỉ là một cảnh báo khó chịu). Bên cạnh việc ghi đè toàn bộ DSDT / SSDT, bạn cũng có thể sử dụng custom_methodmô-đun hạt nhân để ghi đè lên một phương thức ACPI duy nhất. Bạn có thể sử dụng điều này để tạo một \_TZ.THRMnút giả (với những đứa trẻ dự kiến) hoặc ghi đè \_GPE._L1Cđể xóa cuộc gọi. Tuy nhiên, không chỉ đơn giản là chỉnh sửa mọi thứ mà không hiểu những gì đang xảy ra. Nó có thể có tác dụng phụ tiêu cực (như vô hiệu hóa năng lượng hoặc tiết lưu nhiệt để lấy một ví dụ bổ sung).

— Lekensteyn