Display freeze on Fedora 42/43, probable cause hybrid dGPU and iGPU switching

[ricvasi]

Hello,

I'm pretty new to Linux and Fedora, so I have little experience in fixing things and I have this persistent issue, that feels unrepairable and I would really appreciate any suggestion or advice for this issue.

I have a an Asus Tuf Gaming 14 FA401UV_FA401UV laptop with these specifications:

AMD Ryzen™ 7 8845HS w/ Radeon™ 780M Graphics × 16
32 Gb of RAM
NVIDIA GeForce RTX™ 4060 Laptop GPU

On this, I try to run Fedora 43 workstation, with windowing system being Wayland and Kernel version: Linux 6.18.9-200.fc43.x86_64

What I am experiencing are sudden freezes of the screen, it happened in almost all possible situation (browsing web, browsing system files, using various applications (VSCode, Spyder, Mathematica, ...), watching videos, it happened when I was doing nothing and just had the laptop on, it is also happeing regardless of the system updates). It happened when using a second monitor, and it is happening with only the laptop screen in play. It happened with the laptop plugged in and when on battery. The freeze is always the same, the mouse stops moving and I can do nothing about it, BUT the keyboard is working, meaning when I try to turn on the Caps Lock, the light indicator does change, so I think that only the display freezed, but the system itself was working.

Also, when I am using the second monitor and the laptop screen freezes, the second monitor is working, meaning the mouse appears freezed at the laptop screen, but at the second monitor, I can use the mouse and the keyboard normally.

But doesn't matter the circumstances, I always have to to hard reboot with holding the power button for a couple of seconds to power it off and restart it.

I am desperate, I tried putting the AMD iGPU as a primary and Nvidia dGPU only on command using "__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia program_name", but even after that the Nvidia was still active and the freezes persisted.

I found, that going to Xorg instead of wayland could fix things, but I haven't been able to put Xorg into place, as Fedora 43 doesn't seem to have it as a option anymore and when i tried to force it to use the Xorg, the whole graphics crashed and I was only in the text mode from the boot and even after the login, so I went back to the previous settings using Wayland.

Can anyone, who has a clue what to do next, please, advise me what to do next? If I didn't put enough info here, I will gladly do it, just please ask, what could also be relevant that I didn't include here.

 

[dos2unix]

This isn't just a Fedora thing, it's a Linux thing. (Before anyone says "wayland", the same thing happens in X11).
Interestingly enough, if both APGU and discrete GPU are same brand and close to use same driver.. then no problems.

This is a well-documented class of problem on hybrid GPU laptops (AMD iGPU + NVIDIA dGPU) running Wayland, and the symptoms you describe — display freezing while the system keeps running, second monitor staying alive — point pretty clearly toward a GPU/compositor interaction issue rather than a kernel panic or hardware failure. Here's a systematic path forward.

First, confirm what's actually happening during a freeze
Before fixing anything, get diagnostic data. After your next freeze and hard reboot, check the journal from the previous boot:

journalctl -b -1 -p err --no-pager | tail -100

Also check specifically for GPU-related messages:

journalctl -b -1 | grep -iE "nvidia|amdgpu|drm|freeze|hang|reset" | tail -80

This will tell you whether it's the NVIDIA driver crashing, the AMD driver, or the DRM/compositor layer. That information changes what you do next.

The core issue is NVIDIA + Wayland on hybrid laptops

On Fedora 43 with Wayland, the compositor (KDE Plasma or GNOME) needs to coordinate between the AMD iGPU (which drives the internal display) and the NVIDIA dGPU. The NVIDIA proprietary driver has historically had trouble with this handoff, especially around power management and buffer synchronization. The symptom of the internal display freezing while an external monitor (which may be routed differently) keeps working is a classic sign of this.

Some things I would try, starting with the "safest".

Force the NVIDIA driver into proper power management mode
Create or edit /etc/modprobe.d/nvidia.conf:

