Raspberry Pi 4 SSD Boot Problem - xHCI HC died beheben

Raspberry Pi 4 SSD Boot Problem - xHCI HC died beheben

Mein Raspberry Pi 4, der seit Jahren brav von einer USB-SSD bootet, wollte plötzlich nicht mehr. Bullseye runter, Trixie drauf, Reboot - und der Pi hängt im LED-Loop oder crasht nach ein paar Minuten mit xhci_hcd: HC died. Zwei Tage Diagnose später hatte ich die Ursache und einen funktionierenden Setup. Hier ist die Story.

DarkWolfCave.de

🔗 Dieser Artikel ist die Fortsetzung von Raspberry von SSD starten aus 2023. Der dort beschriebene Klon-Workflow funktioniert heute nicht mehr zuverlässig. Hier erfährst du warum und wie es mit aktuellem Raspberry Pi OS trotzdem klappt.

Der Ausgangspunkt - der alte Workflow lief jahrelang

Im Februar 2023 habe ich den Artikel Raspberry von SSD starten geschrieben. Der Workflow ist simpel: SD-Karte mit Bullseye via Balena Etcher Clone Drive auf eine USB-SSD klonen, BOOT_ORDER auf USB First setzen, fertig.

Genau so habe ich auch meinen RPi 4 eingerichtet, der bei mir als Monitoring-Host läuft (Telegraf, Loki, Uptime-Kuma). UGreen-Gehäuse mit ASMedia-ASM235CM-Bridge, Crucial-SSD, lief monatelang stabil.

Bis ich von Bullseye auf Trixie wollte.

Der Plan war einfach, der Ablauf nicht

Eigentlich sollte das eine Stunde Arbeit sein. Pi Imager auf, frisches Raspberry Pi OS Lite (Trixie, Debian 13) auf die SSD flashen, cloud-init für Hostname und SSH-Key vorbereiten, Pi starten, Container aus dem Backup ziehen. Fertig.

Stattdessen sah der Ablauf so aus:

1. Pi Imager auf dem Mac hängte mehrfach beim Flashen bei 11 Prozent
2. Eine zweite SSD zeigte sofort SMART FAILED - tatsächlicher Hardware-Defekt am Controller
3. Der erste Boot-Versuch von der SSD endete im 1Hz-LED-Loop ohne SSH
4. Nach EEPROM-Update bootete er endlich - und crashte nach fünf Minuten mit xhci_hcd: HC died
5. Mehrere Kernel-Workarounds (usb-storage.quirks, pcie_aspm=off) verzögerten den Crash, verhinderten ihn aber nicht
6. Bookworm statt Trixie probiert: Bootloader fand die Bridge nicht mal mehr
7. Drei verschiedene EEPROM-Versionen durchgespielt: alle scheiterten
8. rpi-clone direkt von SD auf SSD: Bridge disconnected mid-clone

Spätestens da war klar: Das ist kein Software-Problem, das ist Hardware-Inkompatibilität.

Symptome zum Wiedererkennen

Wenn du auf einen Pi 4 mit USB-SSD-Boot stößt und dieselben Probleme hast, dann sehen die Symptome ungefähr so aus:

• 1Hz-LED-Loop beim Boot, kein SSH erreichbar
• Pi bootet, kommt hoch, läuft fünf bis zehn Minuten, dann ist SSH tot
• dmesg zeigt nach Crash: xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead, danach HC died; cleaning up und usb 2-2: USB disconnect
• Ping geht noch durch, aber kein Login möglich, weil der rootfs-Zugriff hängt
• Frischer Pi-Imager-Flash verhält sich anders als ein Bullseye-Klon, der jahrelang lief
• Die over-current change Zähler im Kernel-Log eskalieren

Wenn du mehrere dieser Punkte kennst, hast du höchstwahrscheinlich dasselbe Problem.

Die Diagnose - was sich seit 2023 geändert hat

Der bewährte Workflow aus dem Original-Artikel hat zwei stille Annahmen:

