Actually, to clarify, the system doesn’t completely lock up. For example, when I am hanging out with my friends on voice chat, my screen goes completely black, but they can still hear my voice. Furthermore, I can still hear game, program, and system sounds in the background perfectly fine.
In scenario #1, or scenario #2?
In scenario #1
OK, so sounds like what I said was correct:
Are you still seeing this scenario even after updating the drivers? Or do you now have only scenario #2 (complete crash under heavy GPU load)?
Hi again, and thank you for helping me narrow this down.
To answer your question and give you the full picture, even after updating to the 595.80 driver, the exact same behavior persists. I am definitely experiencing the scenario where the display is lost, but the system is still running.
Here are the exact symptoms structured for clarity:
- The System Doesn’t Completely Lock Up:
When the black screen happens, my PC is actually still alive. If I am in a voice call, my friends can still hear me, and I can hear them. I can also hear game and system sounds perfectly fine in the background. It is strictly a total display loss.
- Specific Triggers (Shaders and Lighting):
The crash isn’t strictly caused by raw “heavy GPU stress.” It specifically triggers when the GPU has to process lighting effects, shaders, or certain 3D models. For example, playing vanilla Minecraft works perfectly, but the moment I enable shaders, the screen goes black. I never had this issue on Windows.
- Web Browsing Crashes:
I also realized another crucial detail: this exact same display loss sometimes happens even when I am just doing basic web browsing.
- FurMark Inconsistency:
As for FurMark, its behavior is inconsistent. Sometimes the stress test runs completely fine without any issues, while other times it completely fails to start and crashes the display right away.
Given that it happens during basic web browsing and specific shader tasks while the system remains responsive in the background, could this be related to a Wayland/X11 conflict, or perhaps a hardware acceleration issue with the driver, rather than a thermal/power failure?
I’m not sure what “Wayland/X11 conflict” means exactly. But yes it’s plausible this is a bug in the driver, or in the way the compositor (kwin-wayland) interacts with the driver.
That said, in that case we’d expect more users to be reporting it.
Can you see anything relevant being logged in this scenario? (As opposed to scenario #2, where you said the system crashes so hard that nothing gets logged.)
If i read the inxi correctly i would test this using example other display cable and port to start the debug and minimize cabel or port failure.
For me if nothing shows on logs yet see if you have hardware failures and issues. Does the power cable connected correctly just manual test and verify and if all those are correct and example power suplly is all good etc you are ready to go more deeper on logs to find the root cause
Actually, here is a crucial detail I should mention: I usually force shut down the PC the exact moment the screen goes black. If I were to wait a little longer before resetting, I am sure the system would actually have time to write the errors to the logs.
Regarding the hardware/cables: Everything is plugged in correctly, and I never had this issue on Windows, so I am pretty confident the PSU and cables are fine.
Also, I have a question about the OS version itself. Since Fedora 44 is quite new, could this be a bleeding-edge compatibility bug? Would it make sense for me to just downgrade to the previous release to see if a more mature/stable environment resolves this Wayland/NVIDIA conflict?
I’m disappointed that I’ve spent time trying to help you based on inaccurate statements.
You said:
there are absolutely no errors recorded right before the crash. The system locks up so instantly that it can’t even write the failure to the disk.
When you say, “The system locks up so instantly”, it gives no hint that you are forcibly powering it down yourself!
Possible, but as said earlier, if that was the case we’d probably have seen more reports of this.
You are absolutely right to be frustrated, and I sincerely apologize. It was a total panic reflex on my part to just force shut down the moment the screen went black, and I didn’t realize how much it messed up the diagnostic process. I am really sorry for inadvertently sending you down the wrong path and wasting your time.
To make it right, I will trigger the crash again right now (using Minecraft shaders), but this time I will leave the PC running for a few minutes so the kernel has plenty of time to write the actual errors to the log. I will post the real journalctl logs shortly. Thank you for your patience with me!
This should NEVER be an action taken unless there is absolutely no other alternative. Doing so can quickly cause file system errors and other problems that become difficult to track down.
At the very least a few minutes should elapse to allow the system to stabilize before forcing down
.',;::::;,'. anilcemresacak@fedora
.';:cccccccccccc:;,. ---------------------
.;cccccccccccccccccccccc;. OS: Fedora Linux 44 (KDE Plasma Deskt4
.:cccccccccccccccccccccccccc:. Kernel: Linux 7.0.14-201.fc44.x86_64
.;ccccccccccccc;.:dddl:.;ccccccc;. Uptime: 1 hour, 44 mins
.:ccccccccccccc;OWMKOOXMWd;ccccccc:. Packages: 50 (flatpak), 2851 (rpm)
.:ccccccccccccc;KMMc;cc;xMMc;ccccccc:. Shell: bash 5.3.9
,cccccccccccccc;MMM.;cc;;WW:;cccccccc, Display (LS24AG32x): 1920x1080 in 24"]
:cccccccccccccc;MMM.;cccccccccccccccc: DE: KDE Plasma 6.7.1
:ccccccc;oxOOOo;MMM000k.;cccccccccccc: WM: KWin (Wayland)
cccccc;0MMKxdd:;MMMkddc.;cccccccccccc; WM Theme: Utterly-Round-Dark-Solid
ccccc;XMO';cccc;MMM.;cccccccccccccccc' Theme: Breeze (Light) [Qt], Breeze-Da]
ccccc;MMo;ccccc;MMW.;ccccccccccccccc; Icons: Papirus [Qt], Papirus [GTK2/3/]
ccccc;0MNc.ccc.xMMd;ccccccccccccccc; Font: Noto Sans (10pt) [Qt], Noto San]
cccccc;dNMWXXXWM0:;cccccccccccccc:, Cursor: material_light (24px)
cccccccc;.:odl:.;cccccccccccccc:,. Terminal: /dev/pts/2
ccccccccccccccccccccccccccccc:'. CPU: AMD Ryzen 5 5600 (12) @ 4.47 GHz
:ccccccccccccccccccccccc:;,.. GPU: NVIDIA GeForce RTX 3060 Ti Lite ]
':cccccccccccccccc::;,. Memory: 4.89 GiB / 31.24 GiB (16%)
Swap: 0 B / 8.00 GiB (0%)
Disk (/): 103.20 GiB / 463.17 GiB (22s
Local IP (enp6s0): 192.168.1.134/24
Locale: en_US.UTF-8
anilcemresacak@fedora:~$ journalctl -b -1 | gep -i xid
bash: gep: command not found...
anilcemresacak@fedora:~$ journalctl -b -1 | grep -i xid
Jul 04 20:17:44 fedora kernel: r8169 0000:06:00.0 eth0: RTL8125B, f0:2f:74:f6:85:c2, XID 641, IRQ 73
anilcemresacak@fedora:~$ journalctl -b | grep -i xid
Jul 04 20:19:36 fedora kernel: r8169 0000:06:00.0 eth0: RTL8125B, f0:2f:74:f6:85:c2, XID 641, IRQ 73
Jul 04 22:13:01 fedora kernel: NVRM: Xid (PCI:0000:07:00): 79, GPU has fallen off the bus.
Jul 04 22:13:01 fedora kernel: NVRM: Xid (PCI:0000:07:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
anilcemresacak@fedora:~$ journalctl -b -1 --no-pager | grep -B 5 -A 5 -i xid
Jul 04 20:17:44 fedora kernel: kvm_amd: Virtual GIF supported
Jul 04 20:17:44 fedora kernel: usbcore: registered new interface driver btusb
Jul 04 20:17:44 fedora kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database
Jul 04 20:17:44 fedora kernel: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
Jul 04 20:17:44 fedora kernel: Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
Jul 04 20:17:44 fedora kernel: r8169 0000:06:00.0 eth0: RTL8125B, f0:2f:74:f6:85:c2, XID 641, IRQ 73
Jul 04 20:17:44 fedora kernel: r8169 0000:06:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]
Jul 04 20:17:44 fedora systemd-vconsole-setup[741]: All allocated virtual consoles are busy, will not configure key mapping and font.
Jul 04 20:17:44 fedora systemd[1]: Finished systemd-vconsole-setup.service - Virtual Console Setup.
Jul 04 20:17:44 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 04 20:17:44 fedora kernel: audit: type=1130 audit(1783185464.436:31): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
anilcemresacak@fedora:~$ nvidia-smi --query-gpu=driver_version,name,power.draw,power.limit.temperature.gpu --format=csv
Field "power.limit.temperature.gpu" is not a valid field to query.
anilcemresacak@fedora:~$ nvidia-smi
Unable to determine the device handle for GPU0: 0000:07:00.0: Unknown Error
No devices were found
anilcemresacak@fedora:~$ nvidia-smi --query-gpu=driver_version,name,power.draw,power.limit,temperature.gpu --format_csv
ERROR: Option --format_csv is not recognized. Please run 'nvidia-smi -h' for help.
anilcemresacak@fedora:~$ sudo reboot
Update for everyone following this thread — I managed to catch it properly this time.
Instead of hard-resetting the moment the screen went black, I SSH’d in from another machine on the same network while the system was still “black.” Audio kept playing and the machine was fully responsive over SSH — only the video output was dead. That let me pull the actual kernel log instead of losing it to a hard reset.
Here’s what showed up in journalctl -b | grep -i xid:
NVRM: Xid (PCI:0000:07:00): 79, GPU has fallen off the bus.
NVRM: Xid (PCI:0000:07:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (GPU Reset Required)
And right after that, nvidia-smi couldn’t even see the card anymore:
Unable to determine the device handle for GPU0: 0000:07:00.0: Unknown Error
No devices were found
So this isn’t a simple driver/compositor bug — Xid 79 (“GPU has fallen off the bus”) means the OS lost communication with the card over the PCIe bus entirely. That generally points to something physical/electrical rather than a Fedora- or KDE-specific software issue: a loose PCIe power connector, a card not fully seated in the slot, a marginal PSU under transient load spikes, riser cable issues (if anyone’s using one), or in rarer cases a failing card itself.
Setup for reference: Fedora 44, kernel 7.0.14-201.fc44, KDE Plasma 6.7.1 on Wayland, NVIDIA driver 595.80 (open kernel module), RTX 3060 Ti, Ryzen 5 5600.
Posting this in case anyone else hitting similar random full-display-loss issues wants to check for the same Xid code before assuming it’s a Fedora/driver regression — this looks hardware/connection related in my case, not something a reinstall or distro switch would fix. Will report back once I’ve reseated the card and checked the PSU/cabling.
Hello again everyone,
I want to sincerely thank everyone who followed this thread and took the time to help me. I’m glad to share that this long-running issue has finally been resolved.
First, I’d like to apologize for some of the misleading information I gave earlier in this process. Being new to Linux, when I first experienced the issue, I panicked and immediately hard-reset the system, which led me to report that “the system freezes instantly and doesn’t even log the error.” In reality, the system kept running fine in the background — only the display output was dying. Not recognizing this early on caused the thread to run longer than it needed to, and I apologize for that.
Thanks to the guidance here, I learned to SSH into the machine while the screen was black and pull the actual kernel logs, which revealed the real cause: Xid 79 - GPU has fallen off the bus. This confirmed the issue had nothing to do with the driver or the OS — it was purely hardware-related.
Here’s how I fixed it:
I removed the graphics card, gently cleaned the PCIe gold contacts with a soft eraser, and reseated it. I also did a general maintenance pass on the system — dust cleaning and reapplying CPU thermal paste. After that, I stress-tested extensively with FurMark, shader benchmarks, and real gaming sessions (War Thunder, shader-heavy Minecraft), and the issue has completely disappeared since.
As someone new to Linux, this whole experience taught me a lot — especially that properly diagnosing an issue takes patience and gathering the right data before jumping to conclusions. I wouldn’t have gotten here without everyone’s help.
Thank you all again, and take care.