Abstürze mit RTX 4000 Ada unter TrueNAS (Linux)

[crogge]

System: AMD Ryzen 5950X, 96GB ECC RAM, Gigabyte MC12, NVMe RAID, TrueNAS (25.10.4)

Die GPU steckt via RIser Kabel im PCIe 4.0 x4 Slot da der PCIe x16 Slot durch die 4x4 Bifurcation Karte belegt wird.

Der Server erkennt die GPU sofort, TrueNAS installiert den 570 Treiber und ich kann (meistens) Ollama via Docker laufen lassen, Temperaturen und Auslastung passen. Leider hängt sich das Ganze dann jedoch nach X Minuten auf.

Folgendes wird in dem Moment geloggt:

[ 99.416272] NVRM: Xid (PCI:0000:01:00): 120, pid=9740, name=nvidia-smi, GSP task panic: unknown error (0) @ pc:0x1001b70, aux:0x0, partition:2#0, task:1[ 99.426301] NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)

Protokolle:

[ 2049.814717] NVRM: _threadNodeCheckTimeout: _threadNodeCheckTimeout: Timeout was set to: 4000 msecs![ 2053.814682] NVRM: _threadNodeCheckTimeout: _threadNodeCheckTimeout: currentTime: 3d0a98547af100 >= 3d0a98547af100[ 2053.814686] NVRM: _threadNodeCheckTimeout: _threadNodeCheckTimeout: Timeout was set to: 4000 msecs![ 2053.814690] NVRM: kflcnWaitForHalt_TU102: Timeout waiting for Falcon to halt[ 2053.814693] NVRM: s_executeBooterUcode_TU102: failed to execute Booter: status 0x65, mailbox 0xff[ 2053.814694] NVRM: kgspExecuteBooterUnloadIfNeeded_TU102: failed to execute Booter Unload: 0x65[ 2053.814735] NVRM: nvAssertFailedNoLog: Assertion failed: rmStatus == NV_OK @ osinit.c:2172[ 2125.562385] NVRM: _kgspBootGspRm: unexpected WPR2 already up, cannot proceed with booting GSP[ 2125.562640] NVRM: _kgspBootGspRm: (the GPU is likely in a bad state and may need to be reset)[ 2125.562867] NVRM: RmInitAdapter: Cannot initialize GSP firmware RM[ 2125.564605] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x62:0x40:1859)[ 2125.566370] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0[ 2128.589506] NVRM: _kgspBootGspRm: unexpected WPR2 already up, cannot proceed with booting GSP[ 2128.589755] NVRM: _kgspBootGspRm: (the GPU is likely in a bad state and may need to be reset)[ 2128.589970] NVRM: RmInitAdapter: Cannot initialize GSP firmware RM[ 2128.592518] NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x62:0x40:1859)[ 2128.594132] NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

