# AArch64 데스크톱 실험의 끝 > Clean Markdown view of GeekNews topic #30985. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30985](https://news.hada.io/topic?id=30985) - GeekNews Markdown: [https://news.hada.io/topic/30985.md](https://news.hada.io/topic/30985.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-01T09:04:04+09:00 - Updated: 2026-07-01T09:04:04+09:00 - Original source: [marcin.juszkiewicz.com.pl](https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment/) - Points: 1 - Comments: 1 ## Topic Body - 약 11개월간 **Ampere Altra 기반 AArch64 데스크톱**을 실사용했지만, 서버용 플랫폼을 데스크톱처럼 쓰면서 커널·GPU·앱 호환성 부담이 계속 누적됨 - 시스템은 **Ampere Altra Q80-30 80코어 3.0GHz**, 128GB RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T, Fedora 42–44 조합이었고, 애초에 데스크톱용 하드웨어가 아니었음 - AMD GPU 사용에는 **erratum 82288 / PCIE_65** 우회 패치가 필요해 Fedora 커널 업데이트 때마다 자체 커널을 주로 매주 다시 빌드해야 했음 - Linux 7.0 전후로 AMD GPU 오류와 영상 프레임 드롭이 생겼고, Nvidia RTX 2060 전환 후에도 AArch64 Flatpak 저장소의 `org.freedesktop.Platform.GL.nvidia` 부재로 FreeCAD와 OrcaSlicer가 크래시됨 - 결국 x86-64 Ryzen 5 3600 시스템으로 돌아갔으며, Ampere Altra는 데스크톱 대신 **RISC-V 패키지 빌드**용으로 남기고 새 AArch64 데스크톱에는 다른 하드웨어 플랫폼이 필요하다고 판단함 --- ### 서버용 Altra를 데스크톱으로 쓴 구성 - 약 11개월 동안 AArch64 데스크톱을 실사용한 뒤 **실험을 종료**함 - 최종 하드웨어 구성은 다음과 같음 - CPU: **Ampere Altra Q80-30**, 80코어 3.0GHz - RAM: 128GB, 8×16GB HMA82GR7CJR8N-XN - GPU: AMD Radeon RX6700XT - NVMe: Lexar LM970 2TB, ADATA SX8200 Pro 1TB - 메인보드: ASRock Rack ALTRAD8UD-1L2T - PSU: MSI MPG A850G 850W - 케이스: Endorfy 700 Air - USB3: PCIe x4 no-name USB 3.2/10Gbps 컨트롤러 - 이 보드는 **서버 메인보드**이고, Altra 시스템 자체도 데스크톱용으로 설계된 제품이 아님 - Ampere Altra 시스템의 QVL에는 AMD Radeon GPU 카드가 포함되지 않으며, 동작시킬 수는 있지만 추가 작업이 필요한 경우가 많음 - 별도 USB 3.2 컨트롤러는 메인보드 기본 지원보다 더 많은 USB 장치와 외장 NVMe용 **10Gbps 포트**를 제공함 - 전체 시스템은 Fedora 42–44에서 동작했지만, 실제 사용에는 기본 Fedora 커널이 아니라 자체 빌드 커널이 필요했음 ### PCIE_65가 만든 커널 유지보수 부담 - Ampere Altra의 PCI Express 컨트롤러에는 **erratum 82288 / PCIE_65** 문제가 있음 - PCIE_65는 PCIe MMIO 쓰기에서 잘못된 주소를 만들 수 있으며, 특히 AMD GPU 같은 특정 장치 유형에 영향을 줌 - Linux 커널 드라이버가 `ioremap_wc`처럼 MMIO 공간을 Normal, non-cacheable 메모리 속성으로 매핑할 때 문제가 생길 수 있음 - write combining 또는 비정렬 접근을 가능하게 하려는 목적일 수 있음 - 이 경우 PCIe 인터페이스의 outbound MMIO write에서 **데이터 손상**이 발생할 수 있음 - 우회책은 `ioremap_wc` 대신 `ioremap`처럼 Device, non-gathering 메모리로 매핑하고, PCIe MMIO 공간의 모든 메모리 연산을 엄격히 정렬하는 방식임 - 정상적인 Linux 시스템으로 쓰려면 Fedora 커널 패키지 업데이트마다 커널을 다시 빌드해야 했고, 보통 **매주** 작업이 필요했음 - 로컬 Fedora 커널 패키지 저장소를 업데이트한 뒤 `7.0.2-200.fc44.pcie65.6` 같은 자체 버전 규칙으로 빌드함 - `pcie65`는 적용한 패치를 나타냄 - 마지막 숫자는 패치 리베이스 카운터였음 - GitHub 저장소에서 패치를 가져와 리베이스하고 필요할 때 수정했으며, 그 결과 공식 Fedora보다 더 최신 커널을 쓰는 경우도 있었음 ### 80코어가 데스크톱 체감 성능을 보장하지는 않음 - 80개의 CPU 코어가 있어도 좋은 **데스크톱 머신**이 되는 것은 아니었음 - 많은 코어 수는 데스크톱에서 필요한 빠른 체감 성능을 보장하지 않았음 ### GPU 교체 뒤에도 남은 앱 호환성 문제 - AMD Radeon RX6700XT는 out-of-tree PCIE_65 패치를 적용한 커널에서 동작했고, 게임 실행과 하드웨어 보조 영상 디코딩도 가능했음 - Linux 7.0 릴리스 전후 어느 시점부터 AMD GPU가 실패하기 시작함 - 게임 실행 시 `amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0` 로그가 반복됨 - YouTube 영상 시청에서는 750프레임 중 720프레임이 드롭되어 사실상 사용할 수 없었음 - 일반적인 상황이라면 커널을 bisect해 문제 지점을 찾겠지만, PCIE_65 패치 때문에 커널이 tainted 상태라 실제 원인을 판단하기 어려웠음 - AMD Radeon 대신 **Nvidia RTX 2060**을 장착함 - `nouveau` 커널 드라이버를 쓰려면 여전히 PCIE_65 패치가 필요했음 - 기본 Fedora 커널과 Nvidia 바이너리 드라이버 조합은 정상 동작함 - 영상 디코딩 가속과 Wine 기반 일부 게임도 동작함 - FreeCAD와 OrcaSlicer는 실행 직후 크래시됨 - 원인은 AArch64 Flatpak 저장소에 `org.freedesktop.Platform.GL.nvidia`가 없는 것이었음 - 두 도구는 자주 쓰는 앱이라 데스크톱 전환을 어렵게 만든 핵심 문제였음 ### x86-64 복귀와 Altra의 새 역할 - 결국 꺼두었던 **x86-64 시스템**을 다시 부팅함 - 케이블을 많이 옮기고 새 케이블도 배치한 뒤, 책상 아래에서 두 시스템을 함께 사용하게 됨 - `wooster`: Ampere Altra 시스템 - `puchatek`: Ryzen 5 3600 시스템 - 80코어에서 6코어 12스레드로 이동하는 경험은 낯설었지만, 실제 작업은 정상적으로 돌아감 - 모든 스레드를 사용해도 음악 재생이 계속됨 - Steam 라이브러리의 모든 게임을 플레이할 수 있음 - FreeCAD로 홈 프로젝트 케이스 설계를 마칠 수 있음 - OrcaSlicer에서 바로 3D 프린트용 프로토타입을 만들 수 있음 - Ampere Altra 시스템은 계속 켜둔 채 **RISC-V 패키지 빌드**를 처리함 - 이 시스템은 단일 스레드 성능은 약하지만, 멀티코어 부하에서는 빠르게 동작함 ### 같은 방식의 AArch64 데스크톱은 반복하지 않음 - Ampere Altra로 같은 데스크톱 실험을 반복할 계획은 없음 - 또 다른 AArch64 데스크톱을 시도하려면 **완전히 새로운 하드웨어 플랫폼**이 필요함 - Nvidia DGX Spark 시스템을 사기 위해 20,000 PLN 이상을 지출할 계획은 없음 ## Comments ### Comment 60910 - Author: neo - Created: 2026-07-01T09:04:05+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/pjcplu/end_aarch64_desktop_experiment) - 이 상황에는 어느 정도 공감함. 내 **Raptor Talos II**에서는 IBM이 PowerNV를 계속 깨뜨리고 있음 처음엔 amdgpu였고, 이제는 SATA 카드가 문제임. IBM이 비베어메탈 시스템용 PCIe를 계속 만지작거리는 바람에 6.14 커널에 묶여 있음 - 어떤 **Linux 배포판**을 쓰는지 궁금함. 회사 서버는 Ubuntu 26.04에 7.0 커널을 올려 쓰고 있는데 지원이 잘 되고 있음 출시 때부터 하나 갖고 싶었지만 이제는 꽤 오래됐고, 어쩌면 Power 11 버전이 나올 수도 있겠다는 생각이 듦 - 나도 비슷했음. **Thinkpad X13S**에서 NixOS를 돌려보려 했고, 어느 정도는 동작했지만 설치부터 Ubuntu ISO를 써야 했음 제대로 부팅되는 aarch64 UEFI NixOS 이미지를 찾지 못했기 때문임. 최신 커널 업그레이드 이후 부팅이 깨졌고, 이제는 시스템을 그냥 동작하게 만드는 데 쓸 기력이 바닥남 Ubuntu도 X13S 지원이 어느 정도 들어 있지만, 전통적인 x86_64 머신이라면 당연히 되는 것들이 꽤 많이 안 됨. 절전은 아예 안 되고, TPM 지원은 제한적이며, 그래픽도 특이하게 굴고, 테스트하지 못한 문제도 더 많을 것 같음 여기에 Anbernic 같은 회사의 에뮬레이션 핸드헬드처럼 오래된 이미지만 제공되는 ARM 장치나, Clockwork uConsole처럼 하드웨어를 영리하게 쓰거나 남용해서 비표준 커널 패치가 필요한 장치들은 제외하고도 그렇다. 결국 그런 소프트웨어는 업스트림에 들어가지 못하고, 업데이트할 수 없는 운영체제를 단 하드웨어로 남게 됨 Linux에서 ARM이 잘 동작하길 바라며 여러 컴퓨터에서 꽤 시간을 썼지만 막혀 있음. Raspberry Pi를 제외하면 그냥 되는 것이 없었고, 하드웨어/커널 쪽을 충분히 몰라서 의미 있는 개선을 만들기도 어려움 - 나도 **X13S**를 샀음. 크기와 무게가 완벽해 보였기 때문임 같은 방식으로 NixOS 설치에 몇 시간을 썼고, Ubuntu에서 설치해 대충 동작하게 만들었지만 너무 취약해서 사실상 제대로 쓰기 어려웠음 정말 잘 되길 바랐지만 Linux 쪽에서는 버려진 느낌이었고, 결국 포기하고 Apple MacBook Air에서 NixOS를 가상 머신으로 돌리게 됨 - 나도 X13s가 있는데, 시도한 배포판은 **Fedora**뿐이고 설치 프로그램을 시작하면 입출력 멈춤이 생김. 좋지 않음 Ubuntu에 큰 애정이 있는 것도 아니라 다른 배포판은 굳이 시도하지 않았고, Windows는 그래도 충분히 괜찮게 동작함 더 최신 SoC들은 특이점이 훨씬 적음. 예를 들어 커널 명령행을 한 문단 길이로 입력할 필요가 없음. 하지만 X13s의 X Elite 2 버전은 나오지 않음 - 새 **Nvidia RTX Spark 노트북**들이 공식 Linux 지원을 받을지 궁금함 결국 Ubuntu 파생 배포판을 돌리는 DGX Spark와 거의 같은 플랫폼인데, 지금까지의 조짐은 그다지 좋아 보이지 않음 - 반대 경험을 이야기하자면, **Radxa Rock5bPlus**를 4개월 정도 쓰고 있음. 16GB 메모리와 NVMe 구성이고, 메인라인 u-boot와 Fedora Rawhide의 EFI 버전, 메인라인 커널을 사용함 Collabora가 rk3588 지원을 메인라인에 올리기 위해 한 작업은 사실상 놀라울 정도임 아직 기다리는 부분은 있음. HDMI 2.0 이상, 즉 4k@60, 그리고 USB-C DP 같은 것들임. 그래도 하드웨어 측면에서는 내 XPS 13 9370보다 오히려 특이점이 적은 것 같음. 그 노트북은 5.14쯤부터 오디오 출력이 그냥 멈췄음 https://www.dell.com/community/en/conversations/xps/linux-audio-broken-on-xps-13-9370/647f9f5df4ccf8a8de428a6e https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md - **OrangePi 5 Plus**를 쓰고 있는데, HDMI 캡처가 이제 병합된 것을 봤음 아직 HDCP 지원은 없지만, 예전에 해봤던 저지연 1080p HDMI OSD 실험으로 돌아갈 때가 된 듯함 3프레임 지연으로 동작했었고, 이론상 최소는 2프레임. HDMI 신호 위에 Chromium Embedded를 오버레이해서 홈 미디어 구성에서 OSD 능력을 크게 확장할 수 있었음 가장 큰 문제는 불안정성이었고, 전체 구성이 OrangePi 커널을 정기적으로 크래시시켰음 - 이건 현재 **Linux의 하드웨어 지원 상태**를 더 잘 보여주는 것 같음. 인기가 있고 수익성이 있는 하드웨어만 커널 지원을 받고, 바이너리 드라이버의 상태는 예전부터 지금까지 계속 지옥임 사람들이 자기 하드웨어에서 뭔가를 동작시키려고 Linux를 쫓아다니다가 결국 오래된 커널에 묶이거나, 패치를 직접 유지하고 리베이스해야 하는 모습이 흥미로움. 이런 일을 하지 않아도 오래된 하드웨어를 지원하는 운영체제를 쓰는 대신 말임 - 내게는 이 결함 있는 하드웨어를 **AMD GPU**와 잘 동작하게 만들 방법을 아직 찾는 중처럼 들림 “Altra 제품군 정오표에 따르면 PCIE_65는 PCIe MMIO 쓰기에서 잘못된 주소를 생성할 수 있고, 특정 장치 유형, 특히 AMD GPU에 영향을 주므로 Altra 제품군은 일반적으로 그런 장치 유형과 호환되지 않는다. 실험 및 개발 작업을 진행할 수 있도록 GPL v2로 개념 증명 소프트웨어 패치를 제공했다”는 내용임 운영체제가 단순한 개념 증명 패치를 받아들이고 싶어 하지 않을 이유는 이해됨 특정 하드웨어 조각을 지원하는 Linux 커널 포크가 아주 많고, 이건 안타까운 일임. 이런 포크에는 메인라인 Linux 커널에 받아들여지려면 더 많은 작업이 필요한 침습적이거나 실험적인 커밋이 들어 있는 경우가 많음 다른 운영체제들은 여기서 다른 길을 가고 있는지 궁금함. 업스트림 기여를 쉽게 만들면서도 아키텍처, SoC, 보드 유지보수를 감당 가능하게 하려면 무엇을 하고 있을까 - 그렇다면 시도해보려던 수고는 덜었음. 그래도 **고통 지점**을 파악하는 일이 장기적으로는 도움이 되길 바람 - 나만 고생하는 줄 알았음. 개발 서버로 비슷한 사양을 썼는데, 대부분의 문제는 **네이티브 코드가 있는 Python 의존성**에서 나왔음 몇몇 최적화 패키지와 Matplotlib도 기억남. 일반 pip와 uv를 다 시도했지만 결국 소스에서 컴파일해야 했음. 결국 x86으로 완전히 돌아갔고, 솔직히 코어가 그렇게 많아도 성능이 그리 대단하지 않았음 - “pip와 uv를 다 시도했지만 결국 소스에서 컴파일해야 했다”는 게, pip 바깥으로 나가 패키지를 직접 빌드해야 했다는 뜻인지 궁금함 - 게임용으로 실제로 동작하는 **Linux 데스크톱**을 원한다면 Nvidia 카드와 바이너리 드라이버가 필요하고, 거기에 잘 맞춰 동작하지 못하는 Flatpak 같은 것은 피해야 함 이건 어떤 아키텍처에서든 수십 년 동안 그랬고, 상식에 가깝다고 봄 - 나는 **AMD GPU**를 쓰는데 Linux에서 게임이 아주 잘 됨. 게다가 예전 Nvidia와 그 멍청한 폐쇄형 드라이버 덩어리보다 전반적인 자잘한 문제도 적음 - 다른 용도로 Cuda 같은 Nvidia가 꼭 필요한 게 아니라면, Linux 게임에서는 몇 년 전부터 **AMD**가 선호되는 GPU였음 - 무슨 소리인지 모르겠음. **AMD GPU**는 게임에 잘 동작하고, 예를 들어 Flatpak 안의 Steam도 잘 됨 Steam의 경우 Flatpak에서는 Steam 컨트롤러 접근이 안 되긴 하지만, 그 외에는 문제없이 동작함 그런 주장을 하려면 “나를 믿어” 말고 뒷받침할 데이터라도 가져와야 함 - 최근 몇 년 동안 같은 기간을 놓고 보면, **AMD 기반 Steam Deck**, AMD APU인 5750GE 기반 미니 PC, Intel Arc B580이 NVIDIA 3090보다 실제로 더 나은 경험을 줬음 - 이렇게 **커널 패치에 민감한 구성**이라면 배포판의 커널 패키지는 아예 쓰지 않을 것 같음 패키지 시스템 밖에서 직접 커널을 빌드하고 부팅한 뒤, 내 속도에 맞춰 업데이트하겠음 - 이 글 흐름을 조금 따라보고 있었는데, 그렇게 오래 동작했다는 게 오히려 놀라웠음 항상 “어떻게든 되게 만들기”에 가까워 보였고, 그래도 이런 결말을 읽으니 아쉬움