The end of the AArch64 desktopexperiment

Lobsters Hottest News

Summary

Marcin Juszkiewicz concludes his 11-month experiment using an Ampere Altra AArch64 system as a desktop, citing ongoing PCIe issues that required custom kernel builds and limiting its viability as a daily driver.

<p><a href="https://lobste.rs/s/pjcplu/end_aarch64_desktopexperiment">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 06/30/26, 03:32 AM

# The end of the AArch64 desktop experiment – Marcin Juszkiewicz Source: [https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment](https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment) This post is part 7 of the "Let me try to use an AArch64 system as a desktop" series: 1. [AArch64 desktop: day one](https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/) 2. [AArch64 desktop: day two](https://marcin.juszkiewicz.com.pl/2015/09/22/aarch64-desktop-day-two/) 3. [AArch64 desktop: last day](https://marcin.juszkiewicz.com.pl/2015/09/25/aarch64-desktop-last-day/) 4. [Arm desktop: 2025 attempt, part one](https://marcin.juszkiewicz.com.pl/2025/07/07/arm-desktop-2025-attempt-part-one/) 5. [Arm desktop: emulation](https://marcin.juszkiewicz.com.pl/2025/07/22/arm-desktop-emulation/) 6. [Arm desktop: so many cores, not enough speed](https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/) 7. [The end of the AArch64 desktop experiment](https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment/) After about eleven months of using an AArch64 desktop, I decided to end that experiment\. ### Hardware used About a year ago,[I bought myself an Ampere Altra system](https://marcin.juszkiewicz.com.pl/2025/06/27/bought-myself-an-ampere-altra-system/)\. After moving some hardware around and making a few extra orders, the final setup was: CPUAmpere Altra Q80\-30 processor \(80 cores at 3\.0GHz\)RAM128GB\(8x16GBHMA82GR7CJR8N\-XN\)GPUAMDRadeonRX6700XTNVMELexarLM9702TB ADATASX8200Pro1TBMotherboardASRock RackALTRAD8UD\-1L2TPSUMSIMPGA850G\(850W\)CaseEndorfy 700 AirUSB3no\-nameUSB3\.2/10Gbps controller \(PCIe x4\)To be fair, I should mention that this is a server motherboard, not a desktop one, and Altra systems were never meant to be desktops \(despite companies selling them as such\)\. Naturally, the list of tested/approved devices \(Qualified Vendor List \(QVLforTLAfans\)\) is quite short and for Ampere Altra systems, it does not containAMDRadeonGPUcards\. They can be made to work, but this often requires additional effort\. The extraUSB3\.2 controller allowed me to have moreUSBdevices than the motherboard alone supported, and gave me some 10Gbps ports for connecting external NVMe drives\. The whole system was running just fine\*under Fedora 42–44\. ### The first issue Have you noticed the small “\*” at the end of the previous paragraph? The system I used was not quite Fedora — I had to use my own, self\-built kernel\. You see, thePCIExpress controller in the Ampere Altra has some issues\. Let me quote the description of[the Ampere Altra erratum 82288](https://github.com/AmpereComputing/linux-ampere-altra-erratum-pcie-65)patches: > Per Altra family erratum, PCIE\_65 may cause invalid addresses to be generated on PCIe mmio writes, impacting certain device types, notablyAMDGPUs, and thus the Altra family is not generally compatible with those device types\. And longer description from patch itself: > PCIe device drivers may mapMMIOspace as Normal, non\-cacheable memory attribute \(e\.g\. Linux kernel drivers mappingMMIOusing ioremap\_wc\)\. This may be for the purpose of enabling write combining or unaligned accesses\. This can result in data corruption on the PCIe interface’s outboundMMIOwrites due to issues with the write\-combining operation\. The workaround modifies software that maps PCIeMMIOspace as Normal, non\-cacheable memory \(e\.g\. ioremap\_wc\) to instead Device, non\-gathering memory \(e\.g\. ioremap\)\. And all memory operations on PCIeMMIOspace must be strictly aligned\. So, to have a working Linux system, I had to rebuild the kernel on every package update\. Which usually meant “weekly”\. Each Monday or Tuesday, I would update the local copy of the Fedora kernel package repository and build it using my own versioning scheme, like “7\.0\.2\-200\.fc44\.pcie65\.6”\. The “pcie65” part reminded me which patches I had applied, and the “6” was a counter for the patch rebases\. I cloned the repository from GitHub and then rebased patches, adapting them whenever they needed work\. The side effect was that I often used a newer kernel than the official Fedora release — there is a “stabilisation” branch in the Fedora kernel package repo where the soon\-to\-be\-pushed version is present\. So, when Fedora had 6\.19\.y kernel, I had 7\.0\.z one\. ### So many cores, not enough speed As[I wrote in my previous post](https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/), having eightyCPUcores does not mean that the system is a good, fast desktop machine\. ### AMDGPUstarted failing As I mentioned above, to get myAMDRadeonRX6700XTrunning properly I had to alter kernel with the out\-of\-tree patches\. It worked, I could play some games, watch videos with hardware\-assisted video decode acceleration\. Until one day, around the Linux 7\.0 release, when it started to fail\. Running a game ended with: ``` kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 ``` Over and over again\. Watching YouTube videos became impossible due to 720 out of 750 frames being dropped, etc\. Normally I would start to bisect the kernel to find out where the problem is\. But I was running a tainted kernel due toPCIE65patches so who knew where the problem actually was… ### Let’s get Nvidia I bought an NvidiaRTX2060 graphics card and put it in place of theAMDRadeon\. It turned out that if I wanted to use it with the`nouveau`kernel driver I still neededPCIE65patches applied… So I tried default Fedora kernel with Nvidia binary driver\. And it worked fine\. Video decoding was accelerated, some games under Wine worked as well\. But then I started FreeCAD\. And OrcaSlicer\. And in both cases I got crash and exit… It turned out that there was no`org\.freedesktop\.Platform\.GL\.nvidia`in Flatpak repositories for AArch64\. And I used both of those tools quite often\. ### Powering up the old x86\-64… At that point, I gave up\. And booted my x86\-64 system, which had been powered off all that time\. There were a lot of cables to move, some new ones to arrange, and now I have both “wooster” \(Ampere Altra\) and “puchatek” \(Ryzen 5 3600\) systems running under my desk\. Moving from 80 cores to 6 cores \(12 threads\) was a weird experience\. A much smaller number, yet things work fine\. I can load all threads and the music still plays\. All games from my Steam library are playable\. A working FreeCAD allows me to finish designing cases for my home projects and I can 3D print prototypes straight from OrcaSlicer\. The “wooster” system stays powered on, churning throughRISC\-V package builds\. It may be weak in single\-thread, but it flies when it comes to multi\-core load\. ### Conclusion As for the Ampere Altra, I am not planning to repeat this experiment\. Another AArch64 desktop attempt would require a completely new hardware platform\. And I have no plans to spend over twenty thousandPLNto buy an NvidiaDGXSpark system\.

Similar Articles

A Linux desktop in x86_64 Assembly

Lobsters Hottest

A developer rebuilt their entire Linux desktop stack—from shell to terminal, window manager, and utilities—in pure x86_64 Assembly using Claude Code, achieving microsecond startup times and hours of extra battery life.

Arm desktop: so many cores, not enough speed

Lobsters Hottest

A developer shares his experience using an 80-core ARM desktop, noting that while multi-core builds are fast, single-thread performance and latency issues cause problems for everyday tasks like web browsing and audio playback.

An Arm Mainboard for the Framework Laptop

Jeff Geerling

Jeff Geerling tests the MetaComputing AI PC Arm mainboard for the Framework Laptop, featuring Cix's P1 SoC and 16GB LPDDR5 RAM. The board offers UEFI support and runs Ubuntu, with acceptable performance but higher idle power consumption compared to AMD alternatives.

My 2025 high-end Linux PC 🐧

Michael Stapelberg

A detailed blog post about building a high-end Linux PC in 2025, including component selection, setup, and troubleshooting a faulty Intel CPU.