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!