Bug Report & Fix: RTX 5090 — Xid 79 GSP Firmware Crash Under Sustained CUDA Load

Graphics / Linux Linux
1

This post may help show/indicate where a bug/compatibility issue is being introduced that causes “Xid 79 GSP Firmware Crash Under Sustained” (at least in my case). Perhaps Nvidia may wish to look at what I found.

Summary

RTX 5090 crashes with Xid 79 “GPU has fallen off the bus” under sustained CUDA load after a motherboard BIOS update that introduced AGESA PI-1.3.0.0. Downgrading to a BIOS version using AGESA 1.2.0.3f restored full stability as I have had for months. No hardware changes were made between the working and broken states.

NOTE: There are other changes between the 4x versions of the bios I went from > to. These should also be considered as possibilities. Link to the bios’s and their listed changes are below.

System Information

Component Detail
GPU NVIDIA GeForce RTX 5090 (Gigabyte, PCI: 0000:01:00.0)
Motherboard MSI PRO X870-P WIFI (MS-7E47)
CPU AMD (AM5 socket, X870 chipset)
OS Ubuntu 24.04 LTS
Kernel 6.17.0-23-generic
Driver tested 595.58.03 (both open and proprietary variants)
Display server Tested on both Wayland and X11 — crash occurs on both
Workload ComfyUI AI video generation (sustained CUDA compute)

BIOS Versions

BIOS Version AGESA Version Stable?
MSI 1A76 (Aug 2025) AGESA PI 1.2.0.3f ✅ Stable
MSI 1A82 (Mar 2026) AGESA PI 1.3.0.0 ❌ Crashes

BIOS settings were identical between versions — a saved BIOS profile from the working configuration was loaded after downgrading, confirming the issue is most likely the AGESA version/bios version itself and not a settings change. This bios upgrade was 4x revisions newer with only a few changes between them

I have not tested the intermediate bios version 7E47v1A77, 7E47v1A7B or 7E47v1A80 so all changes in those bios’s also need to be taken into account.

https://www.msi.com/Motherboard/PRO-X870-P-WIFI/support

BIOS Change
A77 AGESA PI 1.2.0.3g updated. Improved Ryzen 8000 series CPU compatibility
A7B AGESA PI pre-1.3.0.0 updated
A80 AGESA PI pre-1.3.0.0 updated. Added “BIOS UEFI/CSM Mode” option
A82 AGESA PI-1.3.0.0. Anti-cheat mechanism. Improved PCIe-based device compatibility. Optimised OC for Ryzen 9 9950X3D2

Crash Behaviour

  • System runs 1-2 generations of ComfyUI without issue

  • Crash occurs reliably at generation 2-3 under sustained near-TDP load (~595W)

  • Screen goes blank, GPU fans ramp to 100% and stay there

  • System is unrecoverable without a hard reboot (Alt+SysRq+REISUB)

  • GPU temperature at time of crash: 70-72°C (well within safe range)

  • PCIe link confirmed healthy: Gen 5 x16 under load

Kernel Logs at Crash

The following errors appear in journalctl -b -1 immediately before the crash:

NVRM: Xid (PCI:0000:01:00): 79, pid=829, name=nvidia-modeset/, GPU has fallen off the bus.
NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.
NVRM: GPU0 krcRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
NVRM: GPU0 _kgspIsHeartbeatTimedOut: Heartbeat timed out
NVRM: GPU0 _kgspRpcRecvPoll: GSP RM heartbeat timed out
NVRM: GPU0 _kgspRpcRecvPoll: LibOS heartbeat timed out
NVRM: GPU0 tmrGetTimeEx_GH100: NVRM-RC: Consistently Bad TimeLo value ffffffff
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)
NVRM: nvGpuOpsReportFatalError: uvm encountered global fatal error 0x60, requiring os reboot to recover.
NVRM: GPU0 nvCheckOkFailedNoLog: Check failed: GPU lost from the bus [NV_ERR_GPU_IS_LOST]

Diagnosis

The crash is a GSP firmware heartbeat timeout (Xid 79) causing the GPU to disappear from the PCIe bus entirely. The timer register reads back 0xffffffff indicating the GPU hardware is completely unresponsive at the point of crash.

