AArch64桌面实验的终结

# AArch64桌面实验的终结 – Marcin Juszkiewicz 来源：https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment 本文是“让我尝试将AArch64系统用作桌面”系列的第7部分： 1. AArch64桌面：第一天 (https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/) 2. AArch64桌面：第二天 (https://marcin.juszkiewicz.com.pl/2015/09/22/aarch64-desktop-day-two/) 3. AArch64桌面：最后一天 (https://marcin.juszkiewicz.com.pl/2015/09/25/aarch64-desktop-last-day/) 4. Arm桌面：2025年尝试，第一部分 (https://marcin.juszkiewicz.com.pl/2025/07/07/arm-desktop-2025-attempt-part-one/) 5. Arm桌面：模拟 (https://marcin.juszkiewicz.com.pl/2025/07/22/arm-desktop-emulation/) 6. Arm桌面：核心虽多，速度不足 (https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/) 7. AArch64桌面实验的终结 (https://marcin.juszkiewicz.com.pl/2026/06/26/the-end-of-the-aarch64-desktop-experiment/) 在使用 AArch64 桌面约十一个月后，我决定结束这个实验。 ### 使用的硬件 大约一年前，我给自己买了一套 Ampere Altra 系统 (https://marcin.juszkiewicz.com.pl/2025/06/27/bought-myself-an-ampere-altra-system/)。在更换了一些硬件并额外下了几次订单后，最终配置如下： | 组件 | 型号 | |------|------| | 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 | 无名 USB3.2/10Gbps 控制器（PCIe x4）| 说句公道话，这是一块服务器主板，而非桌面主板，并且 Altra 系统从来就不是为桌面设计的（尽管有公司将其当作桌面来销售）。自然，经过测试/认可的设备列表（QVL，给 TLA 爱好者看的）相当短，而且对于 Ampere Altra 系统，列表里并不包含 AMD Radeon GPU 显卡。它们可以工作，但往往需要额外付出努力。 额外的 USB3.2 控制器让我能连接比主板原生支持更多的 USB 设备，并且提供了几个 10Gbps 端口用于连接外部 NVMe 硬盘。 整个系统在 Fedora 42～44 下运行得**还算**良好。 ### 第一个问题 你注意到上一段末尾那个小小的“\*”了吗？我使用的系统并非纯粹的 Fedora——我必须使用自己构建的内核。 你看，Ampere Altra 中的 PCI Express 控制器存在一些问题。让我引用一下 Ampere Altra erratum 82288 补丁 (https://github.com/AmpereComputing/linux-ampere-altra-erratum-pcie-65) 的描述： > 根据 Altra 系列勘误表，PCIE_65 可能导致在 PCIe MMIO 写入时生成无效地址，影响某些特定设备类型，尤其是 AMD GPU，因此 Altra 系列通常不兼容这些设备类型。 再来看补丁本身的更详细描述： > PCIe 设备驱动可能将 MMIO 空间映射为 Normal、non-cacheable 内存属性（例如 Linux 内核驱动使用 ioremap_wc 映射 MMIO）。这可能是为了启用写合并或非对齐访问。由于写合并操作的问题，这可能导致 PCIe 接口的出站 MMIO 写入出现数据损坏。解决方法是将映射 PCIe MMIO 空间为 Normal、non-cacheable 内存（例如 ioremap_wc）的软件修改为映射为 Device、non-gathering 内存（例如 ioremap）。并且对 PCIe MMIO 空间的所有内存操作必须严格对齐。 因此，要拥有一个可工作的 Linux 系统，我必须在每次软件包更新时重新构建内核。这通常意味着“每周一次”。每周一或周二，我会更新本地 Fedora 内核软件包仓库的副本，并使用自己的版本命名方案进行构建，例如“7.0.2-200.fc44.pcie65.6”。其中的“pcie65”部分提醒我应用了哪些补丁，而“6”则是补丁重基的计数器。 我从 GitHub 克隆仓库，然后重基补丁，必要时进行调整。副作用是我经常使用比官方 Fedora 版本更新的内核——Fedora 内核软件包仓库中有一个“稳定化”分支，即将推送的版本就在那里。所以当 Fedora 有 6.19.y 内核时，我用的是 7.0.z 版本。 ### 核心虽多，速度不足 正如我在上一篇文章 (https://marcin.juszkiewicz.com.pl/2026/06/01/arm-desktop-so-many-cores-not-enough-speed/) 中所写，拥有八十个 CPU 核心并不代表系统就是一台优秀、快速的桌面电脑。 ### AMDGPU 开始失效 如上所述，为了让我的 AMD Radeon RX6700XT 正常运行，我必须使用带有外部补丁的内核。它工作正常，我可以玩一些游戏，观看支持硬件视频解码加速的视频。 直到有一天，大约在 Linux 7.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 kernel: amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 ``` 一遍又一遍。观看 YouTube 视频也变得不可能，因为每 750 帧中有 720 帧被丢弃等等。 通常我会开始二分定位内核，找出问题所在。但由于我运行的是因 PCIE65 补丁而受污染的内核，谁知道问题到底出在哪里…… ### 入手 Nvidia 我买了一块 Nvidia RTX2060 显卡，替换掉 AMD Radeon。结果发现，如果我想用 `nouveau` 内核驱动，我仍然需要应用 PCIE65 补丁…… 于是我尝试了默认的 Fedora 内核搭配 Nvidia 二进制驱动。它工作正常。视频解码加速了，一些在 Wine 下的游戏也能正常运行。 但随后我开始运行 FreeCAD 和 OrcaSlicer。这两个程序都崩溃退出了…… 结果发现，在 AArch64 的 Flatpak 仓库中并没有 `org.freedesktop.Platform.GL.nvidia`。而我经常使用这两个工具。 ### 启动旧的 x86-64…… 此时，我放弃了。我启动了长期以来一直关机的 x86-64 系统。需要移动大量线缆，重新布置一些新线缆，现在我的桌下同时运行着“wooster”（Ampere Altra）和“puchatek”（Ryzen 5 3600）两台系统。 从 80 核迁移到 6 核（12 线程）是一种奇怪的体验。核心数量少得多，但事情运行得很好。我可以加载所有线程，音乐依然流畅播放。Steam 库中的所有游戏都可以玩。可用的 FreeCAD 让我能为家庭项目设计外壳，并直接从 OrcaSlicer 进行 3D 打印原型。 “wooster”系统保持开机状态，用于处理 RISC-V 软件包构建任务。它在单线程方面可能较弱，但在多核负载下表现飞快。 ### 结论 至于 Ampere Altra，我不打算重复这个实验。下一次 AArch64 桌面尝试需要一套全新的硬件平台。而且我也没有计划花费超过两万 PLN 来购买 Nvidia DGX Spark 系统。