El fin del experimento de escritorio AArch64

• Usé durante unos 11 meses un escritorio AArch64 basado en Ampere Altra en la práctica, pero al usar una plataforma de servidor como si fuera de escritorio, la carga de compatibilidad de kernel, GPU y apps siguió acumulándose
• El sistema combinaba Ampere Altra Q80-30 de 80 núcleos a 3.0GHz, 128GB de RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T y Fedora 42–44; desde el inicio no era hardware pensado para escritorio
• Para usar la GPU AMD hacía falta un parche de workaround para erratum 82288 / PCIE_65, por lo que con cada actualización del kernel de Fedora había que volver a compilar un kernel propio, generalmente cada semana
• Alrededor de Linux 7.0 aparecieron errores con la GPU AMD y caídas de frames en video; incluso tras cambiar a una Nvidia RTX 2060, FreeCAD y OrcaSlicer crasheaban por la ausencia de org.freedesktop.Platform.GL.nvidia en el repositorio Flatpak de AArch64
• Al final volví a un sistema x86-64 con Ryzen 5 3600, dejé la Ampere Altra para compilar paquetes RISC-V en vez de usarla como escritorio, y concluí que para un nuevo escritorio AArch64 haría falta otra plataforma de hardware

---

Configuración para usar una Altra de servidor como escritorio

• Después de usar durante unos 11 meses un escritorio AArch64 en la práctica, di por terminado el experimento
• La configuración final de hardware fue la siguiente
  • CPU: Ampere Altra Q80-30, 80 núcleos a 3.0GHz
  • RAM: 128GB, 8×16GB HMA82GR7CJR8N-XN
  • GPU: AMD Radeon RX6700XT
  • NVMe: Lexar LM970 2TB, ADATA SX8200 Pro 1TB
  • Placa madre: ASRock Rack ALTRAD8UD-1L2T
  • PSU: MSI MPG A850G 850W
  • Gabinete: Endorfy 700 Air
  • USB3: controlador PCIe x4 USB 3.2/10Gbps sin marca
• Esta placa es una placa madre de servidor, y el sistema Altra en sí tampoco es un producto diseñado para escritorio
• La QVL del sistema Ampere Altra no incluye tarjetas GPU AMD Radeon, y aunque pueden hacerse funcionar, a menudo requieren trabajo adicional
• El controlador USB 3.2 separado ofrece más dispositivos USB y puertos de 10Gbps para NVMe externos que el soporte básico de la placa madre
• Todo el sistema funcionó con Fedora 42–44, pero para el uso real hacía falta un kernel compilado por cuenta propia, no el kernel estándar de Fedora

La carga de mantenimiento del kernel creada por PCIE_65

• El controlador PCI Express de Ampere Altra tiene el problema erratum 82288 / PCIE_65
• PCIE_65 puede generar direcciones incorrectas en escrituras MMIO por PCIe, y afecta especialmente a ciertos tipos de dispositivos, como las GPU AMD
• Pueden aparecer problemas cuando el driver del kernel Linux mapea el espacio MMIO con atributos de memoria Normal, non-cacheable, como ioremap_wc
  • El objetivo puede ser habilitar write combining o accesos no alineados
  • En ese caso, puede producirse corrupción de datos en escrituras MMIO outbound de la interfaz PCIe
  • El workaround consiste en mapear como memoria Device, non-gathering, como con ioremap en vez de ioremap_wc, y alinear estrictamente todas las operaciones de memoria del espacio MMIO PCIe
• Para usarlo como un sistema Linux normal, había que recompilar el kernel con cada actualización del paquete de kernel de Fedora, y normalmente hacía falta hacerlo cada semana
• Tras actualizar el repositorio local de paquetes de kernel de Fedora, lo compilaba con una regla de versionado propia como 7.0.2-200.fc44.pcie65.6
  • pcie65 indicaba el parche aplicado
  • El último número era el contador de rebase del parche
