Created attachment 15040 [details]
files list

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

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.

I was able to get Plasma back by using run level 3 as root to run drakx11 and switch to the modesetting driver. Nouveau wouldn't work - conflicts with already installed nvidia driver modules. (Maybe because of the initramfs package?)

I removed all nvidia-newfeature and nvidia-current packages, rebooted into each kernel, and both worked. Then I installed nvidia-current with drakx11, and before rebooting installed the nvidia-current-all package, with dependencies. I did not install the initramfs package. Both kernels worked on the reboot, the desktop kernel building the modules during the boot process.

Another reboot, and this time I used drakx11 from MCC to switch to the newfeature driver, also installing the newfeature-all package before the reboot. Rebooting into that kernel worked as it should, as described in comment 17. 

And here is where it fails. Booting into the other installed kernel appeared to build and install the newfeature drivers as before, but when it got to point just before the sddm autologin would show up, it stalled. Worse, trying to restart into the kernel that had just been working failed in the same way.

I had to go back to the modesetting driver again to get the desktop back. I suspect that if I were to remove all installed newfeature packages again, reboot with the modesetting driver, then use drakx11 to install them again, it would work on both kernels once more. As an experienced Mageia user, I can work this out, but new users - no way.

(In reply to Thomas Andrews from comment #20)
> I was able to get Plasma back by using run level 3 as root to run drakx11
> and switch to the modesetting driver. Nouveau wouldn't work - conflicts with
> already installed nvidia driver modules. (Maybe because of the initramfs
> package?)
> 
> I removed all nvidia-newfeature and nvidia-current packages, rebooted into
> each kernel, and both worked. Then I installed nvidia-current with drakx11,
> and before rebooting installed the nvidia-current-all package, with
> dependencies. I did not install the initramfs package. Both kernels worked
> on the reboot, the desktop kernel building the modules during the boot
> process.
> 
> Another reboot, and this time I used drakx11 from MCC to switch to the
> newfeature driver, also installing the newfeature-all package before the
> reboot. Rebooting into that kernel worked as it should, as described in
> comment 17. 
> 
> And here is where it fails. Booting into the other installed kernel appeared
> to build and install the newfeature drivers as before, but when it got to
> point just before the sddm autologin would show up, it stalled. Worse,
> trying to restart into the kernel that had just been working failed in the
> same way.
> 
> I had to go back to the modesetting driver again to get the desktop back. I
> suspect that if I were to remove all installed newfeature packages again,
> reboot with the modesetting driver, then use drakx11 to install them again,
> it would work on both kernels once more. As an experienced Mageia user, I
> can work this out, but new users - no way.

So, apparently this is a problem in the transaction from a driver to another (or modesetting) rather than the newfeature 575.64.05 itself?

Regarding the -initramfs package a few note. It isn't handled automatically by drakx11 (at least not yet), and is intended to "consolidate" the NVidia proprietary driver installation, so that it's loaded early at boot. This might also help with some desktop (e.g. Wayland) when the desktop starts too fast and the nvidia kernel modules aren't yet loaded.

Since it writes the modules to the initramfs for early loading a successful, switch to nouveau or modesetting (and even if the switch is performed automatically by drakx11 for some reason) wouldn't remove it, so the nvidia modules are still loaded, even if next boot is trying to use modesetting/nouveau. But due to concurrent access of the same resources,it's the nouveau that conflicts with previous nvidia and then it can be loaded too.

(In reply to Giuseppe Ghibò from comment #21)

> So, apparently this is a problem in the transaction from a driver to another
> (or modesetting) rather than the newfeature 575.64.05 itself?
> 
Maybe not. I tried one more round, trying to be more methodical this time.

I started with the server kernel, modesetting driver, all -newfeature and -current packages removed. Using XFdrake as root, I installed the  newfeature driver. I seemed to build OK, when choices were offered I went with the defaults. When told I'd need to reboot for changes to take effect, I did so. And the boot failed. Back to modesetting without removing the newfeature packages, installed the newfeature-opencl package, and rebooted once more, successfully. 

Then I booted the desktop kernel. The modules were built and installed, and the boot was successful. But then I booted into the server kernel - and it failed as before.

Back to modesetting in the server kernel, removed all newfeature packages, rebooted because I had above, then used XFdrake to install nvidia-current. Rebooted when told I should, successfully. Booted into the desktop kernel, modules built and installed, and it was successful. Booted into the server kernel once more, successfully.

So, when installed by XFdrake, nvidia-current works as expected, but newfeature sometimes fails to boot. To me, that means there's something different about the newfeature driver, at least with my hardware. The Quadro K620 IS still supported by this newfeature driver, isn't it?

(In reply to Thomas Andrews from comment #22)

> So, when installed by XFdrake, nvidia-current works as expected, but
> newfeature sometimes fails to boot. To me, that means there's something
> different about the newfeature driver, at least with my hardware. The Quadro
> K620 IS still supported by this newfeature driver, isn't it?

yes, K620 is still supported, see:

https://www.nvidia.com/en-us/drivers/details/250991/

in the "Supported Products" tab, in the section "Quadro Series", is the last in list. PCIe ID should be 10de:13bb.

Does using it with kernel-server 6.6.100 in updates_testing showing the same problems?

(In reply to Thomas Andrews from comment #22)

> Then I booted the desktop kernel. The modules were built and installed, and
> the boot was successful. But then I booted into the server kernel - and it
> failed as before.
> 

this come as suggestion on another bug (#34514), but might be worthwhile an attempt: if you in /etc/nvidia-newfeature/modprobe.conf, uncomment the line:

#options nvidia-drm fbdev=1

and change to:

options nvidia-drm fbdev=0

or "on the fly" booting with cmdline nvidia-drm.fbdev=0, does it run smoother?

(In reply to Giuseppe Ghibò from comment #24)
> (In reply to Thomas Andrews from comment #22)
> 
> > Then I booted the desktop kernel. The modules were built and installed, and
> > the boot was successful. But then I booted into the server kernel - and it
> > failed as before.
> > 
> 
> this come as suggestion on another bug (#34514), but might be worthwhile an
> attempt: if you in /etc/nvidia-newfeature/modprobe.conf, uncomment the line:
> 
> #options nvidia-drm fbdev=1
> 
> and change to:
> 
> options nvidia-drm fbdev=0
> 

I edited the file before the first reboot after installing with XFdrake, and that took care of the boot problems. It now boots every time, for each kernel, with no issues but one - autologin is again disabled. However, that is much easier to live with than failed boots.

Oh, and the change in the conf file made no difference in the way it works under Wayland - though I haven't tried installing the opencl package yet.

(In reply to Thomas Andrews from comment #26)
> Oh, and the change in the conf file made no difference in the way it works
> under Wayland - though I haven't tried installing the opencl package yet.

Ok, I updated to version -575.64.05-2.mga9.nonfree with the fbdev disabled. It should be more stable now.

BTW, what is the ratio betwen the performance of some bench on Xorg and on Wayland?

Created attachment 15060 [details]
files list

Attachment 15046 is obsolete: 0 => 1

Looks good. Installed on the server kernel first, then desktop. No issues with either, except that autologin is disabled. 

Installed newfeature-all, then ran glmark2 under x11 and Wayland. Results:

x11 glmark2 score 5189
Wayland glmark2 score 2153

Quite a difference.

Anyway, giving this an OK and validating.

Sigh. It's been a long day and I forgot how to check the advisory. Katnatek, did you update it for the latest revision?

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK
CC: (none) => sysadmin-bugs

(In reply to Thomas Andrews from comment #29)
> Looks good. Installed on the server kernel first, then desktop. No issues
> with either, except that autologin is disabled. 
> 
> Installed newfeature-all, then ran glmark2 under x11 and Wayland. Results:
> 
> x11 glmark2 score 5189
> Wayland glmark2 score 2153
> 
> Quite a difference.
> 
> Anyway, giving this an OK and validating.
> 
> Sigh. It's been a long day and I forgot how to check the advisory. Katnatek,
> did you update it for the latest revision?

Updated now

(In reply to Thomas Andrews from comment #29)

> Looks good. Installed on the server kernel first, then desktop. No issues
> with either, except that autologin is disabled. 

to get the autologin working you need the nvidia kernel modules early loading at boot, by installing nvidia-{newfeature|current}-initramfs subpackage (of course with paying attention at it when running automatic transictions to other drivers, at least until drakx11 will be able to detect it).

I guess also no artifacts anymore on Wayland for GE?

> 
> Installed newfeature-all, then ran glmark2 under x11 and Wayland. Results:
> 
> x11 glmark2 score 5189
> Wayland glmark2 score 2153
> 
> Quite a difference.

yes, the same seems also under gnome/mutter (e.g. https://gitlab.gnome.org/GNOME/mutter/-/issues/3461).

(In reply to Giuseppe Ghibò from comment #31)
> (In reply to Thomas Andrews from comment #29)
> 
> > Looks good. Installed on the server kernel first, then desktop. No issues
> > with either, except that autologin is disabled. 
> 
> to get the autologin working you need the nvidia kernel modules early
> loading at boot, by installing nvidia-{newfeature|current}-initramfs
> subpackage (of course with paying attention at it when running automatic
> transictions to other drivers, at least until drakx11 will be able to detect
> it).
> 
I was wondering a bit about that. Suppose I had the initramfs package installed, then decided to switch to nvidia-current using XFdrake. What about that first boot? And even if that worked OK, what about the first boot into a different kernel?

> I guess also no artifacts anymore on Wayland for GE?
> 
Nope. Still working OK. VLC still has issues, though they may be a bit less than before.

(In reply to Thomas Andrews from comment #32)

> (In reply to Giuseppe Ghibò from comment #31)
> > (In reply to Thomas Andrews from comment #29)
> > 
> > > Looks good. Installed on the server kernel first, then desktop. No issues
> > > with either, except that autologin is disabled. 
> > 
> > to get the autologin working you need the nvidia kernel modules early
> > loading at boot, by installing nvidia-{newfeature|current}-initramfs
> > subpackage (of course with paying attention at it when running automatic
> > transictions to other drivers, at least until drakx11 will be able to detect
> > it).
> > 
> I was wondering a bit about that. Suppose I had the initramfs package
> installed, then decided to switch to nvidia-current using XFdrake. What
> about that first boot? And even if that worked OK, what about the first boot
> into a different kernel?

I was thinking about this: currently, when you switch nvidia series (e.g. by installing x11-driver-video-nvidia-current), the 'nvidia-newfeature-initramfs' package is uninstalled due to cross-dependencies, and the initramfs for the current kernel is regenerated. However, the `nvidia-<series>-initramfs` isn't automatically "replicated" to other kernel series. This means the early loading of nvidia drivers is lost; replicating the -initramfs installation to other series on driver switching is a feature I'm exploring to add within XFdrake (but it's not trivial). Other kernels might still have the (previous) 'nvidia-newfeature' kernel modules in their initramfs, potentially causing issues when booting them (modules mismatch -> missed libraries, etc.), which probably would lead to a black screen.

To avoid these issues, a "cleaned" initramfs should be regenerated for "all" kernels using "dracut --regenerate-all". Currently, this global initramfs regeneration isn't performed automatically by the `%post` scripts when installing a new 'nvidia-<series>-initramfs' package, but it's only done for the current kernel.

> 
> > I guess also no artifacts anymore on Wayland for GE?
> > 
> Nope. Still working OK. VLC still has issues, though they may be a bit less
> than before.

OK, fine then. I think it's the best we can do for now, until a native wayland vlc is released.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2025-0071.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED