kurioses Grafikfehler mit Xorg/KDE Plasma bei hoher Netzwerkload via rsync/sshfs

[usbstick]

Hallo zusammen.

Ich habe heute meinen neuen Arbeitsdesktop eingerichtet und bin dabei auf ein merkwürdiges Problem gestoßen bei dem ich nicht so recht weiß woran es liegen könnte und hoffe auf einen Geistesblitz von euch.

Die Maschine (wird für Data Science Gedöns genutzt):

• Ryzen 7 PRO 4750G
• 2 x 32 GB RAM GSkill Ripjaws V, 3200 MHz CL16
• SSD Crucial MX500 1TB
• HDD WD Blue 4TB
• NT bequiet Straight Power 11 550W
• MB Gigabyte B550 Aorus Elite AX V2
• Gehäuse Sharkoon VS7
• Kühler Alpenföhn Ben Nevis Advanced
• OS: Arch mit KDE/Plasma
• Dateisysteme: durchgehend ext4

Ich wollte meine Daten … ca. 300 GB Dateien unterschiedlicher Größe … von meinem bisher genutzten Laptop (Dell Latitude 5001, auch Arch) per SSHFS (pubkey auth) per Drag&Drop im Dolphin über das lokale Netzwerk auf den neuen Rechner ziehen.

Nach ein paar GB zeigte der Desktop merkwürdige Grafikfehler/Artefakte und wurde unresponsiv. Zusätzlich wurden die Fensterinhalte nicht mehr angezeigt. Eine Überprüfung der CPU-Temperatur ergab, dass sie bei 33°C im grünen Bereich lag. Killen des plasmashell-Prozesses brachte keine Besserung.

Meine erste Vermutung war, dass, wie so häufig SSHFS einfach keine wirklich gute Lösung ist, und das Kopieren per Drag&Drop auch nur eine zusätzliche Fehlerquelle ist. Also versuchte ich es mit rsync (pubkey auth). Ein paar kleinere Verzeichnisse funktionierten problemlos … aber beim ersten wirklich großen Verzeichnis kam es auch hier zum gleichen Verhalten. Der einzige Unterschied war, dass ich hier nach einer Weile einfach ausgeloggt wurde und wieder im sddm Loginscreen landete.

Ich habe wirklich keine Ahnung woran dieses Verhalten liegen könnte. Das einzige was ich noch nicht getestet habe war der RAM (memtest).

Habt irgendwer schon einmal ein vergleichbares Verhalten gesehen und/oder eine Ahnung worauf das zurückzuführen sein könnte?

Ich stehe ehrlich gesagt vollkommen auf dem Schlauch.

 

[iWaver]

Hatte mit rsync im lokalen Netzwerk auch Probleme, mit --bwlimit=XY hat es dann funktioniert.
Warum, weiß ich nicht. Irgendetwas kann wohl nicht mit so vielen kleinen Dateien bei voller Geschwindigkeit umgehen.

 

[usbstick]

Hm. Es ist einen Versuch wert, allerdings ist die 2,5GBit Netzwerkkarte in einem 1GBit-Netzwerk ohnehin nie annähernd an ihre Grenze gekommen.

Update: Memtest sagt, dass der RAM in Ordnung ist.

 

[lokon]

ein paar GB zeigte der Desktop merkwürdige Grafikfehler/Artefakte

Habt irgendwer schon einmal ein vergleichbares Verhalten gesehen und/oder eine Ahnung worauf das zurückzuführen sein könnte?

(Neben-)Beobachtung: Du nutzt 64GB RAM und hast Arch.
Arch ist viel näher an "Bugs" und "ungetesteter Software" dran als "stabile Distributionen" (die neue Hardware nicht gut unterstützen)

Linux benutzt beim Kopieren teilweise sehr viel RAM als Zwischenspeicher.
Es gibt dann bei Linux teilweise "sehr seltsame" Bugs im Kernel, wenn viel RAM benutzt wird und zB nicht genug "Swap" vorhanden ist - bzw. der Swap sich "komisch" verhält oder der "OOM" Killer nicht so gut funktioniert. Mit USB-Kopieroperationen habe ich das mal beobachten können (allerding schon etwas länger her)
Diese Bugs können in unterschiedlichen Subsystemen des Kernel bzw. Anwendungprogramms liegen - und sind teilweise abhängig von den Einstellungen (Distributionsspezifisch).
Für die meisten User ist eine konkrete Diagnose , Bugticket und ein "fixen" zu zeitaufwendig - meist "verschwindet" der Fehler durch andere Einstellungen (zb bwlimit bei dir).

Beispiel (gibt auch andere): hackernews link+diskussion

Grafikfehler: sind mehrere Monitore angeschlossen ?
Der Cache-Speicher könnte etwas mit dem iGPU Speicher "interagieren" (Speicherleck?) bzw. zu langsames System weil die CPU zu beschäftigt mit Kopieroperation ist.

