1 Punkte von GN⁺ 2025-02-18 | 1 Kommentare | Auf WhatsApp teilen
  • Auftreten des Problems: Auf einem Desktop-PC mit Dual-Boot von Windows und Linux trat beim Wechsel in den Ruhemodus unter Linux bei hoher RAM-Auslastung ein Systemabsturz auf. Beim Aufwecken erschien ein schwarzer Bildschirm oder das System reagierte nicht mehr. Ursache war ein Bug in der Energie-/Speicherverwaltung des amdgpu-Treibers.

  • Diagnose des Problems: Das System mit einem Gigabyte-B550M-DS3H-Mainboard und einer AMD RX 570 GPU lief unter Arch Linux. Nach den Abstürzen wurden die Logs mit journalctl geprüft, wobei ein Out-of-Memory-Fehler (OOM) in amdgpu_device_suspend entdeckt wurde. Der NVMe-Treiber konnte beim Fortsetzen des Systems nicht initialisiert werden, wodurch das System hängen blieb und keine Logs aufgezeichnet wurden.

  • Lösungsversuche: Es wurden verschiedene systemd-Einstellungen für unterschiedliche Ruhemodi ausprobiert und asynchrones Suspendieren deaktiviert, um das Problem zu vereinfachen, doch die eigentliche Ursache wurde nicht behoben. Es stellte sich heraus, dass der Absturz beim Entfernen von TTM-Buffern durch amdgpu auftrat.

  • Ursache des Problems: Wenn das System in den S3-Ruhemodus wechselt, wird die Stromversorgung der PCIe-GPU unterbrochen, wodurch die Daten im VRAM verloren gehen. Um das zu verhindern, muss der GPU-Treiber den VRAM im System-RAM sichern. Der amdgpu-Treiber unter Linux verursachte jedoch bei unzureichendem RAM einen Out-of-Memory-Zustand, der das System abstürzen ließ.

  • Lösung: Mario Limonciello schrieb einen Kernel-Patch, der den VRAM sichert, bevor der plattenbasierte Speicher deaktiviert wird. Der Patch verschiebt das VRAM-Backup von der Phase dpm_suspend() in die Phase dpm_prepare(), sodass das Suspendieren bei Speichermangel abgebrochen werden kann.

  • Zusätzliche Problemlösung: Der Nutzer schrieb ein Skript, das den VRAM aus dem User Space sichert, indem es ihn vor dem Suspendieren des Systems in den System-RAM verschiebt. Wenn jedoch mehrere 3D-Apps liefen, konnte VRAM weiterhin zur GPU verschoben werden, was erneut zu Abstürzen führen konnte.

  • Endgültige Lösung: Durch die Nutzung der Power-Management-Notification-API wurde das Verhalten so geändert, dass der VRAM in der Phase PM_SUSPEND_PREPARE gesichert wird. Dadurch kann der VRAM in den System-RAM verschoben werden, bevor Swap deaktiviert wird, was das Problem behebt.

  • Fazit: Das Problem wurde durch die Bemühungen mehrerer Beteiligter und diverse Versuche gelöst und soll in Linux-Kernel 6.14 aufgenommen werden.

1 Kommentare

 
GN⁺ 2025-02-18
Hacker-News-Kommentare
  • Es werden Zweifel an der Annahme geäußert, dass ein Desktop-System beim Wechsel in den S3-Schlafmodus die Stromversorgung der PCIe-GPU abschaltet

    • S3 sollte alles außer dem RAM stromlos machen, aber Gigabyte-Aorus-Mainboards haben ein NVMe-SSD-Schlaf-Bug, durch das sie nicht korrekt schlafen oder aufwachen
    • Um das zu beheben, muss eine udev-Regel hinzugefügt werden
    • Es gibt auch eine Möglichkeit, das Aufwachen an bestimmten PCIe-Ports zu verhindern
    • Es gibt eine Methode, problematische PCIe-Wakeup-Geräte zu finden
    • Mit dem Befehl udevadm lassen sich Geräteinformationen abrufen
    • Das Problem lässt sich auch mit einem Shell-Skript lösen
  • Der Autor von memreserver teilt seine Erfahrung mit dem Debugging zur Behebung eines Linux-Schlafproblems

    • Er weist auf das Problem hin, dass Linux keine verlässlichen Suspend-Hooks ausführen konnte, bevor die Festplatten- und Speichersubsysteme eingefroren wurden
    • Relevante Informationen sind auf Freedesktop GitLab schwer zu finden
  • Es wird erklärt, warum die Implementierung der Schlaf-Funktion unter Linux schwierig ist und warum das Debugging kompliziert ist

    • Auf einem ThinkPad P1G4 tritt das Problem auf, dass sich die Lüfter nicht automatisch abschalten
    • Es wurde das Problem erlebt, dass Bluetooth-Kopfhörer nach dem Aufwachen verzerrten Ton wiedergeben
  • Ein Nutzer eines Ryzen-basierten ThinkPad berichtet von Schlafproblemen unter Linux und hofft auf Version 6.14

  • Es wird die Meinung geteilt, dass das „Sleep/Wake“-Problem NP-vollständig sei

  • Es wird angemerkt, dass dies Nutzern eines Framework-AMD-Laptops mit GPU-Erweiterung und Dual-Boot mit Linux/Windows helfen dürfte

    • Es wird der Wunsch geäußert, dafür spenden zu wollen
  • Ein Nutzer arbeitet an der Behebung eines Problems, bei dem der PC nach dem Aufwachen mit einer AMD-GPU fast einfriert

    • Das Problem trat nach dem Wechsel von einer RX 5700 XT zu einer RX 7900 XTX auf
    • Es besteht die Hoffnung, dass Version 6.14 das Problem beheben kann
  • Es wird die Erfahrung geteilt, dass es bei der Nutzung von Linux schon immer Schlafprobleme gegeben habe

    • Selbst mit Hardware von Intel, AMD, ATI und NVIDIA funktionieren Schlafmodus oder Ruhezustand oft nicht richtig
  • Es wird eine Erfahrung mit dem Debugging von Schlafproblemen auf IoT-Hardware geteilt

    • Unter Linux ist der Ruhezustand des Systems oft zuverlässiger als der Schlafmodus
    • Wenn die SSD schnell genug ist, empfiehlt es sich, den Ruhezustand des Systems zu verwenden
  • Es wird erklärt, dass Speicherverwaltung und OOM-Bedingungen unter Linux weiterhin schwierige Probleme sind

    • Mehr RAM hinzuzufügen, um OOM-Probleme zu lösen, ist ineffizient
    • Die Debug-Shell-Funktion von systemd wird als nützlich bezeichnet
    • Nützliche Vorträge über Linux-Kernel-Subsysteme sind online verfügbar