lspci -vv -s 01:00.001:00.0 VGA compatible controller: NVIDIA Corporation AD104GL [RTX 4000 SFF Ada Generation] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation AD104GL [RTX 4000 SFF Ada Generation] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 150 IOMMU group: 17 Region 0: Memory at fb000000 (32-bit, non-prefetchable) [sizee = 16M] Region 1: Memory at ffe0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at fff0000000 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at f000 seise = 7 Expansion ROM at fc000000 [virtual] [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [78] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+ RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <4us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 16GT/s, Width x4 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp+ 10BitTagReq+ OBFF Via message, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS- LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [250 v1] Latency Tolerance Reporting Max snoop latency: 34326183936ns Max no snoop latency: 34326183936ns Capabilities: [258 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2- ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=255us PortTPowerOnTime=10us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us L1SubCtl2: T_PwrOn=10us Capabilities: [128 v1] Power Budgeting <?> Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Capabilities: [900 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: LaneErr at lane: 1 2 3 Capabilities: [bb0 v1] Physical Resizable BAR BAR 0: current size: 16MB, supported: 16MB BAR 1: current size: 256MB, supported: 64MB 128MB 256MB 512MB 1GB 2GB 4GB 8GB 16GB 32GB BAR 3: current size: 32MB, supported: 32MB Capabilities: [c1c v1] Physical Layer 16.0 GT/s <?> Capabilities: [d00 v1] Lane Margining at the Receiver <?> Capabilities: [e00 v1] Data Link Feature <?> Kernel driver in use: nvidia Kernel modules: nouveau, nvidia_drm, nvidia

Zudem läuft die Karte durchgehend im P0 Power State und zieht daher 25W, sobald ich "nvidia-smi -pl 65" nutze geht der Verbrauch auf 5W runter und zumindest der Verbrauch bleibt niedrig. Die Abstürze bleiben jedoch, auch z. B. mit 35W TDP, daher kann die Stromversorgung als Fehlerquelle ausgeschlossen werden.


Ich habe zwecks Debugging mal die GPU in eine Ubuntu VM durchgeschliffen (Passthrough), da läuft alles "halbwegs", jedoch brechen Benchmarks nach wenigen Sekunden ab und der GSP Fehler erscheint erneut. Ubuntu nutzt den neusten 595 Open-Source Treiber.

Jetzt der lustige Teil: Mit dem 580 Closed-Source Treiber läuft auf der Ubuntu VM alles einwandfrei, mehrere Superposition Benchmark Durchläufe stellen kein Problem dar.


Meine Vermutung: Treiber und/oder Riser Kabel?

 

[Tornhoof]

Treiber wäre auch mein Tipp, ggf. dein Pass-Through weiter nutzen, kann aber auch Kernel Version sein, TrueNAS nutzt ja auch LTS versionen.

 

[chr1zZo]

• GPU recovery action changed ... to GPU Reset Required – die GPU verlangt einen Reset.
• WPR2 already up, cannot proceed with booting GSP – der Write-Protected-Region-2-Speicher der vorherigen GSP-Instanz ist noch belegt, deshalb scheitert jeder erneute Init-Versuch.

# Treiber entladen
sudo systemctl stop nvidia-persistenced # falls aktiv
sudo rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
# Funktions-Level-Reset
echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/reset
# Treiber neu laden
sudo modprobe nvidia
nvidia-smi


LnkSta: Speed 16GT/s, Width x4 (downgraded)
LaneErr at lane: 1 2 3

sudo lspci -vv -s 01:00.0 | grep -E "LnkSta:|LaneErr"


Wenn das wiederkehrt:

• GSP-Hänger korrelieren manchmal mit instabilem PCIe-Link (siehe oben) oder Treiber-/Firmware-Mismatch. Treiberversion prüfen: nvidia-smi --query-gpu=driver_version --format=csv.
• nouveau ist noch als Modul gelistet – stelle sicher, dass es geblacklistet ist, sonst kann es zu Konflikten kommen.
• Persistence-Mode (nvidia-smi -pm 1) kann helfen, GSP-Reinit-Zyklen zu reduzieren.

 

[AAS]

Der Kernel-Log zeigt eine „GSP task panic“ (Xid 120/154). Bei neueren Nvidia-Architekturen übernimmt die GPU-Firmware (GSP) über das Betriebssystem hinweg viele Management-Aufgaben. Wenn der PCIe-Link instabil wird, stürzt die GSP-Firmware ab, blockiert den Schreibschutzspeicher (WPR2) und reisst das gesamte Subsystem mit.

Da hast du den Fehler:

LnkSta: Speed 16GT/s, Width x4 (downgraded)
LaneErr at lane: 1 2 3

Es handelt sich um ein physikalisches Signal-Integritätsproblem. Der Chipsatz-Slot muss die Signale über Leiterbahnen quer durch das Mainboard und anschliessend durch das Riser-Kabel schicken. Bei PCIe 4.0 (16GT/s) reicht die Dämpfung aus, um bit-Fehler auf den Lanes 1, 2 und 3 zu erzeugen, was den Treiber abstürzen lässt.

Tipp:
Check die Kontakte des Riser Kabels ob diese korrodiert sind.

 

[Der_Dicke82]

Qualität vom riserkabel würde ich als erstes im Verdacht haben! Ist es ein ordentliches x16 im offenen x4 slot? Oder ist es nur ein x4 kabel.

Meine Erfahrungen mit x1 und x4 Kabeln an GPUs ist sehr sehr schlecht! Entweder erkennt das Systeme die GPU gar nicht, oder es kommt zu Abstürzen.
Ich bin mir auch nicht sicher wieviel Power ein x4 Slot liefern kann, das kann auf je Mainboard unterschiedlich sein.

Also auf jeden Fall ein hochwertiges und möglichst kurzes Riserkabel benutzen, eventuell mit extra Stromversorgung.