Ansonsten:
Neben "bwlimit" würden es vlt. "VM swappiness", wechseln des IO Schedulers (o. auch CPU Schedulers), "direct IO" (also kopieren ohne Cache), evtl auch NFS statt SSHFS ausprobieren, IRQ-Storm / anderes "rate limiting" untersuchen (trace / debug strukturen im Kernel nutzen ...)

google auch: "linux desktop unresponsive" in kombination mit "usb copy" u. anderen "copy" operationen

Der

Ryzen 7 PRO 4750G

ist etwas neu und nicht unbedingt bugfrei - AMD ist nicht so "vorsorgend" & ressourcenreich wie Intel und bringt die Treiber langsamer in den Kernel (Intel reicht aktuell Gen 13 GPU Code ein - also für ~2022-23er iGPU , quelle) - eventuell das Kernel-Log beobachten : journalctl -k ; und dort amdgpu Fehler/Warnungen suchen bzw. im Anwendungsjournal prüfen ob Desktop-Anwendungen abstürzen/Fehler produzieren.
zB nebenbei glxgears als einfaches Testprogramm laufen lassen - und/oder die HW Video-Dekodiereinheit

Beim journalctl -k auch über den "-p" Schalter die Fehlerprioritäten durchsehen und evtl. Bootnummer -b Schalter nutzen.

Erweiterter Hintergrund: prinzipiell würde eine Analyse vermutlich mit Tools erfolgen, die in solchen Blogposts wie 11 Mio. iops mit 10 ssds beschrieben sind

 

[usbstick]

Hm. Ja, eventuell wäre es auch ein Gedanke den Swap zu eliminieren.

Ich benutze Arch jetzt seit Anfang 2008 und hatte noch nie solche Probleme auf keiner Hardware. Tatsächlich habe ich auch auf meinem Privatrechner 64GB und auch dort keine solche Probleme …
In meinem Homeserver läuft auch der 4750G, dort aber Debian SID mit 5.10er kernel … und auch dort keine Probleme (da allerdings nur mit 16GB RAM). Ebenso habe ich high-load Szenarien schon gehabt mit dem gleichen Kernel zwischen ebenjenem Server und dem Privatrechner. Jeweils dasselbe Realtek 8125 Chipset für das Netzwerk. Auch da … nichts.

Monitor ist aktuell nur ein einzelner FullHD von Dell weil mein UHD-Arbeitsmonitor noch am Latitude hängt.

Danke für Deinen Input. Das mit dem Swap ist einen Versuch wert.

Ich hab mir jetzt zusätzlich noch eine alte FirePro V4900 aus der Grabbelkiste der IT Abteilung besorgt und teste morgen mal mit einer anderen CPU ohne iGPU. Der 4750G wurde nur angeschafft weil die GPU die ich eigentlich zum arbeiten bräuchte (egal was, Hauptsache 12GB+ Speicher und CUDA oder rocm) außerhalb des Budgets war.

 

[usbstick]

Zwischenstand:

• Das Verhalten tritt mit einer Ausnahme nur bei Operationen auf die mit Verschlüsselung zu tun haben
• Das Verhalten tritt mit einer Ausnahme nur auf wenn SSH direkt oder indirekt genutzt wird, und zwar mit
  • rsync
  • sshfs
• Das Verhalten tritt nicht auf wenn hohe Netzwerklast über NFS (v4) erzeugt wird
• Das Verhalten tritt nicht auf wenn hohe Netzwerklast über Samba erzeugt wird
• Memtest ergab, dass der RAM in Ordnung ist
• stress/s-tui ergab, dass die CPU unter Last keine Ausfälle zeigt

Ich bin fast so weit, das ganze als SSH-Fehler zu interpretieren.

 

[iWaver]

Wie genau sieht denn dein rsync Befehl aus?
Ich verwende üblicherweise "rsync --info=progress2 --bwlimit=10000 -az"

 

[lokon]

Der amdgpu hat keine Fehler oder Warnungen in den Logs ? Auch die Wiedergabe / "GPU-Test" während rsync/ssh läuft problemlos ?
zB gputest im AUR enthält auch furmark für Linux

Eventuell ändert sich der Fehler wenn die Auflösung/Farbtiefe oder iGPU RAM (bzw. Modulparameter für GART, GTT, VRAM) angepasst wird ?
Der "amdgpu-pro" Treiber könnte sich auch anders verhalten.

Ein openssl benchmark mit openssl speed -seconds <hohe Zahl> reicht bestimmt auch nicht um den Fehler zu erzeugen (ich denke mal es ist eine Kombination aus algorithmus + RAM belegung)?

eventuell ein on the fly verschlüsseln ? also etwas mit
dd if=/random bzw. /largefile /zero | openssl enc (AES encoding) > /dev/null bzw. durch mit netcat (nc) einfach blind senden

 

[usbstick]

Update!