Based on testing, the root cause appears to be an incompatibility between AGESA PI 1.3.0.0 (introduced in MSI BIOS 1A82) and Blackwell’s GSP firmware under sustained high-power CUDA workloads on Linux. The issue is consistent with other Blackwell GSP crash reports on the Nvidia developer forums, but this specific reproduction case most likely isolates the AGESA version as the trigger. I guess MSU could have made other changes within the bios that I cant ask them about.

Nvidia may wish to look at all possible changes between the BIOS versions I link to above.

Steps to Reproduce

  1. MSI PRO X870-P WIFI with BIOS 1A82 (AGESA PI-1.3.0.0)

  2. RTX 5090, Ubuntu 24.04, kernel 6.17, driver 595.58.03

  3. Run ComfyUI with a batch of 3 long consecutive AI generations

  4. Crash occurs reliably at generation 2-3

Resolution

Downgrading BIOS to MSI 1A76 (AGESA PI 1.2.0.3f) and restoring the saved BIOS profile restored full stability. Multiple consecutive generation batches complete without issue.

I have not tested the intermediate bios version 7E47v1A77, 7E47v1A7B or 7E47v1A80 so all changes in those bios’s also need to be taken into account.

Additional Notes

2

Seeing an identical issue with vLLM and long inference jobs. Haven’t tried downgrading AGESA/BIOS because ASRock boards are famous for blowing up 9800X3Ds.

Issue does not seem to be power/thermal related, I have plenty of headroom on both.

Component Detail
GPU NVIDIA GeForce RTX 5090 (PCI 0000:01:00.0, VBIOS 98.02.2E.00.E4)
Motherboard ASRock X870 Steel Legend WiFi
CPU AMD Ryzen 7 9800X3D (8-core, AM5)
Chipset AMD X870
OS Arch Linux
Kernel 7.0.9-arch1-1
NVIDIA driver 595.71.05 (NVIDIA Open Kernel Module, x86_64)
Display server KDE (Wayland)
Workload vLLM 0.21.0 serving sakamakismile/Qwen3.6-27B-Text-NVFP4-MTP (Qwen3.6 27B NVFP4 + MTP draft speculative decoding), continuous single-stream inference at 195k input + 2048 output tokens, fp8 KV cache, CUDA graphs enabled, gpu-memory-utilization=0.92.

Kernel Logs at Crash

NVRM: GPU at PCI:0000:01:00: GPU-beafa3e5-0d05-0524-6c63-e3698b624fbd
NVRM: Xid (PCI:0000:01:00): 79, pid=12625, name=btop, GPU has fallen off the bus.
NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.
NVRM: GPU0 krcRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79.
NVRM: GPU0 _kgspIsHeartbeatTimedOut: Heartbeat timed out, currentTimeMs 0 heartbeat 4294967295
                                     heartbeatWithOffsetMs 890989791 diff 3403977505 timeout 5200
NVRM: GPU0 _kgspRpcRecvPoll: GSP RM heartbeat timed out
NVRM: GPU0 _kgspRpcRecvPoll: LibOS heartbeat timed out
NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)
NVRM: GPU0 _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 78
NVRM: GPU0 nvCheckOkFailedNoLog: Check failed: GPU lost from the bus [NV_ERR_GPU_IS_LOST]
NVRM: GPU0 nvAssertFailedNoLog: Assertion failed: (status == NV_OK) || (status == NV_ERR_GPU_IN_FULLCHIP_RESET)
NVRM: GPU0 kgmmuFaultBufferReplayableDestroy_IMPL: Unregistering Replayable Fault buffer failed (status=0x0000000f), proceeding...
NVRM: GPU0 uvmTerminateAccessCntrBuffer_IMPL: Unloading UVM Access counters failed (status=0x0000000f), proceeding...
NVRM: _issueRpcLarge: rpcSendMessage failed with status 0x0000000f for fn 76!
3

Adding one data point because the final symptom looks very similar, although my root cause appears to be different.

My setup:

  • RTX 5090 AORUS MASTER ICE on CPU PEG, PCIe Gen5 x16

  • RTX 4060 Ti on chipset/DMI, PCIe Gen4 x4

  • Gigabyte Z790 AORUS MASTER X, BIOS F19a

  • Intel i9-13900KS

  • Windows 11

  • NVIDIA Studio driver 596.36

In my case the failure initially looked like a GSP/PSU/RMA-type issue as well: CUDA error: unknown / GPU lost, plus Windows nvlddmkm Event ID 14/153. The low-level errors were:

  • PCIE P2PREQ, Uncorrectable SRAM Error

  • PCIE REORDER, Uncorrectable SRAM Error

  • followed by GpuRcReset TDR

