The end of the AArch64 desktop experiment – Marcin Juszkiewicz
This post is part 7 of the "Let me try to use an AArch64 system as a desktop" series:
AArch64 desktop: day one
AArch64 desktop: day two
AArch64 desktop: last day
Arm desktop: 2025 attempt, part one
Arm desktop: emulation
Arm desktop: so many cores, not enough speed
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.<br>After moving some hardware around and making a few extra orders, the final setup was:
CPU<br>Ampere Altra Q80-30 processor (80 cores at 3.0GHz)
RAM<br>128 GB (8x 16GB HMA82GR7CJR8N-XN)
GPU<br>AMD Radeon RX6700XT
NVME<br>Lexar LM970 2TB<br>ADATA SX8200 Pro 1TB
Motherboard<br>ASRock Rack ALTRAD8UD-1L2T
PSU<br>MSI MPG A850G (850W)
Case<br>Endorfy 700 Air
USB3<br>no-name USB 3.2/10Gbps controller (PCIe x4)
To be fair, I should mention that this is a server motherboard, not a desktop<br>one, and Altra systems were never meant to be desktops (despite companies<br>selling them as such). Naturally, the list of tested/approved devices (Qualified<br>Vendor List (QVL for TLA fans)) is quite short and for Ampere Altra systems, it<br>does not contain AMD Radeon GPU cards. They can be made to work, but this often<br>requires additional effort.
The extra USB 3.2 controller allowed me to have more USB devices than the<br>motherboard alone supported, and gave me some 10Gbps ports for connecting<br>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<br>I used was not quite Fedora — I had to use my own, self-built kernel.
You see, the PCI Express controller in the Ampere Altra has some issues. Let me<br>quote the description of<br>the Ampere Altra erratum 82288 patches:
Per Altra family erratum, PCIE_65 may cause invalid addresses to be generated<br>on PCIe mmio writes, impacting certain device types, notably AMD GPUs, and<br>thus the Altra family is not generally compatible with those device types.
And longer description from patch itself:
PCIe device drivers may map MMIO space as Normal, non-cacheable memory<br>attribute (e.g. Linux kernel drivers mapping MMIO using ioremap_wc). This may<br>be for the purpose of enabling write combining or unaligned accesses. This can<br>result in data corruption on the PCIe interface’s outbound MMIO writes due to<br>issues with the write-combining operation.
The workaround modifies software that maps PCIe MMIO space as Normal,<br>non-cacheable memory (e.g. ioremap_wc) to instead Device, non-gathering memory<br>(e.g. ioremap). And all memory operations on PCIe MMIO space must be strictly aligned.
So, to have a working Linux system, I had to rebuild the kernel on every package<br>update. Which usually meant "weekly". Each Monday or Tuesday, I would update<br>the local copy of the Fedora kernel package repository and build it using my own<br>versioning scheme, like "7.0.2-200.fc44.pcie65.6". The "pcie65" part reminded me<br>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<br>whenever they needed work. The side effect was that I often used a newer kernel<br>than the official Fedora release — there is a "stabilisation" branch in the<br>Fedora kernel package repo where the soon-to-be-pushed version is present. So,<br>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,<br>having eighty CPU cores does not mean that the system is a good, fast desktop machine.
AMD GPU started failing
As I mentioned above, to get my AMD Radeon RX6700XT running properly I had to<br>alter kernel with the out-of-tree patches. It worked, I could play some games,<br>watch videos with hardware-assisted video decode acceleration.
Until one day, around the Linux 7.0 release, when it started to fail. Running a<br>game ended with:
kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0<br>kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0<br>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<br>750 frames being dropped, etc.
Normally I would start to bisect the kernel to find out where the problem is.<br>But I was running a tainted kernel due to PCIE65 patches so who knew where the<br>problem actually was…
Let’s get Nvidia
I bought an Nvidia RTX 2060 graphics card and put it in place of the AMD Radeon.<br>It turned out that if I wanted to use it with the nouveau kernel driver I<br>still needed PCIE65 patches applied…
So I tried default Fedora kernel with Nvidia binary driver. And it worked fine.<br>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...