• Tomaba los parches de un repositorio de GitHub, los rebaseaba y los modificaba cuando era necesario; como resultado, a veces usaba un kernel más reciente que el oficial de Fedora

80 núcleos no garantizan una buena sensación de rendimiento en escritorio

• Tener 80 núcleos de CPU no lo convertía necesariamente en una buena máquina de escritorio
• Una gran cantidad de núcleos no garantizaba el rendimiento rápido y perceptible que se necesita en un escritorio

Problemas de compatibilidad de apps que siguieron incluso después de cambiar la GPU

• La AMD Radeon RX6700XT funcionaba con un kernel que incluía el parche out-of-tree de PCIE_65, y también era posible ejecutar juegos y usar decodificación de video asistida por hardware
• En algún momento alrededor del lanzamiento de Linux 7.0, la GPU AMD empezó a fallar
  • Al ejecutar juegos, se repetía el log amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
  • Al ver videos de YouTube, se caían 720 frames de 750, por lo que en la práctica era inutilizable
• En una situación normal habría hecho bisect del kernel para encontrar el punto del problema, pero por el parche PCIE_65 el kernel quedaba en estado tainted, lo que hacía difícil determinar la causa real
• En lugar de la AMD Radeon, instalé una Nvidia RTX 2060
  • Para usar el driver de kernel nouveau seguía haciendo falta el parche PCIE_65
  • La combinación del kernel estándar de Fedora con el driver binario de Nvidia funcionaba correctamente
  • También funcionaban la aceleración de decodificación de video y algunos juegos basados en Wine
• FreeCAD y OrcaSlicer crasheaban justo después de arrancar
  • La causa era que el repositorio Flatpak de AArch64 no tenía org.freedesktop.Platform.GL.nvidia
  • Como son dos herramientas que uso con frecuencia, fueron un problema clave que dificultó la transición de escritorio

Regreso a x86-64 y nuevo rol para Altra

• Al final volví a arrancar el sistema x86-64 que tenía apagado
• Después de mover muchos cables y también colocar cables nuevos, terminé usando ambos sistemas juntos debajo del escritorio
  • wooster: sistema Ampere Altra
  • puchatek: sistema Ryzen 5 3600
• Pasar de 80 núcleos a 6 núcleos y 12 hilos se sintió extraño, pero el trabajo real siguió funcionando normalmente
  • La música seguía reproduciéndose incluso usando todos los hilos
  • Puedo jugar todos los juegos de mi biblioteca de Steam
  • Puedo terminar el diseño de la carcasa de un proyecto casero en FreeCAD
  • Puedo crear prototipos para impresión 3D directamente en OrcaSlicer
• El sistema Ampere Altra sigue encendido y se encarga de compilar paquetes RISC-V
• Este sistema tiene un rendimiento de un solo hilo débil, pero funciona rápido con cargas multinúcleo

No repetiré un escritorio AArch64 del mismo modo

• No planeo repetir el mismo experimento de escritorio con Ampere Altra
• Si intento otro escritorio AArch64, hará falta una plataforma de hardware completamente nueva
• No planeo gastar más de 20,000 PLN para comprar un sistema Nvidia DGX Spark

[GN⁺]

Opiniones en Lobste.rs

• Me identifico en cierta medida con esta situación. En mi Raptor Talos II, IBM sigue rompiendo PowerNV.
  Al principio era amdgpu, y ahora el problema es una tarjeta SATA. Como IBM sigue toqueteando PCIe para sistemas que no son bare metal, estoy atado al kernel 6.14.

  • Me da curiosidad qué distribución de Linux usas. En los servidores de la empresa usamos Ubuntu 26.04 con el kernel 7.0 y el soporte ha sido bueno.
    Quise tener uno desde su lanzamiento, pero ya tiene bastantes años, y me pregunto si quizá salga una versión Power 11.