There was no full system power-off, no BSOD, and no Kernel-Power 41 event — only an internal GPU reset/TDR.

After controlled testing, the 5090 itself appears stable in my system. I was able to run several long single-GPU training runs at PCIe Gen5 x16, 600 W power limit, full CPU load, with no ECC/TDR events and no power instability.

The crash became reproducible only when a real cross-GPU/offload path was involved. In my case, ComfyUI MultiGPU / DisTorch2 offload to the second GPU reproduced the same “CUDA unknown error → GPU lost” behavior. Disabling the second GPU in Windows Device Manager made the 5090 training stable again.

So my current conclusion is that my issue is not the same as a pure BIOS/GSP sustained-load crash. It appears to be a fragile cross-GPU PCIe/P2P/topology path: 5090 on CPU PEG ↔ second GPU behind chipset/DMI.

I am posting this because the end symptom can look very similar to Xid 79 / “GPU fell off the bus” / GSP timeout cases, but the trigger may be different. It may be useful to separate at least these classes:

  1. BIOS/GSP sustained-load crashes

  2. PSU/transient or cabling issues

  3. PCIe Gen5/signal-integrity issues

  4. Cross-GPU PCIe/P2P/topology issues

One detail that mattered in my case: CUDA_VISIBLE_DEVICES=0 is not the same as disabling the second GPU. It only hides the device from the CUDA application; the OS/NVIDIA driver still has the second GPU enumerated and the platform multi-GPU topology still exists.

So if someone has a similar “GPU lost” symptom but also has a second GPU installed, it may be worth testing with the second GPU disabled at the device level or physically removed, not only masked via CUDA_VISIBLE_DEVICES.

4

Adding a related data point because the final symptom looks very similar, although my trigger appears to be different.

My setup:

  • RTX 5090 AORUS MASTER ICE on CPU PEG, PCIe Gen5 x16

  • RTX 4060 Ti on chipset/DMI, PCIe Gen4 x4

  • Gigabyte Z790 AORUS MASTER X, BIOS F19a

  • Intel i9-13900KS

  • Windows 11

  • NVIDIA Studio driver 596.36

In my case the failure initially looked like a GSP/PSU/RMA-type issue as well: CUDA error: unknown / GPU lost, with Windows nvlddmkm Event ID 14/153.

The low-level errors were:

  • PCIE P2PREQ, Uncorrectable SRAM Error

  • PCIE REORDER, Uncorrectable SRAM Error

  • followed by GpuRcReset TDR

There was no full system power-off, no BSOD, and no Kernel-Power 41 event — only an internal GPU reset/TDR.

After controlled testing, the RTX 5090 itself appears stable in my system. I was able to run several long single-GPU training runs at PCIe Gen5 x16, 600 W power limit, full CPU load, with no ECC/TDR events and no power instability.

The crash became reproducible only when a real cross-GPU/offload path was involved. In my case, ComfyUI MultiGPU / DisTorch2 offload to the second GPU reproduced the same “CUDA unknown error → GPU lost” behavior. Disabling the second GPU in Windows Device Manager made the 5090 training stable again.

So my current conclusion is that my case is probably not the same as a pure BIOS/GSP sustained-load crash. It appears to be a fragile cross-GPU PCIe/P2P/topology path: 5090 on CPU PEG ↔ second GPU behind chipset/DMI.

I am posting this because the end symptom can look very similar to Xid 79 / “GPU fell off the bus” / GSP timeout cases, but the trigger may be different. It may be useful to separate at least these classes:

  1. BIOS/GSP sustained-load crashes

  2. PSU/transient or cabling issues

  3. PCIe Gen5/signal-integrity issues

  4. Cross-GPU PCIe/P2P/topology issues

One detail that mattered in my case: CUDA_VISIBLE_DEVICES=0 is not the same as disabling the second GPU. It only hides the device from the CUDA application; the OS/NVIDIA driver still has the second GPU enumerated and the platform multi-GPU topology still exists.

So if someone has a similar “GPU lost” symptom but also has a second GPU installed, it may be worth testing with the second GPU disabled at the device level or physically removed, not only masked via CUDA_VISIBLE_DEVICES.

5

Update: Crash Appears Thermal in Nature — Full Testing Summary

I wanted to update this thread with my findings after extensive testing over several weeks. I owe the community a detailed account of everything I tried, as I believe others may be experiencing the same issue and could benefit from this information.

TLDR Summary

After ruling out virtually every software variable, the crashes appear to have been caused by inadequate case airflow leading to thermal stress on one or more components. The exact failure point remains uncertain, candidates include a hotspot on the RTX 5090 itself (GDDR7 memory junction, VRM, or PCIe controller chip) that Linux cannot report, general motherboard thermal stress, or CPU thermal throttling affecting PCIe stability.

The CPU throttling theory is worth highlighting: the AMD Ryzen’s memory controller is integrated into the CPU die and handles all PCIe traffic between system RAM and the GPU. During sustained AI video generation, WanVideoWrapper repeatedly transfers large model weights between RAM and VRAM. If the CPU/memory controller area heats sufficiently to throttle, PCIe transaction timing could be affected, causing the GPU to lose bus communication entirely and manifesting as Xid 79. This would explain why the GPU core temperature (70-72°C) was always within spec, why crashes only occurred under sustained repeated load, and why improving case airflow resolved the issue.

Adopting a significantly more aggressive fan profile resolved the crashes. I can now run 10+ consecutive generations across 7+ sessions without issue (albeit with noisier fans).

Important caveat: I cannot definitively identify the exact component overheating as several critical temperature sensors are inaccessible on Linux. It is also possible that a software change in early May contributed by altering power or thermal behaviour, making a previously marginal thermal situation critical. All software changes listed below have been reverted — the only remaining change is the fan profile.

System Information

Component Detail
GPU NVIDIA GeForce RTX 5090 (Gigabyte, PCI: 0000:01:00.0)
Motherboard MSI PRO X870-P WIFI (MS-7E47)
CPU AMD Ryzen 7 9700X (AM5, X870 chipset)
OS Ubuntu 24.04 LTS

Complete List of Individual Variables Tested one by one (All Reverted Except Fan Profile)

Display Server

  • Tested on Wayland

  • Tested on X11

  • Result: Crash occurs on both — display server is irrelevant

Nvidia Driver Versions

  • nvidia-driver-595-open (open kernel module)

  • nvidia-driver-595 (proprietary)

  • nvidia-driver-580

  • Result: Crashes on all driver versions

Linux Kernel Versions

  • 6.17.0-23-generic

  • 6.14.x

  • Result: Crashes on both kernel versions

BIOS Versions

  • MSI 1A82 (AGESA PI 1.3.0.0) — updated version

  • MSI 1A76 (AGESA PI 1.2.0.3f) — original version

  • MSI factory defaults

  • Result: Initially appeared BIOS was the cause (stable on A76, crashing on A82), but later testing proved crashes also occurred on A76, so BIOS was not the root cause. The AGESA version may have been a contributing factor but was not solely responsible. Perhaps this bios update also changed the fan profiles?

Kernel Parameters Tested

  • pcie_aspm=off

  • nvidia.NVreg_EnableGpuFirmware=0

  • nvidia_drm.fbdev=1

  • Result: No effect on crash frequency

GPU/Nvidia Settings

  • GPU locked to maximum performance mode via nvidia-smi

  • PowerMizer set to maximum performance

  • GPU Fans set to max performance

  • PCIe correctable errors checked — clean, no signal integrity issues

  • PCIe link speed monitored under load — confirmed Gen5 x16 throughout

  • Result: No effect

ComfyUI Launch Flags

  • --use-sage-attention vs without

  • --disable-smart-memory vs without

  • --disable-cuda-malloc

  • CUDA_LAUNCH_BLOCKING=1

  • PYTORCH_NO_CUDA_MEMORY_CACHING=1

  • Result: No effect on crashes

PyTorch/CUDA Versions

  • PyTorch 2.10.0+cu130

  • PyTorch 2.7.0+cu128

  • Result: Crashes on both versions

ComfyUI/Workflow Variations

  • Latest ComfyUI vs older known-good version

  • Updated vs older WanVideoWrapper node

  • Updated other used nodes to older/newer versions

  • bf16 model vs fp8 model

  • With LoRAs vs without LoRAs

  • Various delay nodes added between workflow steps (2-5 seconds each) This may be useful to have longer delays for general cooling, but at the time I was trying to give a bit of extra headroom for the VRAM offloads to occur.

  • Different video output formats (h264, h265, webm) as compiling the videos is heavy on CPU and increases its temp

  • Low memory LoRA loader

  • Force unload disabled

  • Block swap enabled vs disabled

  • Brave browser GPU acceleration disabled

  • Brave browser closed entirely during generation

  • Result: None of these changed crash behaviour and there was no one single consistent point where a crash would occur, other than to say it was during heavy offloads/memory transfer and generation.