Auch wenn mich andere Aufgaben die Woche über davon abgehalten haben die Migration abzuschließen, so konnte ich doch ein paar Kleinigkeiten testen.

• rsync habe ich in diversen Ausprägungen getestet … quasi immer das gleiche Ergebnis. Zum migrieren hatte ich allerdings ohnehin nur "rsync -r /bla /blub" genutzt
• amdgpu spuckt nichts besorgniserregendes aus
• iommu meckert ein wenig …

Aber dann …

BIOS Version F12

1. Update AMD AGESA ComboV2 1.1.0.0 D
2. Performance optimized on Ryzen 5000 series processors
3. Add Re-size bar option for AMD Smart Access Memory support
4. Improve connection stability for USB 2.0 ports of USB hub
5. Improve system stability

BIOS Version F13a

1. AMD AGESA ComboV2 1.2.0.0

Eigentlich wollte ich ja lieber schön langsam nur superstabile BIOS-Versionen nutzen weil es ja ein Produktivsystem ist. Aber ich habe es als letzte Option das Update auf F13a probiert und … es funktioniert.

Dass der Rechner unresponsiv bei langen Phasen des Stehenlassens wurde war wohl dem Punkt mit der Verbindungsstabilität für USB 2.0 geschuldet, denn genau da drin steckte das Keyboard. Tests mit USB 3.x-Ports zeigten mir aber Prä-Update, dass sie ebenfalls regelmäßig ausfielen.

Die plötzlichen Freezes unter I/O-Last sind jetzt trotz mehrfachem Provozierens auf die im Eingangsposting beschriebene Weise nicht wieder aufgetreten. Ich bin da einigermaßen zuversichtlich, dass es das auch war.

Kein sonderliches Ruhmesblatt für Gigabyte, dass sie dermaßen deutliche Fehler in ihren BIOSes ausliefern. Ich mutmaße mal, dass das nicht mit jeder CPU-Serie auftrat, denn dann wäre das ein extremes Qualitätsproblem. Allein schon weil es ja auch unter anderen OSen auftreten dürfte.

Nunja. Danke nochmal für euren Input!

 

[nullPtr]

Hm. Ja, eventuell wäre es auch ein Gedanke den Swap zu eliminieren.

Im Zusammenspiel mit einem vorhandenen tmpfs würde ich das übrigens auf keinen Fall empfehlen. Ich selbst habe bei älteren (3.x, 4.x) Kernel-Versionen die Erfahrung gemacht, dass, wenn einem der Speicher ausgeht und man kein Swap hat, die Kiste einfach hart freezed.
Meine Parameter waren ~8GB von 12GB RAM mit Daten in einem tmpfs voll gepackt. Hat wohl auch mit virtual memory over-subscription und dem OOM-Killer zu tun, aber rausfinden, was genau bei sowas die Ursache ist, ist für Laien (in Sachen Kernel) praktisch hoffnungslos.

 

[usbstick]

@nullPtr ja, das ist halt so. Allerdings hätte ich auf der Kistte mit 64G RAM auch ganz gut Reserven.

Was übrigens wohl zusätzlich in mein Ursprungsproblem mit reingespielt hat … jetzt so rückblickend, war wohl auch dieses Problem: https://www.computerbase.de/2021-02/amd-b550-x570-usb-verbindungsabbrueche-vr-headset/
Zumindest kann ich das auch (immer noch) nachvollziehen.

 

[Alexander2]

Interessant, somit ist es auch Bestriebssystemübergreifend - unabhängig vom Treiber. abgesehen davon, dass man es ggf. irgendwie mit dnem Treiber fixen kann.

Mir ist das zum Beispiel noch nicht aufgefallen, dass USB 3 ausfällt. ist zwar der X370 Chipsatz, aber ist ja auch ne Moderne CPU mit 3900X bei mir und der USB Controller ist ja in der CPU.

Ob das wohl nur die 550er Boards betrifft und nicht die X570? das da der 550er Chipsatz mit reinspielt? der ist ja von Asmedia glaube ich. anders als der X570, der ja von amd ist.

 

[lokon]

Ob das wohl nur die 550er Boards betrifft und nicht die X570? das da der 550er Chipsatz mit reinspielt? der ist ja von Asmedia glaube ich. anders als der X570, der ja von amd ist.

So richtig wird die Frage vielleicht nicht zu beantworten sein - ich hab hier mal "nachgeschaut" -
in den Changelogs steht zumindest ab und zu etwas von verbesserter USB Unterstützung - auch bei anderen Chipsätzen als B550 (evtl. aber unterschiedlich oft) - aber nicht bei jedem Hersteller .
Die vollständigen Änderungen sind vermutlich geheim / unter NDA - welche genauen Fehler zB AGESA jeweils behebt oder das Bios - zB was vorher "incompatible" war, bei Updates bei denen "Improve PCIe device compatibility" steht - da funktionierte eine oder mehrere Karten vielleicht nicht.