• A mí me pasó algo parecido. Intenté correr NixOS en una Thinkpad X13S y, hasta cierto punto, funcionó, pero desde la instalación tuve que usar una ISO de Ubuntu.
  Fue porque no pude encontrar una imagen aarch64 UEFI de NixOS que arrancara correctamente. Después de actualizar al kernel más reciente, el arranque se rompió, y ya se me agotó la energía para simplemente hacer que el sistema funcione.
  Ubuntu también tiene cierto soporte para la X13S, pero muchas cosas que en una máquina x86_64 tradicional se darían por sentadas no funcionan. La suspensión no funciona en absoluto, el soporte de TPM es limitado, los gráficos se comportan de forma rara, y sospecho que hay más problemas que no alcancé a probar.
  Y eso sin contar dispositivos ARM para los que solo se ofrecen imágenes viejas, como las consolas portátiles de emulación de empresas como Anbernic, o dispositivos como la Clockwork uConsole, que usan —o abusan— del hardware de forma ingeniosa y requieren parches de kernel no estándar. Al final, ese software no llega upstream y el hardware queda con un sistema operativo que no se puede actualizar.
  He dedicado bastante tiempo en varias computadoras esperando que ARM funcionara bien en Linux, pero estoy estancado. Salvo la Raspberry Pi, nada funcionaba sin más, y no sé lo suficiente del lado de hardware/kernel como para hacer mejoras significativas.

  • Yo también compré una X13S, porque su tamaño y peso parecían perfectos.
    Pasé horas instalando NixOS de la misma manera, la instalé desde Ubuntu y logré que funcionara más o menos, pero era tan frágil que en la práctica era difícil usarla bien.
    De verdad quería que funcionara bien, pero en Linux se sentía abandonada, y al final me rendí y terminé corriendo NixOS en una máquina virtual sobre una Apple MacBook Air.
  • Yo también tengo una X13s, y la única distribución que probé fue Fedora; al iniciar el instalador se congela la E/S. Nada bien.
    Tampoco le tengo gran cariño a Ubuntu, así que no intenté con otras distribuciones, y Windows de todos modos funciona lo suficientemente bien.
    Los SoC más recientes tienen muchas menos rarezas. Por ejemplo, no hace falta escribir una línea de comandos del kernel de un párrafo de largo. Pero no salió una versión X Elite 2 de la X13s.

• Me pregunto si las nuevas laptops Nvidia RTX Spark tendrán soporte oficial para Linux.
  Al fin y al cabo son casi la misma plataforma que DGX Spark, que corre una distribución derivada de Ubuntu, pero las señales hasta ahora no se ven muy alentadoras.

• Para contar la experiencia opuesta: llevo unos 4 meses usando una Radxa Rock5bPlus. Tiene 16 GB de memoria y NVMe, y uso u-boot mainline, la versión EFI de Fedora Rawhide y el kernel mainline.
  El trabajo que hizo Collabora para llevar el soporte de rk3588 a mainline es, francamente, sorprendente.
  Todavía hay cosas que estoy esperando: HDMI 2.0 o superior, es decir, 4k@60, y cosas como USB-C DP. Aun así, desde el punto de vista del hardware, creo que tiene menos rarezas que mi XPS 13 9370. En esa laptop, la salida de audio simplemente dejó de funcionar alrededor de la versión 5.14.
  https://dell.com/community/en/…
  https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

  • Uso una OrangePi 5 Plus, y vi que la captura HDMI ya fue integrada.
    Todavía no hay soporte para HDCP, pero parece momento de volver a mis experimentos anteriores de OSD HDMI de 1080p y baja latencia.
    Funcionaba con 3 cuadros de latencia, y el mínimo teórico es de 2 cuadros. Superponía Chromium Embedded sobre la señal HDMI, lo que permitía ampliar mucho las capacidades de OSD en una configuración de medios para el hogar.
    El mayor problema era la inestabilidad, y toda la configuración hacía que el kernel de OrangePi se colgara regularmente.

