Das Ende des AArch64-Desktop-Experiments

 (marcin.juszkiewicz.com.pl)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Rund 11 Monate lang wurde ein AArch64-Desktop auf Basis von Ampere Altra im Alltag genutzt, doch beim Einsatz einer Serverplattform wie eines Desktops summierten sich die Belastungen durch Kernel-, GPU- und App-Kompatibilität immer weiter
  • Das System bestand aus Ampere Altra Q80-30 mit 80 Kernen und 3,0 GHz, 128 GB RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T und Fedora 42–44; ursprünglich war es keine Desktop-Hardware
  • Für die Nutzung der AMD-GPU war ein Workaround-Patch für Erratum 82288 / PCIE_65 nötig, sodass bei Fedora-Kernel-Updates meist wöchentlich ein eigener Kernel neu gebaut werden musste
  • Ab etwa Linux 7.0 traten AMD-GPU-Fehler und Framedrops bei Videos auf; auch nach dem Wechsel auf eine Nvidia RTX 2060 stürzten FreeCAD und OrcaSlicer ab, weil im AArch64-Flatpak-Repository org.freedesktop.Platform.GL.nvidia fehlte
  • Am Ende erfolgte die Rückkehr zu einem x86-64-System mit Ryzen 5 3600; Ampere Altra bleibt statt als Desktop für RISC-V-Paket-Builds im Einsatz, und für einen neuen AArch64-Desktop wäre eine andere Hardwareplattform nötig

Server-Altra als Desktop-Konfiguration

  • Nach rund 11 Monaten praktischer Nutzung eines AArch64-Desktops wurde das Experiment beendet
  • Die finale Hardwarekonfiguration sah wie folgt aus
    • CPU: Ampere Altra Q80-30, 80 Kerne, 3,0 GHz
    • RAM: 128 GB, 8×16 GB HMA82GR7CJR8N-XN
    • GPU: AMD Radeon RX6700XT
    • NVMe: Lexar LM970 2 TB, ADATA SX8200 Pro 1 TB
    • Mainboard: ASRock Rack ALTRAD8UD-1L2T
    • PSU: MSI MPG A850G 850 W
    • Gehäuse: Endorfy 700 Air
    • USB3: namenloser PCIe-x4-USB-3.2/10-Gbit/s-Controller
  • Dieses Board ist ein Server-Mainboard, und auch das Altra-System selbst ist kein Produkt, das für Desktops entwickelt wurde
  • Die QVL des Ampere-Altra-Systems enthält keine AMD-Radeon-GPU-Karten; sie lassen sich zwar betreiben, erfordern aber häufig zusätzliche Arbeit
  • Der separate USB-3.2-Controller bietet mehr USB-Geräten und externen NVMes 10-Gbit/s-Ports als die Grundausstattung des Mainboards
  • Das Gesamtsystem lief unter Fedora 42–44, für die tatsächliche Nutzung war jedoch nicht der Standard-Fedora-Kernel, sondern ein selbst gebauter Kernel nötig

Kernel-Wartungsaufwand durch PCIE_65

  • Im PCI-Express-Controller von Ampere Altra gibt es das Problem Erratum 82288 / PCIE_65
  • PCIE_65 kann bei PCIe-MMIO-Schreibvorgängen falsche Adressen erzeugen und betrifft insbesondere bestimmte Gerätetypen wie AMD-GPUs
  • Probleme können auftreten, wenn Linux-Kerneltreiber MMIO-Bereiche wie mit ioremap_wc als Normal, non-cacheable Memory Attribute mappen
    • Ziel kann sein, Write Combining oder unaligned Accesses zu ermöglichen
    • In diesem Fall kann es bei outbound MMIO writes der PCIe-Schnittstelle zu Datenbeschädigung kommen
    • Der Workaround besteht darin, statt ioremap_wc mit ioremap als Device, non-gathering Memory zu mappen und alle Speicheroperationen im PCIe-MMIO-Bereich strikt auszurichten
  • Um es als normales Linux-System zu nutzen, musste bei jedem Fedora-Kernel-Paketupdate der Kernel neu gebaut werden; meist war das wöchentlich nötig
  • Nach dem Aktualisieren des lokalen Fedora-Kernel-Paket-Repositorys wurde nach einem eigenen Versionsschema wie 7.0.2-200.fc44.pcie65.6 gebaut
    • pcie65 bezeichnete den angewendeten Patch
    • Die letzte Zahl war ein Zähler für Patch-Rebases
  • Patches wurden aus einem GitHub-Repository geholt, rebased und bei Bedarf angepasst; dadurch kam teilweise ein neuerer Kernel als der offizielle Fedora-Kernel zum Einsatz