options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp
Then enable the NVIDIA suspend services:
sudo systemctl enable nvidia-suspend.service
sudo systemctl enable nvidia-resume.service
sudo systemctl enable nvidia-hibernate.service
Rebuild initramfs and reboot:
sudo dracut --force
sudo reboot

This is one of the most common fixes for freeze issues on NVIDIA + Wayland hybrid systems.
Check your NVIDIA driver version and kernel module status

nvidia-smi
modinfo nvidia | grep ^version

Make sure you're running the latest driver available in Fedora's RPM Fusion repository. If you're on an older driver:

sudo dnf update akmod-nvidia xorg-x11-drv-nvidia\*

Force the dGPU off when not in use (true PRIME offload mode) (This is only for testing purposes, not a permanent fix)
The goal is to have the AMD iGPU handle all rendering by default and only invoke NVIDIA explicitly. Check whether your system is actually doing this:

cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status

# (adjust PCI address — find it with: lspci | grep -i nvidia)


To enforce runtime power management on the NVIDIA GPU, add to /etc/udev/rules.d/80-nvidia-pm.rules:

ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x0c0330", TEST=="power/control", ATTR{power/control}="auto"

About Xorg — it's not gone, just hidden (I recommend staying with Wayland, but you can try this as a last resort). I honest haven't used X11 or xorg on Fedora in years.
Fedora 43 removed Xorg as a login option by default but the packages still exist. To restore the option:

sudo dnf install xorg-x11-server-Xorg