• Esto parece mostrar mejor el estado actual del soporte de hardware en Linux. Solo el hardware popular y rentable recibe soporte en el kernel, y el estado de los drivers binarios ha sido y sigue siendo un infierno.
  Es interesante ver a la gente persiguiendo Linux para hacer funcionar algo en su hardware y al final quedar atada a kernels viejos, o tener que mantener y rebasar parches por su cuenta, en lugar de usar un sistema operativo que soporte hardware antiguo sin tener que hacer todo eso.

  • A mí me suena a que todavía están buscando cómo hacer que este hardware defectuoso funcione bien con GPU AMD.
    Dice algo así: “Según la fe de erratas de la familia Altra, PCIE_65 puede generar direcciones incorrectas en escrituras PCIe MMIO y afecta a ciertos tipos de dispositivos, en particular GPU AMD, por lo que la familia Altra generalmente no es compatible con esos tipos de dispositivos. Para permitir trabajo experimental y de desarrollo, se proporcionó un parche de software de prueba de concepto bajo GPL v2”.
    Entiendo por qué un sistema operativo no querría aceptar un parche que es solo una prueba de concepto.
    Hay muchísimos forks del kernel de Linux para dar soporte a piezas específicas de hardware, y eso es una lástima. Esos forks muchas veces contienen commits invasivos o experimentales que necesitarían más trabajo para ser aceptados en el kernel Linux mainline.
    Me pregunto si otros sistemas operativos están tomando otro camino aquí. ¿Qué estarán haciendo para que contribuir upstream sea fácil y, a la vez, el mantenimiento de arquitecturas, SoC y placas siga siendo manejable?

• Entonces me ahorré el esfuerzo de intentar probarlo. Aun así, espero que identificar los puntos de dolor ayude a largo plazo.

• Pensé que era el único sufriendo con esto. Usé una configuración parecida como servidor de desarrollo, y la mayoría de los problemas venían de dependencias de Python con código nativo.
  Recuerdo algunos paquetes de optimización y también Matplotlib. Probé tanto pip normal como uv, pero al final tuve que compilar desde el código fuente. Terminé volviendo por completo a x86 y, sinceramente, aunque tuviera tantos núcleos, el rendimiento no era tan impresionante.

  • Me pregunto si con “probé pip y uv, pero al final tuve que compilar desde el código fuente” quieres decir que tuviste que salirte de pip y construir los paquetes manualmente.

• Si quieres un escritorio Linux que realmente funcione para juegos, necesitas una tarjeta Nvidia y el driver binario, y debes evitar cosas como Flatpak que no se llevan bien con eso.
  Esto ha sido así durante décadas en cualquier arquitectura, y diría que es casi sentido común.

  • Yo uso una GPU AMD y los juegos en Linux van muy bien. Además, en general tengo menos problemas menores que con las antiguas Nvidia y ese bloque tonto de drivers cerrados.
  • Si no necesitas específicamente Nvidia para otro uso, como Cuda, AMD ha sido la GPU preferida para jugar en Linux desde hace varios años.
  • No sé de qué hablas. Las GPU AMD funcionan bien para juegos, y Steam dentro de Flatpak, por ejemplo, también funciona bien.
    En el caso de Steam, en Flatpak no se puede acceder al Steam Controller, pero fuera de eso funciona sin problemas.
    Si vas a hacer una afirmación así, deberías traer algún dato que la respalde, no solo “créeme”.
  • Si miro el mismo periodo en los últimos años, una Steam Deck basada en AMD, una mini PC con APU AMD 5750GE y una Intel Arc B580 me dieron en la práctica una mejor experiencia que una NVIDIA 3090.

• Si fuera una configuración tan sensible a parches del kernel, creo que directamente no usaría el paquete de kernel de la distribución.
  Compilaría y arrancaría mi propio kernel fuera del sistema de paquetes, y lo actualizaría a mi propio ritmo.

• Había estado siguiendo un poco el hilo de esta publicación, y más bien me sorprendió que funcionara durante tanto tiempo.
  Siempre parecía algo más cercano a “hacer que funcione como sea”, y aun así da pena leer este desenlace.