80 Kerne garantieren keine gefühlte Desktop-Leistung

  • 80 CPU-Kerne machten daraus noch keine gute Desktop-Maschine
  • Die hohe Kernzahl garantierte nicht die schnelle gefühlte Performance, die auf einem Desktop gebraucht wird

App-Kompatibilitätsprobleme auch nach GPU-Wechsel

  • Die AMD Radeon RX6700XT lief mit einem Kernel, auf den der out-of-tree-PCIE_65-Patch angewendet war; auch Spiele und hardwareunterstütztes Video-Decoding waren möglich
  • Ab irgendeinem Zeitpunkt rund um das Release von Linux 7.0 begann die AMD-GPU auszufallen
    • Beim Starten von Spielen wiederholte sich im Log amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
    • Beim Ansehen von YouTube-Videos wurden 720 von 750 Frames gedroppt, was sie praktisch unbenutzbar machte
  • Unter normalen Umständen würde man den Kernel bisecten, um die Problemstelle zu finden; wegen des PCIE_65-Patches war der Kernel jedoch tainted, sodass die tatsächliche Ursache schwer zu beurteilen war
  • Statt der AMD Radeon wurde eine Nvidia RTX 2060 eingebaut
    • Für den Kernel-Treiber nouveau war weiterhin der PCIE_65-Patch nötig
    • Die Kombination aus Standard-Fedora-Kernel und Nvidia-Binärtreiber funktionierte korrekt
    • Video-Decoding-Beschleunigung und einige Wine-basierte Spiele liefen ebenfalls
  • FreeCAD und OrcaSlicer stürzten direkt nach dem Start ab
    • Ursache war das Fehlen von org.freedesktop.Platform.GL.nvidia im AArch64-Flatpak-Repository
    • Da beide Tools häufig genutzt werden, war das ein zentrales Problem, das den Desktop-Wechsel erschwerte

Rückkehr zu x86-64 und die neue Rolle von Altra

  • Schließlich wurde das ausgeschaltete x86-64-System wieder gebootet
  • Nachdem viele Kabel umgesteckt und neue Kabel verlegt worden waren, wurden beide Systeme unter dem Schreibtisch gemeinsam genutzt
    • wooster: Ampere-Altra-System
    • puchatek: Ryzen-5-3600-System
  • Der Wechsel von 80 Kernen auf 6 Kerne und 12 Threads fühlte sich ungewohnt an, doch die eigentliche Arbeit lief normal weiter
    • Auch bei Nutzung aller Threads spielte die Musik weiter
    • Alle Spiele aus der Steam-Bibliothek sind spielbar
    • Mit FreeCAD lässt sich das Gehäuse für ein Heimprojekt fertig entwerfen
    • In OrcaSlicer können direkt Prototypen für den 3D-Druck erstellt werden
  • Das Ampere-Altra-System bleibt eingeschaltet und übernimmt RISC-V-Paket-Builds
  • Die Single-Thread-Leistung dieses Systems ist schwach, unter Multicore-Last arbeitet es jedoch schnell

