Slimbook Titan 보고서 7 - 아니요, 만족스럽지 않습니다(다시 한번)
업데이트 날짜:2025년 11월 5일
내 Linux 전용 노트북인 Slimbook Titan에 대해 이야기해야 합니다. 저는 이 기계를 약 2년 동안 사용하다가 바꿨습니다. 나는 Windows에서 영원히 마이그레이션하겠다는 명시적인 사명으로 그것을 구입했습니다. 기계와 운영 체제인 Kubuntu(22.04 LTS + pro 에디션(현재))는 게임, Windows 소프트웨어 등을 포함한 모든 종류의 놀라운 기능을 수행할 수 있어야 합니다. 지금까지는 잘 작동하고 있지만 완전히 불필요하고 무작위로 유입되는 소프트웨어 버그로 인해 어려움을 겪고 있습니다.
실제로 노트북을 구입한 이후로 가장 큰 문제는 경험의 일관성이 부족하다는 것이었습니다. 완전히 나빴다면 버릴 수도 있었어요. 완전히 좋았다면 즐기고 잊을 수 있었을 텐데. 하지만 아닙니다. QA와 완전한 데스크톱 사용 철학을 무시하는 전형적인 Linux 방식에서는 업데이트할 때마다 문제가 발생하고 문제가 발생하며 문제가 발생하며 아무도 관심을 두지 않습니다. 하지만 제가 이 시스템을 수용하고 중요한 활동에 의존하려면 신뢰성과 일관성이 필요합니다. 안정성과 예측 가능성은 필수입니다. 그리고 제가 지난 6개의 장기 보고서를 통해 문서화한 것처럼 타이탄은 겉보기에 단순해 보이는 목표를 달성하지 못했습니다. 좋아요, 일곱 번째 노력이 우리 앞에 무엇을 드러낼지 봅시다. 나 이후에.
새로운 문제
두 가지 새로운 문제가 발생했습니다. 첫째, 노트북 팬 중 하나가 심각한 소음을 내기로 결정했습니다. 나는 이 기계의 역사 초기에 여러 리뷰를 통해 이에 대해 언급했지만 지금은 문제가 더욱 눈에 띄게 되었습니다. 즉, 기계를 켜면 모든 플라스틱과 금속 조각이 예열되어 안정된 작업 온도에 도달할 때까지 약 한 시간 동안 팬이 불규칙하게 요란하게 울리고 휘파람을 불게 됩니다.
이 거친 시소 같은 지저귀는 소리를 제외하고는 소리에 예측 가능한 패턴이 없습니다. 꽤 짜증나는 소리인데, 계속해서 덜거덕거리는 소리가 사람의 머리에서 걸러지기 더 쉬울 것이기 때문입니다. 팬이 작동하는 방식에 따라 갑작스러운 소음이 발생하기 전에 몇 초간 조용해지며, 그 소음은 1초, 3, 7초 동안 지속된 후 또 다시 평화가 찾아올 수 있습니다. 그리고 반복하세요.
내가 말했듯이 문제는 사용하면 사라집니다. 그러나 노트북이 "차가워"질 때마다 이런 일이 발생합니다. 그리고 내 경험에 따르면 시간이 지나도 좋아지지 않을 것입니다. 팬들은 사용하면서 조용해지기로 결정하는 경우가 거의 없습니다. 정반대입니다. 사용 마모로 인해 시간이 지남에 따라 구성 요소의 소리가 커집니다. 따라서 고려해야 할 사항입니다.
두 번째 문제는 키보드가 누를 때 항상 잘 반응하지 않는다는 것입니다. 앞서 언급했듯이 기껏해야 평범한 키보드이지만 이제는 스트로크를 등록하려면 정말 힘차게 키를 두드려야 합니다. 가볍게(그리고 빠르게) 타이핑할 때 꽤 많은 문자가 누락되는 것을 발견했습니다. 좀 더 신중해야 해요. 이것은 소프트웨어 문제처럼 느껴지지 않습니다. 이는 전적으로 기계적 문제인 것으로 보이며, 기계 수명 초기에 이렇게 나타나는 것은 상당히 실망스럽습니다. 저는 아직 이 키보드로 10만 단어도 입력하지 않았습니다.
오래된 문제
내 이전 Titan 보고서를 읽어보셨다면 해당 머신이 힘든 펌웨어 커널 안정성 수명을 갖고 있다는 것을 아실 것입니다. 초기에는 일시 중단에 문제가 있었습니다. 그 문제는 결국 해결되었습니다. 그런 다음 컴퓨터는 새로운 펌웨어와 커널을 도입하는 업데이트를 "경험"하여 매우 짜증나는 시스템 정지를 초래했습니다. 새로운 패치로 이러한 문제가 해결된 것 같습니다. 제외.
이번에는 또 다른 잘못 테스트된 코드를 얻었고 다시 한 번 시스템이 정지되어 전체가 5~6초 동안 응답하지 않게 되었습니다. 문제는 세션 전반에 걸쳐 나타나며 시스템 로그에 엄청난 양의 메시지가 표시됩니다. 이에 대해 글을 쓰기도 했지만 지금은 더 많은 소음이 발생하고 있습니다.
acpi_os_execute_deferred CPU가 10000us보다 8회 초과되면 WQ_UNBOUND로 전환하는 것이 좋습니다.
acpi_ec_event_processor가 CPU를 10000us보다 4번 초과했습니다. WQ_UNBOUND로 전환하는 것이 좋습니다.
pm_runtime_work CPU가 10000us 이상 4회 초과되면 WQ_UNBOUND로 전환하는 것이 좋습니다.
pm_runtime 오류는 오래된 것이지만 acpi_ 오류는 새로운 것입니다. 이로 인해 다양한 포럼과 Bugzilla 티켓 시스템이 무엇을 말하는지 알아보기 위해 인터넷 검색을 하게 되었습니다. 아, 꼭 말을 많이 해야 하나요?
- 웹에는 이러한 성격의 보고서가 넘쳐납니다.
- 거의 모든 배포판과 하드웨어 플랫폼에 영향을 미치는 것으로 보입니다.
- 이 문제는 버그가 있는 펌웨어에 "비난"되어 있지만 모든 펌웨어가 실제로 버그가 있을 수 있습니까? 아니면 커널 문제일까요?
- 실제로 커널 업데이트와 함께 문제가 계속 발생하므로 이는 Linux 데스크톱 하드웨어 호환성 문제의 또 다른 징후라고 말하고 싶습니다. 커널은 실제로 가정용으로 설계되지 않았으며 가정용 Linux는 고의적인 설계라기보다는 우연한 상황입니다. Linux는 기업용이며 해당 분야의 솔루션은 실제 유용성과 거의 상관없이 홈 시스템에 적용됩니다. 방정식에 거의 0에 가까운 QA를 추가하면 여기 있습니다.
- 저는 Linux 배포판이 시스템 업데이트와 함께 펌웨어를 "푸시"하는 것을 정말 싫어합니다. 내 경험상 하드웨어 문제가 없으면 종종 문제가 발생하기 때문에 (맹목적으로) 펌웨어를 계속 업그레이드할 필요가 없기 때문에 별도로 처리해야 합니다. 모든 것이 너무 부서지기 쉬우며 동시에 슬프고 우스꽝스럽습니다.
- 아마도 구원은 커널 6.10에서 나옵니다. 재미있는 점은 내 시스템에 AMD 프로세서가 있다는 것입니다! 이제 Phoronix 보고서는 2024년 중반부터, 즉 1년 이상 전이라는 의미입니다. 저는 2025년 10월에 새로운 문제를 경험했습니다. 이 패치가 무엇이었든 간에 제 시스템이 사용하는 Ubuntu 커널로 백포트되지 않았거나 이후 새로운 업데이트로 인해 손상되었습니다(그런 것 같습니다). 어느 쪽이든 Ubuntu 22.04는 6.8만 실행하므로 백포트가 없는 6.10은 여기서 옵션이 아닙니다.
새로운 해결 방법
위의 모든 보고서의 "좋은" 점은 문제를 해결할 수 있다는 것입니다. 잘못 동작하는 인터럽트를 식별한 다음 이를 비활성화(차단)하거나 마스크해야 합니다. 잠재적으로 알 수 없는 결과를 염두에 두어야 합니다. 하드웨어에 대한 ACPI 호출(머신별) 매핑은 쉽지 않기 때문입니다. 실제로 내 컴퓨터에서는:
grep . /sys/firmware/acpi/interrupts/*
...
/sys/firmware/acpi/interrupts/gpe00: 0 유효하지 않음 마스크 해제됨
/sys/firmware/acpi/interrupts/gpe01: 0 STS가 유효하지 않음 마스크 해제됨
/sys/firmware/acpi/interrupts/gpe02: 0 유효하지 않음 마스크 해제됨
/sys/firmware/acpi/interrupts/gpe03: 6071 EN 활성화됨 마스크 해제됨
/sys/firmware/acpi/interrupts/gpe04: 0 유효하지 않음 마스크 해제됨
/sys/firmware/acpi/interrupts/gpe05: 0 유효하지 않음 마스크 해제됨
...
문제가 되는 인터럽트는 gpe03이며 차단하거나 마스크할 수 있습니다. 차이가 있는지 확인하는 빠른 방법은 명령줄을 통해 루트로 수동으로 일시적으로 비활성화하는 것입니다. 변경 사항은 재부팅 후에도 유지되지 않으므로 문제가 발생하면 간단히 컴퓨터를 다시 시작하면 됩니다.
echo "비활성화"> /sys/firmware/acpi/interrupts/gpe03
차단 대신 마스킹을 시도해 볼 수도 있습니다:
echo "마스크"> /sys/firmware/acpi/interrupts/gpe03
만족스러우면 GRUB를 통해 커널 명령줄에 새 부팅 매개변수를 추가하여 변경 사항을 보다 영구적으로 만들 수 있습니다. 이를 달성하는 방법에 대한 자세한 내용은 위의 부트로더 튜토리얼을 참조하고, 절차가 불편하다면 수행하지 마세요. acpi_block_gpe 또는 acpi_mask_gpe 매개변수를 사용할 수 있습니다.
acpi_mask_gpe=0x03
작업을 수행하는 시스템 서비스를 만들 수도 있습니다. 먼저 서비스 유닛 파일을 생성하고, start.service와 같은 이름을 지정하세요. 어떤 이름이라도 괜찮습니다.
[단위]
Description=gpe를 비활성화하는 스크립트
[서비스]
ExecStart=/root/startup.sh
[설치]
WantedBy=multi-user.target
이 파일을 /etc/systemd/system.conf에 저장합니다. 그런 다음 시스템 어딘가에 배치해야 하는 startup.sh라는 스크립트를 만듭니다. 저는 루트 홈 폴더를 선택했습니다. 이 스크립트의 내용은 다음과 같습니다:
#!/bin/bash
에코 "비활성화"> /sys/firmware/acpi/interrupts/gpe03
0번 출구
비활성화 대신 마스크를 사용할 수도 있습니다. 올바른 gpe를 지정했는지 확인하세요. 스크립트가 실행 가능한지 확인하세요. 그렇지 않으면 실행되지 않습니다. 스크립트 파일에 대해 chmod +x 명령을 사용하여 이 작업을 수행할 수 있습니다. 이 작업이 불편하다면 처음부터 손을 대서는 안 됩니다.
마지막으로 systemd 서비스를 활성화하십시오:
sudo systemctl 활성화 [이전에 선택한 서비스 이름]
다시 시작하고 인터럽트를 확인하여 마스크되거나 비활성화된 것으로 표시되는지 확인하세요. 더 이상 서비스를 사용하지 않으려면 비활성화하세요. 서비스 단위 파일을 삭제하거나 스크립트를 제거할 수도 있지만 이는 우아하지 않으며 시스템 로그에 허위 오류가 발생할 수 있습니다.
나는 gpe를 마스킹했는데 도움이되었습니다. 동결이 사라집니다. 그러나 현재 어떤 시스템 기능이 손상되었는지는 알 수 없습니다. 변경으로 인해 눈에 띄는 한 가지 결과는 배터리 충전기를 연결할 때 더 이상 알림 소리가 들리지 않는다는 것입니다.
게임
말하자면 새로운 소식은 없습니다. 아직도 Proton을 통해 Assetto Corsa를 플레이할 수 없습니다. 호환성 도구의 사용자 정의 버전을 설치하지 않았거나 수동 해킹을 시도하지 않았습니다. 나는 Steam이 제공하는 모든 것을 사용하고 게임이 다른 버전의 Proton에서 실행되도록 하기로 결정했습니다. 지금까지는 운이 좋지 않았지만 그렇다고 해서 노력을 중단한다는 의미는 아닙니다.
그리고 여기서 멈추면 될 것 같습니다.
결론
Linux 데스크탑의 비극적인 광채. 한편으로 타이탄은 훌륭하게 해냈습니다. 꽤 괜찮은 하이브리드 그래픽 설정, 부팅 암호화, Steam Proton을 통한 게임, WINE과 함께 훌륭하게 실행되는 12개의 Windows 프로그램, 플라즈마 환경의 모든 특전이 있습니다. 사무용 가상 머신을 사용하면 Windows가 아닌 미래를 맞이할 준비가 되었습니다. 그러나 간신히 테스트된 펌웨어와 커널 패치로 인해 모든 것이 산산조각이 나고 행복을 망치고 모든 훌륭하고 달콤한 업적을 무산시킵니다.
누군가는 별거 아니다, 조금만 손보면 일이 끝났다고 말할 수 있다. 자발적으로, 여분의 시스템에서, 또는 20살이고 세상 걱정 없이 할 때 그것은 재미있습니다. 나에게는 실제 목표와 기한이 있기 때문에 운영 체제에서 "미스쿠시(mi scusi)" 순간을 감당할 수 없습니다. 더 나쁜 것은 노트북을 구입한 이후로 생태계의 전반적인 안정성이 더 나빠졌다는 것입니다. 초기 릴리스가 좋지 않더라도 시간이 지남에 따라 더 많은 안정성과 더 높은 품질을 기대할 수 있습니다. 하지만 아닙니다. 이는 미래를 추정하는 것이 암울한 전망임을 의미합니다. 대안은 Windows를 "패배" 모드로 사용하거나, Mac을 구입하여 긴밀한 하드웨어-소프트웨어 통합의 추가 이점을 누리면서 그러한 구입으로 인해 발생하는 재정적 PTSD를 즐기는 것입니다.
나는 수년 동안 진지하게 사용해왔듯이 계속해서 Linux를 사용할 것입니다. 유일한 질문은 Linux가 나에게 필요한 평화와 안정성을 제공할 것인가입니다. 그러기 위해서는 타이탄에 관한 여덟 번째, 아홉 번째, n번째 보고를 기다려야 할 것입니다. 참고로, 타이탄은 여전히 전문가용 22.04를 실행하고 있으며 Executive 업그레이드 프로세스의 버그가 너무 많아서 24.04로 이동하는 것을 주저하고 있습니다. 나는 진정한 이익에 대한 약속 없이 무작위로 깨지는 일을 더 이상 기대하지 않습니다. 다시 말하지만, 그것은 또 다른 보고서에 대한 이야기입니다. 지금으로서는 다소 낙담한 느낌이 듭니다. C'est la vie. 잘 지내세요.
건배.