This is a bug fix release and a new series 575.xx. Bug fixes: https://www.nvidia.com/en-us/drivers/details/249044/ https://www.nvidia.com/en-us/drivers/details/247716/
Created attachment 15040 [details] files list
Assignee: bugsquad => qa-bugs
Keywords: (none) => advisory
RH x86_64 As this affects packages that are not directly related to nvidia hardware I update the core packages installing glxinfo-9.0.0-1.mga9.x86_64.rpm eglinfo-9.0.0-1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################## 1/2: eglinfo ################################################################################################## 2/2: glxinfo ################################################################################################## 1/2: removing eglinfo-8.5.0-3.1.mga9.x86_64 ################################################################################################## 2/2: removing glxinfo-8.5.0-3.1.mga9.x86_64 ################################################################################################## eglinfo & glxinfo works
MGA9-64 Plasma; $ inxi -MCG Machine: Type: Desktop Mobo: ASUSTeK model: PRIME Q270M-C v: Rev X.0x serial: <superuser required> UEFI: American Megatrends v: 2201 date: 12/21/2023 CPU: Info: quad core model: Intel Core i5-7500 bits: 64 type: MCP cache: L2: 1024 KiB Speed (MHz): avg: 800 min/max: 800/3800 cores: 1: 800 2: 800 3: 800 4: 800 Graphics: Device-1: NVIDIA GM107GL [Quadro K620] driver: nvidia v: 550.163.01 Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: nvidia,v4l gpu: nvidia,nvidia-nvswitch resolution: 1920x1080~60Hz API: EGL v: 1.5 drivers: nvidia,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.163.01 renderer: Quadro K620/PCIe/SSE2 API: Vulkan v: 1.3.231 drivers: nvidia,llvmpipe surfaces: xcb,xlib I began with nvidia-current, testing updates other than newfeature. There were no installation issues. I rebooted, logging into x11, and saw no issues with operation. Logging into Wayland, there was little change from earlier updates.The Google Earth Pro "glitch" from Bug 34190 is still there, just as it was before. In addition, videos played with vlc showed some jerkiness that does not appear with x11. I believe this is another of the ongoing Wayland/Plasma issues that should not hold back the update. I'll be back later with the newfeature test results.
CC: (none) => andrewsfarm
Regarding video with vlc, are you using vlc-plugin-vdpau installed in vlc? Does the same jittering appears in mpv for instance?
(In reply to Giuseppe Ghibò from comment #1) > Created attachment 15040 [details] > files list BTW, sorry the cuda-z will be part of a next upgrade (cuda 12.9.1, not this one).
(In reply to Giuseppe Ghibò from comment #4) > Regarding video with vlc, are you using vlc-plugin-vdpau installed in vlc? > Does the same jittering appears in mpv for instance? Yes, it is installed. No, I do not see the jerkiness with mpv. Or with Dragonplayer.
(In reply to Thomas Andrews from comment #6) > (In reply to Giuseppe Ghibò from comment #4) > > Regarding video with vlc, are you using vlc-plugin-vdpau installed in vlc? > > Does the same jittering appears in mpv for instance? > > Yes, it is installed. No, I do not see the jerkiness with mpv. Or with > Dragonplayer. OK, those are native wayland. Any change using "QT_QPA_PLATFORM=xcb vlc|ge ..."?
You lost me with that one. Please give more details on how to do that. Remember, I'm a simple farmer, not an IT guy.
(In reply to Thomas Andrews from comment #8) > You lost me with that one. Please give more details on how to do that. > > Remember, I'm a simple farmer, not an IT guy. But you were an IT guy... (only changed from electrons to photons...) :-) I was referring to run vlc or googleearth starting from command line with passing the env var QT_QPA_PLATFORM=xcb, like: QT_QPA_PLATFORM=xcb vlc "playbackfile" but for GE, indeed I see you had already tried with QT_QPA_PLATFORM=xcb in bug #34190 to see if that was fixing the glitches, and didn't helped, so probably won't have any effect on vlc too on the jittering problems. "mpv" should be a native Wayland app, that why doesn't show these problems. I don't think there is much we can do for vlc with wayland (under plasma) at the moment.
Moving on to the newfeature driver... With the packages in qarepo, I used drakx11 to switch to the newfeature driver, apparently with no issues. But, knowing drakx11 doesn't install the cuda-opencl package, I attempted to run MCC to take care of that before rebooting. But MCC immediately crashed. I might have been able to run drakrpm or urpmi from a terminal and install it, but I attempted a reboot, as drakx11 had told me I needed to do. That also crashed. It didn't just send me to the sddm login screen, it froze at a point just before that. I had to use the reset button, boot into run level 3, and use startx to get the desktop. Once there MCC would now run without crashing, and I could now install the newfeature cuda-opencl package. After that, sddm started working normally, including autologin into an X session. I could log out and back into a Wayland session - which I'm using now. Google Earth is almost glitch-free in Wayland with the newfeature driver, but the jerkiness in vlc is much worse. The driver runs OK I suppose, but the reboot freeze is unacceptable. Somehow, the cuda-opencl package should be automatically installed BEFORE the user does a reboot. Or, sddm needs to be fixed so it will run without it.
Thanks for testing. Just a few considerations. The nvidia<driver>-cuda-opencl (where driver=470,-current,-newfeature) was "extracted" from the main package dependencies during mga8->mga9 finalization to make room in the LIVE ISO for other packages, for fitting into the 4.3GB limit. AFAIK the hard crash|lockup after reboot is weird and shouldn't happen. Also sddm should run even without the cuda-opencl package installed. What I wonder is if really during that boot the nvidia driver was involved, and instead was caused by temporarely switching for some reason to something other (e.g. nouveau). Can journal logs show something about this? As for the installation, indeed there could be two kind of installations: "basic" and "extended". The basic involves the installation of just the x11-driver-video-nvidia<driver> and it's dkms depependency. However beside this we can manually "complete" the installation with more packages, one is the nvidia<driver>-cuda-opencl, but others are the dkms-nvidia<driver>-open for using the open driver (only for Arch based on Turing and beyond, which is now mandatory for some RTX 50xx card), the nvidia<driver>-all for installing also the 32bit libraries (so "full optional"), useful for 32bit games, and nvidia<driver>-initramfs for early loading at boot of the nvidia kernel modules. However drakx11 is only "aware" of the "basic" installation, and not of the "extended" installation, so when switching to another series it will switch to the "basic" installation in that series, even if user had completed manually to the "extended" installation in the alternative series. To have it more robust we should either add automatically all the deps to the x11-driver-video-nvidia<driver> package, OR make drakx11 aware of the "extensions" and have it to "replicate" all the secondary packages when switching to another nvidia driver series. Of course the latter is not trivial as requires to modify the drakx11 sources (should require at least opening a bug as "enhancement" for drakx11 to remind).
Works great with my nvidia card and kernel 6.14 Other kernesl line 6.15 and 6.16 display an error saying GPU card is already bound to NovaCore. $ inxi -MCG Machine: Type: Desktop Mobo: Gigabyte model: X670 AORUS ELITE AX serial: <superuser required> UEFI: American Megatrends LLC. v: F34 date: 05/23/2025 CPU: Info: 8-core model: AMD Ryzen 7 7700 bits: 64 type: MT MCP cache: L2: 8 MiB Speed (MHz): avg: 3021 min/max: 545/5392 cores: 1: 3021 2: 3021 3: 3021 4: 3021 5: 3021 6: 3021 7: 3021 8: 3021 9: 3021 10: 3021 11: 3021 12: 3021 13: 3021 14: 3021 15: 3021 16: 3021 Graphics: Device-1: NVIDIA TU106 [GeForce RTX 2060 Rev. A] driver: nvidia v: 575.64.03 Device-2: Advanced Micro Devices [AMD/ATI] Raphael driver: amdgpu v: kernel Display: x11 server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8 driver: X: loaded: modesetting,nvidia dri: radeonsi gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz API: EGL v: 1.5 drivers: kms_swrast,nvidia,radeonsi,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 575.64.03 renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2 API: Vulkan v: 1.4.321 drivers: nvidia,radv,llvmpipe surfaces: N/A Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor gpu: corectrl, lact, nvidia-settings, nvidia-smi wl: wayland-info x11: xdpyinfo, xprop, xrandr Regards
CC: (none) => ezequiel_partida
Summary: Update request: nvidia-newfeature-575.64.03-1.mga9.nonfree => Update request: nvidia-newfeature-575.64.05-1.mga9.nonfree
Created attachment 15046 [details] files list
Attachment 15040 is obsolete: 0 => 1
(In reply to Giuseppe Ghibò from comment #0) > This is a bug fix release and a new series 575.xx. Bug fixes: > > https://www.nvidia.com/en-us/drivers/details/249044/ > https://www.nvidia.com/en-us/drivers/details/247716/ New list: https://www.nvidia.com/en-us/drivers/details/250991/ https://www.nvidia.com/en-us/drivers/details/249044/ https://www.nvidia.com/en-us/drivers/details/247716/
Consider also using ldetect-lst for testing, as from bug #34499 (not included here to avoid overlapping).
Advisory Updated
Finally getting back to this. Once again I started with nvidia-current installed, from when I tested that update - also ldetect.lst. My GPU is not supported by the open driver. I used qarepo to download the files from the updated list, then ran MCC and got waiting updates. (poppler, sudo) Then I used drakxll through MCC to switch to the newfeature driver. (The first time, I simply ran drakx11 from the command line as a user, not root. I wonder if that might have been some of the problem I had with the original test?) Once that was done, I used drakrpm to install the newfeature-all Package, which brought in the opencl package a several 32-bit dependencies. But, it did NOT bring in the newfeature-initramfs package. I had to install that separately. I rebooted into a working x11 desktop. Autologin is working. Tried this and that, with no issues. Logged into Wayland, tried stuff again. For the first time in MGA9 Wayland, Google Earth Pro is now stable, working as it should. However, vlc still has instability in the video. I am inclined to validate, unless the initramfs package was supposed to be installed by the -all package.
Cancel that. I am no longer inclined to validate. The above test was with the server kernel. When I attempted to boot into the desktop kernel, it appeared to build the driver as it should, but at the end, it crashed. A number at the top of the screen and a flashing cursor. The reset switch was the only way out. I booted again, this time in run level 3, and logged in, but when I tried "startx" it crashed back to the command prompt. Reboot into the server kernel worked. Reboot into desktop, log in as root, run drakx11. Reboot, no change. Next, I attempted to use drakx11 from the desktop kernel to switch back to nvidia-current. Huge mistake. Now I can't log in at all, with either kernel, except at run level 3. Fortunately, I did all this on my test install. My production install is, so far, unaffected. And once again I am reminded of why I swore off nvidia GPUs several years ago. I'm getting a headache.
(In reply to Thomas Andrews from comment #18) > Cancel that. I am no longer inclined to validate. > > The above test was with the server kernel. When I attempted to boot into the > desktop kernel, it appeared to build the driver as it should, but at the > end, it crashed. A number at the top of the screen and a flashing cursor. > The reset switch was the only way out. > > I booted again, this time in run level 3, and logged in, but when I tried > "startx" it crashed back to the command prompt. Reboot into the server > kernel worked. Reboot into desktop, log in as root, run drakx11. Reboot, no > change. > > Next, I attempted to use drakx11 from the desktop kernel to switch back to > nvidia-current. Huge mistake. Now I can't log in at all, with either kernel, > except at run level 3. > > Fortunately, I did all this on my test install. My production install is, so > far, unaffected. And once again I am reminded of why I swore off nvidia GPUs > several years ago. I'm getting a headache. The -initramfs package at the moment is not installed automatically by drakx11 (nor with -all metapackage), but its choice is left to the user, once the driver installed and built. The idea for the future is to have an option in drakx11 like "[x] install modules in initramfs for early loading", but it's not implemented yet. The crash are pretty weird, and what I'm wondering is what happens (any hints in logs?), i.e. if crashes are from the driver itself, or from the installation that lead in some way to "automatically" switch to the non-proprietary, like nouveau DDX or modesetting (which would use nouveau kernel module at the end), which is done automatically since ancient time if drakx11 perceive something wrong with the loading of the proprietary driver (even if temporarely due to lag or race condition at boot). That's one of the main source of problems it generates. kernel logs might tell. Also to see (in the case you have installed the -initrd) if the driver is included really in the initramfs, you might use "lsinitrd | grep -i nvidia", at least for current kernel; "modinfo nvidia-newfeature" would tell if the driver is build is the right for the current kernel.