En ZimaBoard 2-användare förväntade sig att själva Oculink-adaptern skulle visas i lspci. Diskussionen klargjorde att en passiv Oculink-koppling är en PCIe-förlängning: det viktiga resultatet är om enheten längst bort visas. Användarens GPU visades aldrig, trots att fläktarna snurrade, och webbgränssnittet slutade läsas in när ett grafikkort installerades i dockningsstationen.
Diskussionen förblev olöst efter flera adaptrar och två GPU:er. Den gav en användbar diagnostisk avgränsning: lös PCIe-enumerering och stabil uppstart innan NVIDIA-drivrutiner installeras.
Oculink behöver ingen egen drivrutin
Värden kan visa PCIe-rotningsportar eller bryggor, inte en enhet med namnet ”Oculink”. När inget är anslutet är detta normalt. Jämför PCIe-trädet före och efter att en välfungerande enhet anslutits:
lspci
lspci -tvOm slutpunkten inte visas i lspci kan nvidia-smi inte hitta den, och ett NVIDIA-paket kan inte reparera den fysiska länken.
Ström utan PCIe-enumerering är inte ett godkänt resultat
Snurrande fläktar bevisar bara att någon ström når kortet. De bevisar inte länkförhandling, kontinuitet i ledarna, stabilitet i hjälpmatningen eller initiering av slutpunkten. I den ursprungliga konfigurationen startade kortet normalt efter att dockningsstationen eller GPU:n tagits bort, vilket riktade felsökningen mot expansionskedjan.
En skadad adapter hittades, men ett byte slutförde inte felsökningen
Vid en noggrann inspektion hittades synliga avbrott i både ström- och dataspår på den första PCIe-till-Oculink-adaptern.
Använd en välfungerande lågrisk-slutpunkt för att isolera kedjan
En PCIe-USB-styrenhet visades i lspci via dockningsstationen, vilket visade att åtminstone en del av anslutningen kunde enumereras. Däremot gjorde både en RTX 5060 och senare en GTX 750 att webbgränssnittet inte lästes in. Det riktade uppmärksamheten mot dockningsstationen, strömförsörjningen, PCIe-länkförhandlingen eller plattformens kompatibilitet snarare än mot en enskild GPU-drivrutin.
Testa en variabel i taget: slutpunkten i en annan dator, en annan slutpunkt i samma dockningsstation, en välfungerande kabel, en välfungerande adapter, ett stabilt nätaggregat och korrekt startordning. Hotplugga inte Oculink- eller PCIe-hårdvara om inte dokumentationen uttryckligen stöder det.
Installera drivrutiner först när GPU:n visas
Användaren installerade RTX 50XX-tillägget innan kortet visades i lspci. Det tillförde en programvaruvariabel utan att lösa enumereringen. Använd den versionsspecifika RTX 50XX-handledningen i communityt först efter att hårdvaran har identifierats och endast när ZimaOS-versionen stämmer överens.
Anta inte att alla PCIe-GPU:er stöds officiellt
Oculink överför PCIe, men den praktiska kompatibiliteten beror fortfarande på länkbredd, inbyggd programvara, strömförsörjning, dockningsstationens konstruktion, GPU:ns option-ROM-beteende och drivrutiner. Den länkade dokumentationen om GPU-expansion från IceWhale beskriver expansionskoncept, men gör inte varje kombination av adapter och GPU till en validerad ZimaBoard 2-konfiguration.
Vanliga frågor om Oculink för ZimaBoard 2
Bör Oculink visas med namn i lspci?
Nej. Leta efter den anslutna PCIe-slutpunkten och dess överordnade brygga.
Bevisar snurrande GPU-fläktar att kortet har identifierats?
Nej. Kortet måste enumereras i lspci.
Löstes den här tråden helt?
Nej. Även den strömsnålare GTX 750 förhindrade fortfarande normal uppstart, och användaren övervägde en annan dockningsstation.