1. Du klonst Bullseye mit Kernel 5.10
2. Dein USB-SATA-Adapter ist mit dem Pi-4-USB-Controller kompatibel

Beide Annahmen stimmen 2026 nicht mehr automatisch. Die Hauptursache ist der Kernel-Sprung.

Raspberry Pi OS	Kernel	PCIe ASPM	Verhalten mit ASM235CM
Bullseye	5.10.x	konservativ	stabil
Bookworm	6.6.x	mittel-aggressiv	grenzwertig
Trixie	6.12.x	sehr aggressiv	xHCI-Crash

PCIe ASPM (Active State Power Management) schaltet ungenutzte PCIe-Lanes in einen Stromsparmodus. Auf dem Pi 4 hängt der USB-3.0-Host-Controller (VL805) an PCIe. Wenn der Kernel ihn schlafen schickt und der USB-SATA-Adapter im falschen Moment einen Transfer auslöst, wacht der VL805 nicht sauber auf. Das Ergebnis steht im Log: HC died.

Dazu kommt der Bridge-Mismatch: Die ASMedia ASM235CM ist eine USB-3.1-Gen2-Bridge (10 Gbit/s), der VL805 auf dem Pi spricht nur USB 3.0 Gen1 (5 Gbit/s). Das Timing-Mismatch hat unter dem alten Kernel niemanden gestört, der neue Kernel reagiert empfindlicher.

Der Bug ist gut dokumentiert. Die zentralen Anlaufstellen sind Issue #5076 im raspberrypi/linux Repo und Issue #5060 zum xHCI-Disconnect.

Warum die Kernel-Quirks alleine nicht reichen

Linux kennt seit Jahren das Konzept der USB-Storage-Quirks. Du kannst dem Kernel über Boot-Parameter mitteilen, dass eine bestimmte Bridge nicht im modernen UAS-Modus laufen soll, sondern im alten BOT-Modus (Bulk-Only Transport, langsamer aber stabiler).

In /boot/firmware/cmdline.txt ergänzt das so aus:

# Drei Parameter ergänzen, Rest unverändert lassen
usb-storage.quirks=174c:235c:u usbcore.autosuspend=-1 pcie_aspm=off

Was die drei Parameter machen:

Parameter	Wirkung
usb-storage.quirks=174c:235c:u	Erzwingt BOT-Modus für die Bridge mit der USB-ID 174c:235c (ASMedia ASM235CM). Das :u ist die Flag NO_UAS.
usbcore.autosuspend=-1	Deaktiviert USB-Autosuspend komplett. Der USB-Bus geht nie schlafen.
pcie_aspm=off	Schaltet PCIe-Power-Management ab. VL805 bleibt dauerhaft aktiv.

Das Problem: Diese Parameter wirken erst, wenn der Linux-Kernel läuft. Vor dem Kernel muss aber der RPi-Bootloader (im EEPROM) die Bridge ansprechen, um bootcode.bin und den Kernel selbst von der SSD zu laden. Der Bootloader kennt keine Linux-Quirks. Wenn die Bridge dort schon stolpert, kommt der Boot-Vorgang nicht weit.

Genau das war bei mir der Fall. Mit dem ASM235CM unter Trixie konnte ich die Quirks setzen wie ich wollte - der Crash kam trotzdem.

Die Lösung - anderer Adapter mit anderem Chipsatz

Nach 30 Stunden Diagnose und elf Versuchen brachte ein Adapter-Wechsel die Lösung. Aus der Bastelkiste tauchte ein älterer No-Name-USB-3.0-zu-SATA-Adapter auf, der einen Norelsys-NS1068-Chip verwendet (USB-ID 2537:1068).

Mit diesem Adapter geflasht, frisches Trixie-Image, Quirks gesetzt - und der Pi bootet sauber, läuft seit Stunden ohne einen einzigen xHCI-Crash.

Der Norelsys hat zwei Vorteile:

1. Der Linux-Kernel hat eingebaute Quirks für genau diesen Chipsatz (Quirks match for vid 2537 pid 1068: 800000)
2. Es ist eine reine USB-3.0-Bridge, kein 10-Gbit-Speed-Mismatch zum VL805

Die maximale Schreibgeschwindigkeit liegt bei rund 38 MB/s. Für einen Monitoring-Host völlig ausreichend, für einen Desktop oder Datenbank-Server eher nicht.

Adapter-Empfehlung 2026

Da die Pi Foundation keine offizielle Kompatibilitätsliste pflegt, hier die Erfahrungswerte aus Community und meinem Setup:

Eher meiden auf Pi 4 mit Bookworm/Trixie:

• ASMedia ASM235CM (Vendor 174c, Product 235c) - der Hauptverdächtige
• JMicron JMS578 - bekannt für UASP- und TRIM-Probleme

Funktioniert nach Berichten gut:

• Norelsys NS1068 (2537:1068) - in meinem Setup verifiziert
• ASMedia ASM1153E (älter als ASM235CM)
• StarTech mit eigenem Controller

Wichtig: Vor dem Kauf den Chipsatz herausfinden. Das ist auf der Verpackung selten dokumentiert. Wer einen aktuellen Pi 4 mit USB-SSD aufsetzt, kommt um das Thema heute nicht mehr drumherum.

ℹ️ Hinweis zum Original-Artikel: Im alten Artikel von 2023 habe ich einen anderen Adapter empfohlen. Der lief bei mir mehrere Jahre auf drei bis vier Pi 4 stabil unter Bullseye. Mit aktuellem Bootloader und Trixie ist genau dieser Adapter aber nicht mehr zuverlässig - mein altes Modell gibt es so auch nicht mehr zu kaufen. Heute würde ich einen JSAUX SATA auf USB Adapter für 2.5 Zoll SSD und HDD Festplatten (USB 3.0) nehmen. Als Alternative berichten Nutzer Erfolg mit dem StarTech USB 3.0 auf 2.5” SATA III Festplatten Adapter Kabel.

Den eigenen Adapter prüfen mit lsusb

Wenn du dir nicht sicher bist, was bei dir verbaut ist: Pi mit angeschlossener SSD starten (zur Not noch von SD), dann diesen Befehl:

# USB-SATA-Bridge identifizieren
lsusb

Die Ausgabe sieht ungefähr so aus:

Bus 002 Device 003: ID 174c:235c ASMedia Technology Inc. Ugreen Storage Device

Vendor-ID ist die Zahl vor dem Doppelpunkt, Product-ID dahinter. Beides zusammen identifiziert den Chipsatz. Mit einer schnellen Suche nach 174c:235c xhci raspberry (oder deinem konkreten Wert) findest du sehr schnell heraus, ob du auf dem bekannten Problem-Pfad bist.

Zur Bestätigung lohnt ein Blick ins Kernel-Log:

# Auf bekannte Fehlermuster prüfen
dmesg | grep -iE "xhci.*died|over-current change|HC died"

Wenn dort der over-current change Zähler eskaliert oder ein HC died auftaucht, hast du das Adapter-Problem.

Der funktionierende Setup im Überblick

Mein finaler Stand auf dem Monitoring-Pi sieht so aus:

Komponente	Wert
Hardware	Raspberry Pi 4 Model B Rev 1.1 (4 GB)
USB-SATA-Adapter	Norelsys NS1068 (2537:1068)
SSD	Crucial M500 240 GB (SATA)
OS	Raspberry Pi OS Lite 64-bit (Trixie)
Kernel	6.12.x rpt-rpi
EEPROM-Bootloader	aktuelle Version aus dem default-Channel
cmdline.txt-Zusatz	usb-storage.quirks=2537:1068:u usbcore.autosuspend=-1 pcie_aspm=off
Pre-Config	cloud-init via user-data, meta-data, network-config in der bootfs-FAT32