Ein AArch64-Desktop auf dieselbe Weise wird nicht wiederholt

  • Es gibt keine Pläne, das gleiche Desktop-Experiment mit Ampere Altra zu wiederholen
  • Für einen weiteren AArch64-Desktop wäre eine völlig neue Hardwareplattform nötig
  • Es gibt keinen Plan, mehr als 20.000 PLN für ein Nvidia-DGX-Spark-System auszugeben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Kommentare auf Lobste.rs

  • Ich kann diese Situation bis zu einem gewissen Grad nachvollziehen. Auf meinem Raptor Talos II macht IBM PowerNV ständig kaputt.
    Zuerst war es amdgpu, jetzt ist die SATA-Karte das Problem. Weil IBM weiter an PCIe für Nicht-Bare-Metal-Systeme herumfummelt, hänge ich beim 6.14-Kernel fest.

    • Ich frage mich, welche Linux-Distribution du verwendest. Unsere Firmenserver laufen mit Ubuntu 26.04 und einem 7.0-Kernel, und die Unterstützung ist gut.
      Seit der Veröffentlichung wollte ich einen haben, aber inzwischen ist er ziemlich alt, und ich denke, vielleicht kommt ja eine Power-11-Version.

  • Bei mir war es ähnlich. Ich habe versucht, NixOS auf einem Thinkpad X13S laufen zu lassen, und es funktionierte bis zu einem gewissen Grad, aber schon für die Installation musste ich ein Ubuntu-ISO verwenden.
    Der Grund war, dass ich kein aarch64-UEFI-NixOS-Image finden konnte, das korrekt bootete. Nach dem Upgrade auf einen aktuellen Kernel war das Booten kaputt, und inzwischen ist mir die Energie ausgegangen, das System einfach nur zum Laufen zu bringen.
    Ubuntu hat zwar eine gewisse X13S-Unterstützung, aber ziemlich vieles, was auf einer klassischen x86_64-Maschine selbstverständlich wäre, funktioniert nicht. Energiesparen geht gar nicht, TPM-Unterstützung ist eingeschränkt, die Grafik verhält sich eigenartig, und es gibt vermutlich noch mehr Probleme, die ich nicht getestet habe.
    Und das sogar abgesehen von ARM-Geräten, für die nur alte Images bereitgestellt werden, etwa Emulations-Handhelds von Firmen wie Anbernic, oder Geräten wie dem Clockwork uConsole, die Hardware geschickt nutzen oder missbrauchen und deshalb nicht standardmäßige Kernel-Patches brauchen. Am Ende schafft es solche Software nicht upstream, und man bleibt mit Hardware zurück, auf der ein nicht aktualisierbares Betriebssystem läuft.
    Ich habe auf mehreren Computern ziemlich viel Zeit investiert, in der Hoffnung, dass ARM unter Linux gut funktioniert, aber ich stecke fest. Abgesehen vom Raspberry Pi funktionierte nichts einfach so, und ich kenne mich mit Hardware/Kernel nicht gut genug aus, um sinnvolle Verbesserungen beizutragen.

    • Ich habe mir ebenfalls ein X13S gekauft, weil Größe und Gewicht perfekt wirkten.
      Ich habe auf dieselbe Weise Stunden in die NixOS-Installation gesteckt und es über Ubuntu installiert und irgendwie zum Laufen gebracht, aber es war so fragil, dass es praktisch kaum vernünftig nutzbar war.
      Ich wollte wirklich, dass es gut funktioniert, aber auf der Linux-Seite fühlte es sich aufgegeben an. Am Ende habe ich aufgegeben und lasse NixOS jetzt in einer virtuellen Maschine auf einem Apple MacBook Air laufen.
    • Ich habe auch ein X13s; die einzige Distribution, die ich ausprobiert habe, war Fedora, und sobald der Installer startet, gibt es einen I/O-Hänger. Nicht gut.
      Da ich Ubuntu auch nicht besonders mag, habe ich keine anderen Distributionen ausprobiert, und Windows läuft immerhin ausreichend gut.
      Neuere SoCs haben deutlich weniger Eigenheiten. Zum Beispiel muss man keine Kernel-Kommandozeile in Absatzlänge eingeben. Aber eine X-Elite-2-Version des X13s gibt es nicht.

  • Ich frage mich, ob die neuen Nvidia RTX Spark-Laptops offiziellen Linux-Support bekommen werden.
    Letztlich ist es fast dieselbe Plattform wie DGX Spark, auf dem eine Ubuntu-Derivat-Distribution läuft, aber die bisherigen Anzeichen sehen nicht besonders gut aus.

  • Als Gegenbeispiel: Ich nutze seit etwa vier Monaten ein Radxa Rock5bPlus. Es hat 16 GB Speicher und NVMe, und ich verwende Mainline-u-boot, die EFI-Version von Fedora Rawhide und einen Mainline-Kernel.
    Die Arbeit, die Collabora geleistet hat, um rk3588-Support in den Mainline-Kernel zu bringen, ist tatsächlich erstaunlich.
    Es gibt noch Dinge, auf die ich warte: HDMI 2.0 und höher, also 4k@60, sowie USB-C DP. Trotzdem scheint es auf Hardware-Seite weniger Eigenheiten zu haben als mein XPS 13 9370. Bei diesem Laptop hat die Audioausgabe ungefähr seit 5.14 einfach aufgehört zu funktionieren.
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • Ich nutze ein OrangePi 5 Plus und habe gesehen, dass HDMI-Capture jetzt gemergt wurde.
      HDCP-Unterstützung gibt es noch nicht, aber es scheint Zeit zu sein, zu meinem früheren Experiment mit einem latenzarmen 1080p-HDMI-OSD zurückzukehren.
      Es lief mit 3 Frames Verzögerung, theoretisch wären mindestens 2 Frames möglich. Durch ein Overlay von Chromium Embedded über das HDMI-Signal konnte ich die OSD-Fähigkeiten meines Heimmedien-Setups stark erweitern.
      Das größte Problem war die Instabilität, und die ganze Konfiguration brachte den OrangePi-Kernel regelmäßig zum Absturz.

  • Das scheint eher den aktuellen Stand der Hardware-Unterstützung unter Linux zu zeigen. Nur populäre und profitable Hardware bekommt Kernel-Support, und der Zustand binärer Treiber ist seit jeher die Hölle.
    Interessant ist, wie Leute Linux hinterherlaufen, um irgendetwas auf ihrer Hardware zum Funktionieren zu bringen, und am Ende an alten Kerneln hängen bleiben oder Patches selbst pflegen und rebasen müssen – statt ein Betriebssystem zu nutzen, das alte Hardware unterstützt, ohne dass man all das tun muss.

    • Für mich klingt das so, als suche man noch nach einem Weg, diese fehlerhafte Hardware gut mit AMD-GPUs funktionieren zu lassen.
      Dort heißt es sinngemäß: „Laut Errata der Altra-Produktfamilie kann PCIE_65 bei PCIe-MMIO-Schreibvorgängen falsche Adressen erzeugen und betrifft bestimmte Gerätetypen, insbesondere AMD-GPUs; daher ist die Altra-Produktfamilie im Allgemeinen nicht mit solchen Gerätetypen kompatibel. Um Experimente und Entwicklungsarbeit zu ermöglichen, wurde ein Proof-of-Concept-Software-Patch unter GPL v2 bereitgestellt.“
      Ich verstehe, warum ein Betriebssystem nicht einfach einen bloßen Proof-of-Concept-Patch akzeptieren möchte.
      Es gibt sehr viele Linux-Kernel-Forks zur Unterstützung bestimmter Hardware, und das ist bedauerlich. In solchen Forks stecken oft invasive oder experimentelle Commits, die noch deutlich mehr Arbeit brauchen, bevor sie in den Mainline-Linux-Kernel aufgenommen werden können.
      Ich frage mich, ob andere Betriebssysteme hier einen anderen Weg gehen. Was tun sie, um Upstream-Beiträge einfacher zu machen und zugleich die Wartung von Architekturen, SoCs und Boards handhabbar zu halten?

  • Dann habe ich mir den Aufwand erspart, es selbst auszuprobieren. Trotzdem hoffe ich, dass das Ermitteln der Pain Points langfristig hilft.

  • Ich dachte, nur ich hätte damit zu kämpfen. Ich habe etwas mit ähnlichen Spezifikationen als Entwicklungsserver verwendet, und die meisten Probleme kamen von Python-Abhängigkeiten mit nativem Code.
    Ich erinnere mich auch an einige Optimierungspakete und Matplotlib. Ich habe sowohl normales pip als auch uv ausprobiert, musste am Ende aber aus dem Quellcode kompilieren. Schließlich bin ich vollständig zu x86 zurückgekehrt, und ehrlich gesagt war die Performance trotz der vielen Kerne nicht besonders beeindruckend.

    • Ich frage mich, ob „ich habe sowohl pip als auch uv ausprobiert, musste am Ende aber aus dem Quellcode kompilieren“ bedeutet, dass du außerhalb von pip gehen und die Pakete direkt bauen musstest.

  • Wenn man einen Linux-Desktop will, der für Gaming tatsächlich funktioniert, braucht man eine Nvidia-Karte und den binären Treiber, und man sollte Dinge wie Flatpak vermeiden, die damit nicht sauber zusammenspielen.
    Das war auf jeder Architektur seit Jahrzehnten so, und ich halte es fast für Allgemeinwissen.

    • Ich nutze eine AMD-GPU, und Gaming unter Linux funktioniert hervorragend. Außerdem gibt es insgesamt weniger kleine Probleme als früher mit Nvidia und diesem dummen Haufen geschlossener Treiber.
    • Wenn man Nvidia nicht zwingend für andere Zwecke wie Cuda braucht, ist AMD für Linux-Gaming seit einigen Jahren die bevorzugte GPU.
    • Ich weiß nicht, wovon du redest. AMD-GPUs funktionieren gut fürs Gaming, und zum Beispiel Steam in Flatpak funktioniert ebenfalls gut.
      Bei Steam ist in Flatpak zwar kein Zugriff auf Steam-Controller möglich, aber sonst funktioniert es problemlos.
      Wenn du so eine Behauptung aufstellst, solltest du mehr als nur „vertrau mir“ liefern und wenigstens unterstützende Daten mitbringen.
    • Wenn ich die letzten Jahre im selben Zeitraum betrachte, haben ein AMD-basierter Steam Deck, ein Mini-PC mit AMD-APU 5750GE und ein Intel Arc B580 in der Praxis tatsächlich eine bessere Erfahrung geliefert als eine NVIDIA 3090.

  • Bei einer so Kernel-Patch-sensiblen Konfiguration würde ich die Kernel-Pakete der Distribution vermutlich gar nicht verwenden.
    Ich würde den Kernel außerhalb des Paketsystems selbst bauen und booten und dann in meinem eigenen Tempo aktualisieren.

  • Ich hatte diesen Thread ein wenig verfolgt, und mich hat eher überrascht, dass es so lange funktioniert hat.
    Es sah immer eher nach „irgendwie zum Laufen bringen“ aus, und trotzdem ist es schade, dieses Ende zu lesen.