Then at the GDM login screen, click your username, and before entering your password look for the gear icon in the bottom right — that should give you a session choice including X11. If GDM itself isn't showing that option, you can force it:
(This be a problem if you're still using the sddm greeter sometimes).

sudo nano /etc/gdm/custom.conf

Under [daemon], add or uncomment:

WaylandEnable=false

This forces GDM to use Xorg entirely. It's a valid diagnostic step — if freezes stop under Xorg, you've confirmed it's a Wayland/NVIDIA compositor issue, not hardware.

As a last resort -- Kernel parameters worth trying

Edit your GRUB config (/etc/default/grub) and add to GRUB_CMDLINE_LINUX:

nvidia-drm.modeset=1 nvidia-drm.fbdev=1

Then update GRUB:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

nvidia-drm.modeset=1 enables kernel mode setting for NVIDIA, which is required for proper Wayland support. Without it, the driver gets flaky exactly as you're describing.

Start with step 1 (power management options) and step 5 (kernel parameters) together — those two alone resolve this class of issue for a large number of people. Get the journal logs from your next freeze regardless so you have data to work with. If freezes continue, step 4 (forcing Xorg) will confirm whether it's Wayland-specific, which then tells you whether to wait for an upstream fix or stay on Xorg until the driver situation matures.
Let me know what the journal logs show and that will help narrow it down further.

My laptop doesnt have a 4070, only 3060, but usually disabling one fixes it. (You have to do this in the UEFI). Never had a problem after this. If you dont like that solution, try the things above.

 

[ricvasi]

Hi,

thank you very much for your response. The lag occured an hour ago, so based on those two commands you suggested I'm putting here the journals:

From journalctl -b -1 -p err --no-pager:

Feb 24 16:12:29 risova-masina tlp[206615]: Warning: AMDGPU_ABM_LEVEL_ON_AC/BAT is not set because power-profiles-daemon is running.
Feb 24 17:04:16 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:17 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:17 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR [CRTC:80:crtc-0] flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: amdgpu: [drm] ERROR [CRTC:80:crtc-0] hw_done or flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

this message was repeated for another 5 minutes, then it was replaced by this:

Feb 24 17:09:20 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR Error queueing DMUB command: status=2
Feb 24 17:09:20 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

and this was going on untill i rebooted.

From journalctl -b -1 | grep -iE "nvidia|amdgpu|drm|freeze|hang|reset" :

Feb 24 16:12:29 risova-masina tlp[206615]: Warning: AMDGPU_ABM_LEVEL_ON_AC/BAT is not set because power-profiles-daemon is running.
Feb 24 17:04:16 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:17 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:17 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR [CRTC:80:crtc-0] flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: amdgpu: [drm] ERROR [CRTC:80:crtc-0] hw_done or flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

and again after a while it was sending the same as in the previous journal output.

Please, advise, where to go next from this (if I should then follow your plan from previous message, or this journals change things).

Again, thank you for any help .

 

[dos2unix]

Does your UEFI/BIOS allow you to disable the embdeed APU graphics chip? Most do.

 

[ricvasi]

Does your UEFI/BIOS allow you to disable the embdeed APU graphics chip? Most do.

No, I only found found something about a display mode, with the options Dynamic and dGPU only. Currently, I have a dynamic option selected. If I understand correctly, if I choose dGPU only, than the NVIDIA would be running the display from the start and maybe the freezes would dissapear. But that would probably lead to more power consumption, right?

Is there any possibility, that I could be running on iGPU for the basic tasks, and when the dGPU is needed (simulations, rendering a high resolution 3D graphs, ...), I would turn it on manually for required programs?

Or to ask differently, what did the journals mean, if you could please explain?

 

[dos2unix]

dGPU stands for "discrete GPU", that s likely the nvidia. Disabling the apu (built-in) is usually preferred.
Yes it can use more Battery that way.. but that's better than crashing so often. If battery is a concern,
sometimes you can go the other way and use the APU, and disable the discrete card. Usually the graphics
aren't nearly as good, but yr battery will usually last a little longer.

 

[f33dm3bits]

Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR [CRTC:80:crtc-0] flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: amdgpu: [drm] ERROR [CRTC:80:crtc-0] hw_done or flip_done timed out
Feb 24 17:04:27 risova-masina kernel: amdgpu 0000:66:00.0: [drm] ERROR dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data

That looks like one of the many errors I've seen on the AMD Gitlab issues section. There's boot options that have worked for people and for others not. I would go with what's already been mention if it's a desktop which is this.

dGPU stands for "discrete GPU", that s likely the nvidia. Disabling the apu (built-in) is usually preferred.

For other thing you can try is this:, add the following to your boot parameters your Grub config(/etc/default/grub and it to this line "GRUB_CMDLINE_LINUX_DEFAULT" )

amdgpu.dcdebugmask=0x10 amdgpu.gpu_recovery=1

Then update your Grub menu.

Correct way to update grub boot entries

This command overwrites a default pointer file that has been in place since about fedora 32 or 33 which redirects grub to the actual file at /boot/grub2/grub.cfg. If you were to run ls -l /efi/grub*.cfg you would also find two symlinks there that point to the actual grub.cfg file. What the...

discussion.fedoraproject.org

Try one at a time and then both. If that doesn't work you can try stopping and disabling power profiles.

sudo systemctl disable power-profiles-daemon --now

You can also try using Switcheroo.

sudo dnf install switcheroo-control
sudo systemctl enable switcheroo-control

Then logout and log back in again, more information you can read about here.

Switcheroo Control

Switcheroo-Control D-Bus service to check the availability of dual-GPU, integrates with the settings of KDE/plasma Gnome, and Cinnamon: “Launch using Dedicated Graphics Card” menu item appears on a…

discovery.endeavouros.com

 

[ricvasi]

dGPU stands for "discrete GPU", that s likely the nvidia. Disabling the apu (built-in) is usually preferred.
Yes it can use more Battery that way.. but that's better than crashing so often. If battery is a concern,
sometimes you can go the other way and use the APU, and disable the discrete card. Usually the graphics
aren't nearly as good, but yr battery will usually last a little longer.

So you think my best shot is to choose the dGPU for display handling, and that would eliminate the problem? Because above you mentioned also a solution by putting the nvidia driver into proper power management mode combined with the kernel mode adjust. And if this type of solution would also fix it and also allow me to use the AMD graphics for the basic usage and to use nvidia onyl when needed, that would be the ideal solution for me.

But if the journals I sent tell you I cannot use this fix, then I should use the display mode setting adjustment?

If I am misunderstanding something, I am sorry to ask you to repeat yourself.