Random Graphical Issues with Fedora Workstation 41

Ask Fedora
, ,
1

Hi everyone,
In the past two days, I’ve been experiencing some strange graphical issues.

The first issue that occurred was randomly while I was working, the workspace on my secondary screen became extremely laggy and slow to respond to input. Strangely, everything was fine on the primary screen. As I further tested the problem, everything started flashing and the screen went partially pink. I was worried there was a fault with my graphics card, so I booted into Windows and found no problems with the card there. I booted back into Fedora and had no issues for the rest of the day.

I suspended the system for some hours, then when I came back and woke the system, both monitors were white with glitched colours across (I have attached a photo of this).

Screenshot From 2025-07-17 18-22-12
Screenshot From 2025-07-17 18-22-12679×508 247 KB

Screenshot From 2025-07-17 18-21-56
Screenshot From 2025-07-17 18-21-561187×682 572 KB

I’ve been running Fedora 41 for many months now (and earlier versions of Fedora for probably 2 years on this system) and haven’t changed anything about the system or graphics drivers in some time.

My GPU is NVIDIA GTX 1050 TI using nouveau drivers. I wouldn’t think it relevant, but my secondary monitor is using HDMI and the primary uses VGA.

Here is the log from when I woke the system up, note I’ve removed many repeated lines

 5:30:19 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 6 [00ff88f000 gnome-shell[2337]]
 5:30:19 PM kernel: nouveau 0000:01:00.0: gr: SHADER a204020e, sph: 0x04020e, stage: 0x22
 5:30:19 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 6 [00ff88f000 gnome-shell[2337]]
 5:30:19 PM kernel: nouveau 0000:01:00.0: gr: SHADER a204020e, sph: 0x04020e, stage: 0x22
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 6 [00ff88f000 gnome-shell[2337]]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: SHADER a204020e, sph: 0x04020e, stage: 0x22
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 6 [00ff88f000 gnome-shell[2337]]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000000 [] warp 3c0009 [ILLEGAL_INSTR_ENCODING]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: SHADER a204020e, sph: 0x04020e, stage: 0x22
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 4 [00ff9bd000 Xwayland[15897]]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: SHADER a204020e, sph: 0x04020e, stage: 0x22
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 4 [00ff9bd000 Xwayland[15897]]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: GPC1/TPC1/MP trap: global 00000000 [] warp 3f0009 [ILLEGAL_INSTR_ENCODING]
 5:29:36 PM kernel: nouveau 0000:01:00.0: gr: TRAP ch 4 [00ff9bd000 Xwayland[15897]]
 5:29:36 PM kernel: [TTM] Buffer eviction failed

There was also something in the log from the first incident:

(repeats until I shut the system down)
Jul 16  9:08:10 PM kernel: nouveau 0000:01:00.0: drm: base-1: timeout
Jul 16  9:08:08 PM kernel: nouveau 0000:01:00.0: drm: base-1: timeout
Jul 16  9:08:06 PM kernel: nouveau 0000:01:00.0: drm: base-1: timeout
Jul 16  9:08:04 PM kernel: nouveau 0000:01:00.0: drm: base-1: timeout
Jul 16  9:08:02 PM kernel: nouveau 0000:01:00.0: drm: core notifier timeout

Has anyone experienced issues like this recently?
Thanks in advance for any advice or insight into this problem.

2

Hi and welcome to :fedora: !

Did your issues arise with kernel 6.15 by any chance? If so, please note that a new NVIDIA open driver has been introduced, called nova_core, which could be the culprit.

You can try blacklisting it in the kernel arguments:

sudo grubby --args "rd.driver.blacklist=nova_core modprobe.blacklist=nova_core" --update-kernel=0

Note that I suggested to only updated the GRUB boot entry for the latest kernel, as to be able to revert to a previous boot entry, in case of issues.

Reboot into the latest kernel and test the changes. If this solves your issue, you could then run the following command, in order to have the args added to the GRUB_CMDLINE_LINUX variable, and to any future boot entries:

sudo grubby --args "rd.driver.blacklist=nova_core modprobe.blacklist=nova_core" --update-kernel=ALL
3

Not necessarily needed.

Grubby modifies the /boot/default/grub file when run adding or removing kernel args. IME it always does the necessary changes, though I usually use the update-kernel=ALL option and it may be different with updating a specific kernel.

A simpler way to test the kernel args is to (from the grub menu) edit the kernel command line option during boot which only applies to that one boot session. Using grubby makes the change permanent on the disk.

4

Indeed, grubby --args updates /boot/default/grub, but only with the update-kernel=ALL flag, while it doesn’t when only updating a specific kernel.

Granted, I could have suggested the easier way of editing the boot command line:

:+1:

1 Like