Thermal/Hardware Testing

  • External Vornado fan blowing directly into open case (basically a normal fan you would use to cool yourself on a hot day and the case side panel removed) — stable with this

  • Side panel on, original fan profiles — crashes

  • Side panel on, aggressive fan profiles — stable

  • PCIe power cables physically re-seated and inspected — confirmed secure

  • Result: Thermal management was the key variable

The Thermal Discovery

A critical finding during this investigation: several important temperature sensors are completely invisible on Linux without loading the nct6683 kernel module: (specific to my motherboard)

Without this module, the following sensors do not appear:

  • AMD TSI (CPU socket/VRM area temperature)

  • Motherboard diode temperatures

  • Thermistor readings

  • Fan speed readings for all case fans

Once loaded, monitoring revealed the AMD TSI sensor reaching 76-81°C under sustained generation load with the side panel on, a temperature that was previously completely hidden.

To monitor during generation (you may need to load a motherboard specific module if your system has not detected these temp sensors). This also stores the gathered data in sensors.log:

while true; do
    echo "=== $(date) ===" | tee -a ~/sensors.log
    sensors | grep -E "Diode|Thermistor|AMD TSI|fan[0-9]" | tee -a ~/sensors.log
    nvidia-smi --query-gpu=temperature.gpu,power.draw --format=csv,noheader | tee -a ~/sensors.log
    sleep 2
done

Temperatures Still Invisible on Linux

Even with nct6683 loaded, the following remain inaccessible:

  • GDDR7 memory junction temperature (reportable on Windows, not Linux)

  • GPU back-of-PCB VRM temperatures

  • GPU PCIe controller chip temperature

  • Motherboard chipset temperature (chip ID 0xd592, unknown to lm-sensors)

Given the RTX 5090’s 600W TDP and the sustained nature of AI video generation workloads, any of these invisible sensors could be the actual thermal failure point. The AMD TSI rising to 81°C is correlated with instability, but may itself be a symptom of hot air re-circulation inside the case rather than the direct cause.

What Fixed It

Adopting a significantly more aggressive fan profile in BIOS:

  • Both top fans (AIO radiator) now respond to CPU temp, ramping hard from 55°C, reaching maximum by 70°C

  • Case intake fans set to ramp aggressively from 45°C

  • Case exhaust fans set to respond to CPU temp rather than chipset temp (chipset sensor barely moves, so fans were not responding at all previously)

  • AIO pump speed increased to fixed high speed

With these changes, AMD TSI stays around 76-79°C under sustained load (previously reaching 81°C+ before instability), and 10+ consecutive generations have completed without a crash. With the vornado fan blowing and case open the AMD TSI was running more around the 70°C area as a peak.

Remaining Questions

  1. What exactly is overheating? The GPU core temp (70-72°C) is fine. Something else, possibly GDDR7 memory junction, a PCIe controller chip, a VRM on either the GPU or motherboard, or the CPU memory controller may be the actual failure point.

  2. Did a software update in early May make this worse? The system ran stably for months before crashes started. Multiple software changes occurred around that time (driver, kernel, BIOS, ComfyUI). It is possible one of these changed power management or increased heat output enough to push a marginal thermal situation critical.

  3. Did something change my fan profiles.

I hope this detailed account helps others experiencing similar crashes investigate their own thermal situation.

6

Feedback after 7x days and hours of heavy use, I no longer suffer the issue of crashing.

The RTX 5090 is hitting very closely the same top temperature of 73 Deg C, but the chips across the motherboard are not hitting highs anymore.

My current working theory is that because the RTX5090 is so long/large and sits so close to many of the chips on the motherboard, its generally blocking airflow around the motherboard chips and potentially the CPU/Memory controller is eventually overheating from sheer thermal mass accumulation. Whatever was getting too hot, does not have a temp sensor on it, making it hard to diagnose when generally temps seemed higher but within allowable tolerances.

Having slightly more aggressive fan profiles (increasing the speed of the fans at lower temps) did resolve the issue. Adding an additional case fan below the RTX5090 that pulls in additional airflow under the 5090 (and the chips that are blocked by the size of the card) has resulted in a 100% stable system 7x days later.

