ASM2464PDX (USB4/TB4 4-Bay NVMe Enclosure) – PCIe Tunneling Link-Reset Loop (10s Timeout) unter PVE Kernel 7.0

[Landmark2632]

Hallo zusammen,

ich stoße bei einem 4-Bay NVMe Gehäuse (ASMedia ASM2464PDX Bridge Chip) auf ein reproduzierbares Stabilitätsproblem beim PCIe-Tunneling unter Proxmox VE.

Auf demselben Host läuft die Hardware unter einem normalen Debian Trixie (Kernel 7.0) absolut stabil im echten PCIe-Tunneling. Unter Proxmox VE (Kernel 7.0.14-pve) bricht der Retimer-Link jedoch exakt alle 10 Sekunden ab.

Hier ist eine Zusammenfassung des Problems, der bisherigen Diagnose und der Testergebnisse.

System-Konfiguration​

• Host: Minisforum UM780 XTX (AMD Ryzen 7 7840HS "Phoenix", AMD Pink Sardine USB4 Retimers 0x1032)
• OS: Proxmox VE (Kernel 7.0.14-17-pve)
• Gehäuse: 4-Bay NVMe Enclosure mit ASMedia ASM2464PDX Bridge

Symptom & Relevant Logs​

Beim Anstecken des Gehäuses startet die USB4-Aushandlung und die PCIe-Switch-Topologie wird initial erkannt (03:00.0 Upstream, 04:00.0-04:03.0 Downstream für die 4 NVMe-Endpoints). Nach exakt 10 Sekunden bricht der Retimer-Link ab und geht in eine Endlosschleife:

[ 1579.698934] thunderbolt 0-2: new device found, vendor=0xb8 device=0x2463
[ 1579.698940] thunderbolt 0-2: USB4_TBT SSD Enclosure
[ 1579.925769] thunderbolt 0-0:2.1: new retimer found, vendor=0x7fea device=0x1032
[ 1589.925000] thunderbolt 0-0:2.1: retimer disconnected
[ 1589.925400] thunderbolt 0-2: device disconnected

(Hinweis: Im Fallback auf USB 3.2 UASP / SCSI-Mode bspw. als /dev/sdd–/dev/sdg bleibt die Verbindung bestehen. Der Reset tritt ausschließlich bei aktiver PCIe-Tunnelung auf.)

Bisher durchgeführte Schritte & Erkenntnisse​

1. Firmware-Ausschluss:
   • Auf Debian Trixie (Kernel 7.0.13) verhält sich das Enclosure tadellos. Die Drives werden stabil unter nvme1n1 bis nvme4n1 eingebunden:
     • Non-prefetchable Memory behind bridge: 384M
     • Prefetchable Memory behind bridge: 64G
2. IOMMU / DMA Passthrough:
   • Getestet mit iommu.passthrough=1 und iommu=pt. Das Verhalten bleibt unter PVE unverändert.
