Hello, I have this bug Heavy Flickering on Second Display using Plasma Login Manager or SDDM running on Wayland which is reproducible both with the 580 driver and the 590 driver, and is reproducible with all of the older drivers as well
Thanks for the input, I have created identical setup as yours and tried same repro steps which you have mentioned still I am not able to see sudden mesh explodes. Will it be possible for you to record video of it? Also do you see any Nvidia related error when this issue occurs?
I will let you know whether Iām able to reproduce the issue again on the 590 drivers. It did not occur consistently on my setup, so the testing may take some time.
The video wonāt show anything more than the screenshots I already posted (see below: thatās what an avatar mesh attachment looks like once it āexplodedā)ā¦ And recording 20 minutes of video would result in a huge file I wonāt be able to upload here.
And no, there is no Xid message in the system logs. Also, this happens at stock frequencies (GPU and VRAM), and even when I activate the frame rate limiter in the viewer (at which point the load on the GPU is much smaller).
PS: thereās one thing I did not try however: using NVIDIAās proprietary modules instead of the GPL onesā¦ Might try that, free time permitting (in case the GSP firmware would be involved).
So, I took some time this morning to retry with 580.126.18 and the proprietary modules on my second PC (equipped with a RTX 3070), at stock clock speed, with just the performance mode activated.
I got the same issue again, after 26 minutes of rendering, but it was very fugacious and I had trouble capturing it in a video (the time to start the video and it was gone, only to resurface a couple minutes later).
I finally managed to capture a short video of it after 36 minutes: here it is (note: this file will stay available for 30 days from today).
Iām also attaching the bug report log (though, thereās nothing wrong in the system logs: no Xid, as usual).
nvidia-bug-report.log.gz (674.1 KB)
Note also that the very first v580 beta release was especially bad and showed up numerous of these meshes explosions almost immediately: if you want to reproduce the bug more easily at NVIDIA, you might want to try it instead of the latest releaseā¦
I got the video, Thank you so much for this. Working on it, I will update you accordingly. Can you also please share this location name (I will try on same location to get same light and reflections)?
1 Like
Itās āWarehouse 21ā, but the location in SL does not matter the least: pick up the one with the largest amount of avatars: use the Search functionality, like explained in the second paragraph of this post, to pick the current, most busy place in the āWhatās hot nowā category of the Showcase.
Light and reflections do not matter at all either, and with the Cool VL Viewer I use you can even switch between two renderers; the current and modern PBR one (which I used for this video), or the legacy one with both deferred (AKA āALMā for Advanced Lighting Model) or forward rendering. In any of these three rendering modes, the bug does happen: this is not a renderer bug, but a driver-level, OpenGL (an issue with vertex buffers management in VRAM, perhaps?) or firmware bug (bad automatic GPU core frequency boosting algorithm, perhaps?) that got introduced between v575 and the very first v580 beta release.
nvidia-bug-report.log.gz (135.8 KB)
guys, the game CODE VEIN isnāt launching!
I have the same issue with the same GPU and the last process using the GPU is stuck in the kernel forever. The issue started to happen when I set CUDA_DISABLE_PERF_BOOST to 1 to watch videos using the unofficial VAAPI driver without having the GPU clock at the maximum level.
Did you get chance to check?
Did you get chance to check this? @zrzut01
Thank you so much for your kind revert, I agree that āHDMI FRL link training failedā is generic warning and we get that during bandwidth negotiation. It depends on multiple factors such as Display model, refresh rate and HDMI cable you are using. I am glad that the original issue of āMonitor not waking upā is resolved now. For warning āHDMI FRL link training failedā and other issue you have mentioned I will check logs and file a new bug if needed. Thank you.
Subject area: Suspend/resume failure ā flip event timeout on resume (RTX 5090, COSMIC/Wayland, s2idle)
Hi all. Thank you so much for putting in the effort to make our hardware work! Here is my current issue outlined below.
Hardware:
-
GPU: NVIDIA GeForce RTX 5090 (32GB)
-
Motherboard: ASUS pro WS TRX50-SAGE
-
CPU: MAD Ryzen Threadripper 9970x
-
Monitors: Dell U2725QE (DP), BenQ PD3226G, [others]
Software:
-
OS: Pop!_OS 24 (COSMIC desktop, Wayland)
-
Kernel: [run
uname -rto confirm] -
Driver: 580.119.02 (open kernel modules)
-
Sleep mode: s2idle (
mem_sleep_default=s2idle)
Problem: System suspends successfully via systemd (nvidia-suspend.service runs, s2idle entered), but on resume the display pipeline fails with:
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* Flip event timeout on head 0
No Xid errors or GSP timeouts in this instance ā the failure is purely in the DRM atomic commit path on resume.
Additional observations:
-
nvidia-suspend.service and nvidia-resume.service enabled and running correctly
-
PreserveVideoMemoryAllocations=1 with TemporaryFilePath on disk (VRAM is 32GB, exceeds /run tmpfs)
-
Also tested with PreserveVideoMemoryAllocations=0 ā same failure
-
Also tested with nvidia_drm.fbdev=1 ā same failure
-
S3 (ādeepā) sleep produces Xid 13 and Xid 119 GSP timeout errors on resume
-
cosmic-comp logs āUnable to clear state: DRM access errorā¦ Permission deniedā immediately before suspend
-
Multi-monitor DisplayPort setup
nvidia-bug-report.log.gz (620.7 KB)
Bug report attached.
1 Like
We have similar bug 5921198 filed internally for tracking purpose.
Shall keep you updated on the same.
Will HDR having washed out colors get fixed?
Tested again with GNOME 49 and NVIDIA-Linux-x86_64-580.126.18 driver with same results as previously on same hardware.
Currently I have no other displays to check with.
Thanks for the update.
After installing Windows 10, I also encountered a graphics card driver issue, but it turned out to be a hardware problem (a faulty RAM module).
Also having a resume issue on openSUSE tumbleweed 20260226, kernel 6.19.3-1-default with Gnome 49 Wayland on NVIDIA driver version 580.126.18. Sometimes after resume from sleep the screen will crash to a black screen and fans will speed up. Iām also unable to switch to TTY. Bug report log attached
nvidia-bug-report.log.gz (1.2 MB)
@vrachatte
A version of libva-nvidia-driver containing a supposed fix screen recording issue was pushed to the Fedora 43 repository today, but screen recording remains broken for NVIDIA users (also on 590.44.01, 595.45.04).
kn@fedora:~$ rpm -q libva-nvidia-driver
libva-nvidia-driver-0.0.16-1.fc43.x86_64