As above, my initial simple testing method was to take the side of my case off and blow normal house fan at full speed a foot from the open side of the case, then test. Which showed that everything remained stable, albeit that the measured temps around the system were only 2-3 Deg C cooler on this test and still very much within the allowable thresholds.

Hope this helps someone.

7

Somehow managed to solve this. Did 3 things:

  • Software updates - Kernel 7.0.12, vLLM 0.23.0
  • Fan curve - 100% on every possible fan, PSU silent mode off
  • NVIDIA 610.43.02 drivers
8

Glad you’ve got it stable!

On the airflow point, the more I think about it, the more I suspect the gap between the motherboard and the RTX card is PROBABLY s the real culprit. These cards are enormous, they run the full length of the board and occupy three PCIe slots of height, and while the card’s own fans do a good job cooling the GPU itself, the ~1cm gap between the card and the motherboard can be a real thermal dead zone.

The RTX pulls cool air up through itself and its own temps look fine, but the motherboard components blocked by the card on the PCIe slot side; PCIe controller chips, VRMs, and other components without thermal sensors are likely sitting in stagnant warm air with nowhere for the heat to go. Over sustained workloads that thermal mass gradually builds up, and I suspect that’s what eventually causes instability rather than anything directly wrong with the GPU itself.

Adding a fan below the card to push fresh air up into that gap seems to have resolved it entirely in my case. Might be worth considering if anyone else is still struggling.

Either way, I can confirm my system remains stable to this day and runs heavy workloads without a single issue now, after improving the intake fan(s) to higher throughput ones, having a higher fan curve at medium-lower temps and I have also added a intake fan BELOW the RTX card in the hope it will push air up the gap between the card and motherboard, not just up through the RTX card.

FYI, I used Arctic P14 Pro fans which blow through 110 cubic feet of air per minute @ 2500 RPM, almost double my previous fans airflow. They arent too expensive and no more noisy than my previous fans, bar up at high speed and even then, not that bad.

My posts up above this one have details of all the testing I did and using a house fan to prove that it was/is a cooling issue. So more details in the posts up above for those whom want it.

What my system now looks like. Blue fans are the replacement (fan16) and new fan (fan14)

image
image1311×1323 87.2 KB

9

Okay, I spoke too soon. Got another crash ~50minutes into a run. Then I took the side panel off and the biggest temperature difference is the chipset. I believe this is the real culprit.

TLDR: watch your chipset temperatures

Taking the panel off dropped the PCH sensor by ~10C another 1hr heatsoak test later. I think it makes sense, 5090 on Asrock X870 overhangs the chip almost completely (see pic “enlarged chipset heatsink”).

So it was a thermal problem after all. Not sure how to solve it with panel closed tbh, I’m running in Fractal Design Torrent with all the fan slots populated and at 100%, kind of hard to imagine getting more airflow in this case. I might try taking off the PCH heatsink and replacing the thermal paste, see if the factory application sucks.

At the same time the PCH temperature might be just a “thermometer” and something else is overheating. @erew76 but you seem to be right, it’s most likely the card overheating some chip underneath it.

Big relief though that it’s not something GPU related, it would be a massive pain to go through some kind of RMA process.

image
image1092×614 107 KB

10

Not sure what fans you have. I changed my intake fans from:

  • Be Quiet Pure Wings 3 140mm fans - move 57 CFM (cubic feet per minute) of air @ 1200 RPM

    TO

  • Arctic P14 Pro 140mm fans - move 110 CFM @ 2500 RPM

And of course adding the 2nd fan (in my situation) obviously was a major jump in airflow. 30-40% additional potential air through the case.

May be worth how seeing how much air your current fans can throughput?

Either way, good luck and yeah, the “Do I need to warranty this?” thought was going through my mind too.

image
image1865×494 34.8 KB

11

I started experiencing this xid 79 problem after installing OS updates on my system, including nvidia driver updates(propietary version, not open driver).

And mine could be a particular case, but having option to boot from OS snapshot I took before installing updates, that works fine again, then this could be recent software(driver and/or linux kernel) problem in my case. This way I confirmed it’s not a hardware problem, and I just keep running the previous OS version.

12

Final update.

Its July now, over 1 month since I improved the cooling on my system and it remains solid to this day.

No more crashes or issues. For me, cooling/air flow was the issue, and as above, I suspect on the chipset of the motherboard where the RTX blocks most of the airflow.

Thanks