3. PCIe MMIO Bridge-Window Pre-Allocation:
   • Getestet in Commandline mit: pci=assign-busses,realloc,hpmemsize=512M,hprefmemsize=64G
   • Damit soll das dynamische Rechen-Timeout der Bridge-Fenster für 4 Endpoints beim Hotplug abgefangen werden. (Copilot's Idee)
4. PCIe Power Management (ASPM):
   • Getestet mit pcie_aspm=off zur Vermeidung möglicher L0s/L1-State-Timeouts während der Tunneling-Aushandlung. (Copilot's Idee)
5. Driver / Module Reload Test:
   • Ein manuelles Enladen/Laden des Drivers im laufenden Betrieb (modprobe -r thunderbolt && modprobe thunderbolt) zeigt dieselbe 10s Reset-Schleife. Das schließt ein einfaches Initramfs-Timing-Problem aus.

Offene Punkte & Fragen an das Forum​

1. Gibt es im pve-kernel spezifische Patches bzgl. Thunderbolt/USB4-Retimer-Handshakes oder PCIe-Hotplug-Resource-Allocation, die sich vom Upstream-Debian-Kernel unterscheiden?
2. Warum schlägt das Allocating/Retimer-Training auf AMD Phoenix (Pink Sardine 0x1032) beim PVE-Build fehl, während Debian Trixie die 64G Prefetchable Windows ohne Abbruch zuweist?
3. Gibt es bekannte Module-Parameter für thunderbolt oder pcieport, um das Retimer-Link-Timeout auf Host-Seite zu verlängern?

Danke für jeden Input!

 

[Bu66as]

Das 10-Sekunden-Intervall fällt mir da direkt auf: pvestatd pollt genau in dem Takt die Storages. Versuch mal testweise, mit systemctl stop pvestatd den zu stoppen und steck das Gehäuse danach neu an. Wenn der Link dann hält, liegt's nicht am Kernel, sondern daran, dass dir da alle 10s was auf die getunnelten Devices zugreift. Das würde ich als ersten Test versuchen.

Zum Kernel-Unterschied: der pve-kernel ist kein Debian-Kernel, sondern der Ubuntu-Kernel mit Proxmox-Patches. Andere Basis, andere Config, da unterscheiden sich die Einstellungen bei sowas Speziellem wie USB4-Retimer-Handling. Vergleich mal auf beiden Systemen grep -iE 'thunderbolt|usb4' /boot/config-$(uname -r), und schau ob auf dem Trixie zufällig boltd läuft, das würde die Autorisierung anders handhaben (cat /sys/bus/thunderbolt/devices/domain0/security auf beiden). Spezielle TB-Patches kenne ich da nicht, aber die Ubuntu-Basis allein erklärt's schon.

Btw, die ganzen Cmdline-Parameter (hpmemsize, realloc, pcie_aspm=off) würd ich erstmal rausnehmen. Wenn du drei Workarounds gleichzeitig drin hast, weißt du am Ende nicht mehr, was hilft und was schadet. Sauber auf Standard zurück, dann probierst du eine Hypothese nach der anderen.

 

[Landmark2632]

Hi Bu66as,

erstmal vielen Dank für die schnelle Rückmeldung.
pvestatd hat nichts gebracht. Aber, die Autorisierung war schon das richtige Schlüsselwort.

Das Problem ist gelöst! Die Analyse der Kernel-Debug-Logs (thunderbolt.dyndbg=+p) hat die genaue Ursache gezeigt:

Ursache (Aus den Logs)​

• Kein Hardware-/Signal-Fehler: Die TMU-Zeitsynchronisation und die Switch-Initialisierung liefen sauber durch.
• Fehlende Tunnel-Zuweisung: Der Software Connection Manager im PVE-Kernel hat nach dem Erkennen der PCIe-Adapter (Port 3: PCIe) die PCIe-Tunnel-Pfade (tb_tunnel_alloc_pci) nicht automatisch autorisiert bzw. erstellt.
• Hardware-Keep-Alive-Timeout: Da nach der USB4-Erkennung knapp 10 Sekunden lang kein aktiver PCIe-Tunnel zugewiesen wurde, vermutlich lief die Bridge (ASM2464PDX) in ein internes Firmware-Timeout und hat die Verbindung getrennt, um das Link-Training neu zu starten (10s Reset-Schleife).

Lösung​

Eine udev-Regel erzwingt die sofortige Autorisierung des Thunderbolt/USB4-Domain-Tunnels beim Einstecken, bevor das 10-Sekunden-Timeout greift:

1. Regel anlegen:
   

   nano /etc/udev/rules.d/99-thunderbolt-authorize.rules

2. Inhalt einfügen:
   

   ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"

3. udev neu laden:
   

   udevadm control --reload-rules && udevadm trigger

Danach wird die PCIe-Switch-Topologie sofort aufgebaut. Alle 4 NVMe-Laufwerke binden stabil und dauerhaft auf PCIe Gen4 x4 Tunnel-Ebene ein (1x Gen4 x1 bzw. Gen3 x1 pro Slot behind the switch).

 

[Bu66as]

Das mit dem boltd war's also tatsächlich: auf dem Trixie ist das Paket bolt normalerweise schon installiert und autorisiert neue Geräte selbst, unter PVE ist es nicht drauf und der Kernel lässt das Device einfach unauthorized liegen, bis die Bridge nicht mehr weitermacht. Passt zu deinen Debug-Logs.

Noch ne Sache bei der udev-Regel: die lässt jedes Thunderbolt-Gerät durch, das irgendwann mal an dem Port steckt, inklusive DMA auf den Host. Wenn die Kiste im Schrank steht, geschenkt. Falls sie aber irgendwo frei zugänglich ist, würd ich apt install bolt und boltctl enroll <uuid> für dein Gehäuse machen, das ist sauberer. Dann ist genau das eine Device dauerhaft freigegeben und alles andere nicht. Ob boltd das in 10 Sekunden schafft, müsstest du testen, sollte aber klappen.