Báo cáo Slimbook Titan 7 - Không, tôi không vui (lại)
Cập nhật:ngày 5 tháng 11 năm 2025
Chúng ta phải nói về chiếc máy tính xách tay chỉ dành cho Linux của tôi, một chiếc Slimbook Titan. Tôi đã có chiếc máy này được khoảng hai năm và đã thay đổi. Tôi mua nó với sứ mệnh rõ ràng là vĩnh viễn rời bỏ Windows. Máy và hệ điều hành của nó, Kubuntu với phiên bản 22.04 LTS + pro (hiện tại), cần có khả năng thực hiện tất cả các loại điều kỳ diệu, bao gồm chơi game, phần mềm Windows, v.v. Cho đến nay, nó vẫn hoạt động tốt nhưng gặp khó khăn do các lỗi phần mềm hoàn toàn không cần thiết và được xuất hiện ngẫu nhiên.
Quả thực, kể từ khi có máy tính xách tay, vấn đề lớn của tôi là trải nghiệm thiếu nhất quán. Nếu nó hoàn toàn xấu, tôi có thể bỏ nó. Nếu nó hoàn toàn tốt, tôi có thể tận hưởng nó và quên nó đi. Nhưng không. Theo kiểu Linux điển hình thường coi thường QA và triết lý sử dụng máy tính để bàn đầy đủ, các vấn đề xảy ra và biến mất sau mỗi bản cập nhật, mọi thứ hỏng hóc và không ai thực sự quan tâm. Nhưng đối với tôi, để có thể nắm bắt được hệ thống này và dựa vào nó cho những hoạt động quan trọng, tôi cần sự tin cậy đó, tôi cần sự nhất quán đó. Sự ổn định và khả năng dự đoán là điều bắt buộc. Và như tôi đã ghi lại trong sáu báo cáo dài hạn vừa qua, Titan đã không đạt được những mục tiêu tưởng chừng như đơn giản này. Được rồi, hãy xem nỗ lực thứ bảy sẽ tiết lộ điều gì trước mắt chúng ta. Theo sau tôi.
Vấn đề mới
Tôi đã gặp phải hai vấn đề mới. Đầu tiên, một trong những quạt của máy tính xách tay quyết định bắt đầu gây ra tiếng ồn nghiêm trọng. Tôi đã nhận xét về điều này từ rất sớm trong lịch sử của chiếc máy này, qua một số bài đánh giá của tôi, nhưng bây giờ, vấn đề đã trở nên đáng chú ý hơn. Cụ thể, khi bạn bật máy lên, trong khoảng một giờ, cho đến khi từng miếng nhựa và kim loại nóng lên và đạt đến nhiệt độ hoạt động ổn định ở mức khá, quạt sẽ kêu lạch cạch và kêu còi thất thường.
Không có khuôn mẫu nào có thể dự đoán được cho âm thanh, ngoại trừ nó biểu hiện bằng những tiếng kêu giống như bập bênh hoang dã này. Khá khó chịu, bởi vì tiếng lạch cạch đều đặn sẽ dễ dàng lọc ra khỏi đầu người ta hơn. Theo cách hoạt động của chiếc quạt, bạn có vài giây yên tĩnh trước khi có tiếng ồn đột ngột bùng lên, sau đó có thể kéo dài một, ba hoặc có thể là bảy giây, sau đó là một khoảng thời gian yên bình khác. Và lặp lại.
Như tôi đã nói, vấn đề sẽ biến mất khi sử dụng. Tuy nhiên, mỗi khi laptop “lạnh” thì điều đó lại xảy ra. Và theo kinh nghiệm của tôi, theo thời gian, nó sẽ không khá hơn. Người hâm mộ hiếm khi quyết định trở nên im lặng khi sử dụng. Hoàn toàn ngược lại. Sự hao mòn khi sử dụng làm cho các bộ phận kêu to hơn theo thời gian. Vì vậy đây là điều cần cân nhắc.
Vấn đề thứ hai là bàn phím không phải lúc nào cũng phản hồi tốt khi nhấn. Tốt nhất đó là một bàn phím tầm thường, như tôi đã đề cập trước đây, nhưng bây giờ, tôi thực sự cần phải nhấn mạnh và gõ các phím để các nét bút có thể đăng ký. Tôi nhận thấy có khá nhiều chữ cái bị thiếu khi tôi gõ ngẫu nhiên (và nhanh). Tôi cần phải thận trọng hơn. Điều này không giống như một vấn đề phần mềm. Đây dường như là một vấn đề hoàn toàn về mặt cơ học và thật đáng thất vọng khi xuất hiện sớm như vậy trong vòng đời của máy. Tôi thậm chí còn chưa gõ được 100K từ trên bàn phím này.
Vấn đề cũ
Nếu bạn đã đọc các báo cáo Titan cũ của tôi, bạn sẽ biết rằng máy đã có thời gian sử dụng ổn định phần sụn-nhân khó khăn. Ban đầu, đã có vấn đề với việc đình chỉ. Những vấn đề đó cuối cùng đã được giải quyết. Sau đó, máy "trải nghiệm" bản cập nhật giới thiệu firmware và kernel mới, khiến hệ thống bị treo cực kỳ khó chịu. Một đợt vá lỗi mới dường như đã khắc phục được những vấn đề đó. Ngoại trừ.
Lần này, tôi nhận được một lượt mã bị kiểm tra kém khác và một lần nữa, hệ thống lại trải qua những lần đóng băng đó, theo đó toàn bộ hệ thống không phản hồi trong 5-6 giây. Sự cố xuất hiện trong suốt phiên và kèm theo một loạt thông báo trong nhật ký hệ thống. Tôi thậm chí đã viết về điều này, nhưng bây giờ lại càng ồn ào hơn:
acpi_os_execute_deferred chiếm CPU>10000us 8 lần, hãy cân nhắc chuyển sang WQ_UNBOUND
acpi_ec_event_processor ngốn CPU>10000us 4 lần, hãy cân nhắc chuyển sang WQ_UNBOUND
pm_runtime_work ngốn CPU>10000us 4 lần, hãy cân nhắc chuyển sang WQ_UNBOUND
Lỗi pm_runtime là lỗi cũ nhưng lỗi acpi_ thì mới. Điều này khiến tôi phải tìm kiếm trên Internet để xem các diễn đàn và hệ thống vé bugzilla khác nhau nói gì. Và anh bạn, họ có cần phải nói nhiều không.
- Web tràn ngập các báo cáo kiểu này.
- Nó dường như ảnh hưởng đến hầu hết mọi nền tảng phân phối và phần cứng.
- Vấn đề được "đổ lỗi" cho phần sụn bị lỗi, nhưng có phải mọi phần sụn thực sự đều có lỗi không? Hay đây có lẽ là vấn đề về kernel?
- Thật vậy, vì sự cố xảy đến rồi đi với các bản cập nhật kernel nên tôi cho rằng đó là một biểu hiện khác của sự cố tương thích phần cứng máy tính để bàn Linux. Hạt nhân không thực sự được thiết kế để sử dụng tại nhà và Linux ở nhà là một tình huống ngẫu nhiên chứ không phải là thiết kế có chủ ý. Linux là một thứ dành cho doanh nghiệp và các giải pháp từ không gian đó được đưa lên hệ thống gia đình mà hầu như không quan tâm đến khả năng sử dụng thực tế. Thêm QA gần như bằng 0 vào phương trình và chúng ta đang ở đây.
- Tôi cực kỳ ghét việc Linux phân phối chương trình cơ sở "đẩy" cùng với các bản cập nhật hệ thống. Chúng nên được xử lý riêng biệt, vì theo kinh nghiệm của tôi, nếu bạn không gặp vấn đề gì về phần cứng thì không cần phải tiếp tục nâng cấp chương trình cơ sở của mình (một cách mù quáng), vì điều này thường dẫn đến sự cố. Toàn bộ sự việc thật mong manh, vừa buồn cười vừa lố bịch.
- Được cho là, sự cứu rỗi có trong kernel 6.10. Điều buồn cười là hệ thống của tôi có bộ xử lý AMD! Hiện tại, báo cáo của Phoronix là từ giữa năm 2024, tức là cách đây hơn một năm. Tôi đã gặp phải sự cố mới vào tháng 10 năm 2025. Cho dù bản vá này là gì thì nó cũng chưa được nhập vào nhân Ubuntu mà hệ thống của tôi sử dụng hoặc đã bị hỏng do các bản cập nhật mới (có vẻ như đúng như vậy). Dù sao đi nữa, Ubuntu 22.04 chỉ chạy 6.8, vì vậy 6.10 không có backport không phải là một lựa chọn ở đây.
Một cách giải quyết mới
Chà, điều "tốt" về tất cả các báo cáo ở trên là bạn có thể giải quyết vấn đề. Bạn cần xác định các ngắt hoạt động sai, sau đó vô hiệu hóa (chặn) hoặc che dấu chúng, với những hậu quả có thể chưa biết, vì việc ánh xạ các lệnh gọi ACPI (cụ thể theo máy) tới phần cứng của bạn không phải là việc tầm thường. Quả thực, đối với máy của tôi:
grep . /sys/firmware/acpi/interrupts/*
...
/sys/firmware/acpi/interrupts/gpe00: 0 không hợp lệ bị lộ
/sys/firmware/acpi/interrupts/gpe01: 0 STS không hợp lệ bị lộ
/sys/firmware/acpi/interrupts/gpe02: 0 không hợp lệ bị lộ
/sys/firmware/acpi/interrupts/gpe03: 6071 EN đã bật bị lộ
/sys/firmware/acpi/interrupts/gpe04: 0 không hợp lệ bị lộ
/sys/firmware/acpi/interrupts/gpe05: 0 không hợp lệ bị lộ
...
Ngắt vi phạm là gpe03, bạn có thể chặn hoặc che dấu gián đoạn này. Một cách nhanh chóng để xem liệu nó có tạo ra sự khác biệt nào hay không là tạm thời vô hiệu hóa nó theo cách thủ công thông qua dòng lệnh với quyền root. Thay đổi sẽ không tồn tại sau khi khởi động lại, vì vậy nếu có vấn đề gì xảy ra, bạn chỉ cần khởi động lại máy của mình.
echo "vô hiệu hóa"> /sys/firmware/acpi/interrupts/gpe03
Thay vì chặn, bạn cũng có thể thử che:
echo "mask"> /sys/firmware/acpi/interrupts/gpe03
Nếu hài lòng, bạn có thể thực hiện thay đổi lâu dài hơn, thông qua GRUB, bằng cách thêm các tham số khởi động mới vào dòng lệnh kernel. Vui lòng tham khảo hướng dẫn về bộ nạp khởi động ở trên để biết chi tiết về cách đạt được điều này và nếu bạn không thấy thoải mái với quy trình này thì đừng làm. Bạn có thể sử dụng tham số acpi_block_gpe hoặc acpi_mask_gpe.
acpi_mask_gpe=0x03
Bạn cũng có thể tạo một dịch vụ systemd thực hiện công việc. Đầu tiên, tạo một tệp đơn vị dịch vụ và gọi nó là startup.service. Tên nào cũng được.
[Đơn vị]
Description=Script tắt gpe
[Dịch vụ]
ExecStart=/root/startup.sh
[Cài đặt]
WantedBy=multi-user.target
Lưu tệp này vào /etc/systemd/system. Sau đó, tạo một tập lệnh có tiêu đề startup.sh, tập lệnh này cần được đặt ở đâu đó trên hệ thống của bạn. Tôi đã chọn thư mục gốc. Nội dung của tập lệnh này là:
#!/bin/bash
echo "vô hiệu hóa"> /sys/firmware/acpi/interrupts/gpe03
lối ra 0
Bạn cũng có thể sử dụng mặt nạ thay vì tắt. Đảm bảo bạn chỉ định đúng gpe. Đảm bảo tập lệnh có thể thực thi được, nếu không tập lệnh sẽ không chạy. Bạn có thể thực hiện việc này bằng lệnh chmod +x đối với tệp tập lệnh. Nếu bạn không thấy thoải mái khi làm việc này thì có lẽ bạn không nên mày mò ngay từ đầu.
Cuối cùng, kích hoạt dịch vụ systemd:
sudo systemctl kích hoạt [tên dịch vụ bạn đã chọn trước đó]
Khởi động lại và kiểm tra các ngắt để xem liệu nó hiển thị dưới dạng bị che hay bị vô hiệu hóa. Nếu bạn không muốn sử dụng dịch vụ nữa thì hãy tắt nó đi. Bạn cũng có thể xóa tệp đơn vị dịch vụ hoặc xóa tập lệnh, nhưng cách đó không tinh tế và có thể dẫn đến lỗi giả trong nhật ký hệ thống của bạn.
Tôi đã che giấu gpe và nó giúp ích. Sự đóng băng biến mất. Nhưng tôi thực sự không biết chức năng hệ thống nào hiện đang bị suy giảm, nếu có. Kết quả có thể nhìn thấy được từ sự thay đổi này là khi tôi cắm bộ sạc pin vào, sẽ không còn âm thanh thông báo nữa.
Chơi game
Không có tin tức mới, có thể nói như vậy. Tôi vẫn không thể chơi Assetto Corsa qua Proton. Tôi chưa cài đặt bất kỳ phiên bản tùy chỉnh nào của công cụ tương thích hoặc thử bất kỳ cách hack thủ công nào. Tôi quyết định chỉ sử dụng bất cứ thứ gì Steam cung cấp và buộc trò chơi chạy với các phiên bản Proton khác nhau. Chưa gặp may mắn nhưng điều đó không có nghĩa là tôi sẽ ngừng cố gắng.
Và tôi nghĩ chúng ta sẽ dừng ở đây.
Kết luận
Sự sáng chói bi thảm của máy tính để bàn Linux. Một mặt, Titan làm được điều đó một cách đáng ngưỡng mộ. Thiết lập đồ họa lai khá tốt, mã hóa khởi động, chơi game qua Steam Proton, hàng tá chương trình Windows chạy tuyệt vời với WINE, tất cả các đặc quyền của môi trường Plasma. Với một máy ảo dành cho văn phòng, tôi thực sự sẵn sàng đối mặt với tương lai không có Windows, có thể nói như vậy. Nhưng sau đó, tất cả tan vỡ với bản vá kernel và firmware hầu như không được kiểm tra, phá hỏng niềm hạnh phúc, phá hủy tất cả những thành tựu tốt đẹp, ngọt ngào.
Ai đó có thể nói, không có gì to tát, bạn mày mò một chút là xong. Thật thú vị khi bạn làm điều đó một cách tự nguyện, trên một hệ thống dự phòng, hoặc khi bạn 20 tuổi và không cần quan tâm đến thế giới. Đối với tôi, với những mục tiêu và thời hạn trong đời thực, tôi không thể có được những khoảnh khắc “mi scusi” trong hệ điều hành. Điều tồi tệ hơn là sự ổn định chung của hệ sinh thái đã trở nên Tệ hơn kể từ khi tôi mua chiếc máy tính xách tay. Bạn sẽ mong đợi sự ổn định hơn, chất lượng cao hơn theo thời gian, ngay cả khi các bản phát hành đầu tiên không tốt. Nhưng không. Điều này có nghĩa là việc ngoại suy về tương lai là một viễn cảnh nghiệt ngã. Giải pháp thay thế là sử dụng Windows ở chế độ "đánh bại" hoặc mua máy Mac và tận hưởng PTSD tài chính mà việc mua hàng đó sẽ mang lại, với lợi ích bổ sung thực sự là tích hợp chặt chẽ phần cứng-phần mềm.
Tôi sẽ tiếp tục sử dụng Linux như tôi đã làm một cách nghiêm túc trong nhiều năm qua. Câu hỏi duy nhất là liệu Linux có mang lại cho tôi sự yên bình và ổn định mà tôi cần hay không. Để làm được điều đó, chúng ta sẽ phải đợi đến báo cáo thứ tám, thứ chín và thứ n về Titan. Ngoài ra, vâng, Titan vẫn chạy phiên bản 22.04 hỗ trợ chuyên nghiệp và tôi do dự khi chuyển sang phiên bản 24.04 do quá trình nâng cấp Executive có nhiều lỗi. Tôi hoàn toàn không mong đợi mọi thứ sẽ xảy ra ngẫu nhiên hơn nữa mà không có bất kỳ lời hứa hẹn nào về lợi ích thực sự. Một lần nữa, đó là một câu chuyện cho một báo cáo khác. Hiện tại tôi cảm thấy khá chán nản. Đó là cuộc sống. Bảo trọng.
Chúc mừng.