Die Pre-Config über cloud-init ersetzt den alten Etcher-Klon-Workflow. Statt eine bestehende SD zu spiegeln, schreibe ich auf die FAT32-Bootpartition der frischen SSD vier Dateien (user-data, meta-data, network-config, ssh) und der Pi konfiguriert sich beim ersten Boot selbst.

Eine kuriose Bridge-zu-SSD-Inkompatibilität

Eine Erkenntnis aus den Diagnose-Tagen, die du im Hinterkopf haben solltest: Auch wenn du einen guten Adapter hast, passt nicht jede SSD zu jeder Bridge.

Mit dem Norelsys NS1068 wollte ich zuerst eine Crucial MX500 1 TB anschließen. Ergebnis im Log: [sda] Media removed, stopped polling. Die Bridge konnte die SSD nicht stabil enumerieren.

Mit der älteren Crucial M500 240 GB an derselben Bridge: läuft sauber.

Solche Bridge-zu-SSD-Inkompatibilitäten sind selten, aber dokumentiert. Wenn deine erste Wahl beim Pi nicht erkannt wird, lohnt der Test mit einer anderen SSD bevor du den Adapter wegwirfst.

Was im alten Artikel heute fehlt

Der ursprüngliche Raspberry von SSD starten ist 2023 entstanden, mit Bullseye und einem damals völlig unauffälligen ASMedia-Adapter. Folgende Punkte sind aus heutiger Sicht ergänzungsbedürftig:

1. Adapter-Wahl ist heute entscheidend. “Irgendein USB-SATA-Adapter” reicht 2026 nicht mehr. Chipsatz prüfen.
2. Kernel-Quirks gehören in cmdline.txt. Auf modernen OS-Versionen sind sie quasi Pflicht, gerade auf dem Pi 4.
3. Klonen via Balena Etcher Clone Drive ist nicht mehr der beste Weg. Frisch flashen plus cloud-init Pre-Config ist sauberer und reproduzierbarer.
4. EEPROM-Bootloader updaten. Aktuelle Bootloader haben mehr Repeat-after-fail-Fixes als die Versionen von 2023.

Wenn du den alten Artikel als How-To nutzt und auf moderne OS-Versionen wechseln willst, denke an diese vier Punkte zusätzlich.

Quellen für die tiefere Recherche

Falls du den Bug selbst nachverfolgen willst, hier die wichtigsten Anlaufstellen:

• raspberrypi/linux Issue #5076 - ASMedia ASM235CM Issue
• raspberrypi/linux Issue #5060 - USB SSD disconnects, xHCI not responding
• raspberrypi/linux Issue #5659 - PCIe Express regression on CM4/Pi 4
• bookworm-feedback Issue #83 - VL805 firmware loading regression
• rpi-eeprom Release Notes
• James A Chambers - Best SSD Storage Adapters for Pi 4

Was du aus dieser Story mitnehmen kannst

Drei Punkte für den Werkzeugkasten:

1. lsusb ist dein erstes Tool. Wenn ein USB-Gerät auf dem Pi zickt, beginnt die Diagnose immer mit der Vendor- und Product-ID.
2. Quirks vor Adapter-Tausch versuchen. Wenn die Bridge wenigstens den Bootloader übersteht, kann man mit Kernel-Parametern viel retten.
3. Bei Bridge-Versagen vor dem Kernel hilft nur Hardware-Wechsel. Linux kommt nicht vor sich selbst dran. Andere Bridge oder zurück auf den alten Kernel.

Wenn dein Pi 4 also plötzlich nicht mehr von der USB-SSD will, obwohl er es jahrelang tat: Prüfe zuerst den Adapter-Chipsatz, schau dir die Quirks an, und wenn das nicht reicht, ist ein anderer Adapter mit anderem Chipsatz der schnellste Weg zurück zu einem laufenden System.

Wer sein bestehendes USB-SSD-Setup gerade neu aufbaut, findet im verlinkten Original-Artikel von 2023 die Grundlagen zum BOOT_ORDER und EEPROM-Update. Der Rest aus diesem Artikel ergänzt den Workflow für aktuelle Raspberry Pi OS Versionen.