nvidia-390xx AUR package discussion thread

seth · 2025-05-09 18:27:33

seth also wrote:

monitor the nvidia-390xx-dkms package for gcc15 patch

It's already slushing around and you don't need a patch for the 6.15 kernel - in doubt you'd likely be better off holding out on the LTS kernel and the 390xx drivers (performance-wise)

aldolat · 2025-05-09 19:14:16

An update regarding my post here: I successfully compiled and installed the nvidia-390-dkms package adding the gcc-15.patch of bufferunderrun here to PKGBUILD. Then I re-enabled the updates for:

linux
linux-headers
gcc
gcc-libs

and updated the whole system without any error.

drankinatty · 2025-05-11 02:15:00

@Seth, the Nvidia-390xx fix build with kernel 6.3 patch looks exactly like what will be required. I wonder why the AUR 390xx driver never fully incorporated that patch?

In the current kernel-6.3.patch for the AUR 390xx driver, kernel/comon/inc/nv-mm.h is never modified. This will take some significant testing to see if we can now incorporate the missing items of the 6.3 patch and make that work with the changes needed for 6.15. If we can, then the backport of Joan's 470 patch with vm_flags_reset(vma, vma->vm_flags | flags) can be directly incorporated.

When 6.15 appears, we see if it will build as is, but I suspect these inconsistencies will need to be ironed out. Has anyone tried incorporating the complete linked 6.3 kernel patch yet with the current or LTS kernel?

Last edited by drankinatty (2025-05-11 03:26:57)

canolucas · 2025-05-13 02:03:49

I'm taking a look at the linux-6.3.patch that was uploaded to the AUR package. Looks like almost all changes of the PLD Linux patch are included in our Archlinux patch

The difference is that the PLD Linux patch adds the following functions:

++static inline void nv_vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
++{
++#if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
++    vm_flags_set(vma, flags);
++#else
++    vma->vm_flags |= flags;
++#endif
++}
++
++static inline void nv_vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
++{
++#if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
++    vm_flags_clear(vma, flags);
++#else
++    vma->vm_flags &= ~flags;
++#endif
++}

But looks like we added similar functions in nv-linux.h (first file modified in the Archlinux patch)

+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 3, 0)
+// Rel. commit "mm: introduce vma->vm_flags wrapper functions" (Suren Baghdasaryan, 26 Jan 2023)
+static inline void vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags |= flags;
+}
+
+static inline void vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags &= ~flags;
+}
+#endif
+

As I could see in the archlinux patch, our approach is different. Instead of using the wrapper functions that start with nv_, we are using the functions defined in Linux kernel directly, (we just declare the functions if the kernel version is < 6.3).

I think we were functionally covered. Functionally, it looks like our code didn't differ from Joan's source code. Yes, the name of the wrapper functions differ vm_flags_set vs nv_vm_flags_set, vm_flags_clear vs vm_flags_clear but both pairs of wrapper functions just add or remove the given flags vma->vm_flags |= flags and vma->vm_flags &= ~flags respectively.

So, what will be the problem with the upcoming Linux kernel release ? I don't see too much code breakage. Yes, Joan's 6.15 patch rely on the functions named nv_vm_flags_set and nv_vm_flags_unset being present. But what if we continue using the functions already defined in the Linux kernel directly (vm_flags_set and vm_flags_clear) ?

I agree that we will be better off avoiding this difference with Joan's code. We'll probably face more merge conflicts or breakage in the future, and being Joan the main maintainer regarding the compatibility of this old driver with new kernel versions, I agree that we will be better off being sync'ed with Joans' codebase.

nv_ wrapper functions also give us more flexibility, we will be able to handle compatibility issues in our package, instead of relying on the Linux kernel functions and being affected by possible changes there.

On the other hand, Joans' changes to the nv_vm_flags_set and nv_vm_flags_clear functions (previously created by him in the 6.3 patch) is just a licence thing, maybe it is not really needed at all. We will have to see when the next kernel version gets released.

static inline void nv_vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
 {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
+    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
+    // Since Linux 6.15, vm_flags_set and vm_flags_clear call a GPL-only symbol
+    // for locking (__vma_start_write), which can't be called from non-GPL code.
+    // However, it appears all uses on the driver are on VMAs being initially
+    // mapped / which are already locked, so we can use vm_flags_reset, which
+    // doesn't lock the VMA, but rather just asserts it is already write-locked.
+    vm_flags_reset(vma, vma->vm_flags | flags);
+#else
     vm_flags_set(vma, flags);
+#endif
 }
 
 static inline void nv_vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
 {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
+    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
+    // See above
+    vm_flags_reset(vma, vma->vm_flags & ~flags);
+#else
     vm_flags_clear(vma, flags);
+#endif
 }

EDIT: yup, looks like we will need Joan's code. symbols that are exported with EXPORT_GPL_ONLY, are only available if the kernel module contains MODULE_LICENSE("GPL")

Last edited by canolucas (2025-05-13 03:14:46)

drankinatty · 2025-05-20 07:16:53

Thank YOU! I'm concerned my attempt to modify the code to use Joan's approach incorporating the changes needed to bring the 390 driver in sync with the 470 driver would not end well. I haven't taken a deep dive into the sources to try and sort it out yet, so it may not be that bad, but I find I'm a bit reluctant to just start tinkering with function renaming or adding new wrappers to the mix without having a good base understanding of the complete sources.

If you have a good handle on what is needed, I'm happy to help test what you can put together. Your explanation above provides a good roadmap that I can use, if needed, to try and locate the current wrappers and see whether we just need to rename/modify the current functions in nv-mm.h or whether we need to add wrappers and leave the current content unchanged. Let me know either way.

I tend to agree that bringing our 6.3 patch in line with the complete kernel 6.3 patch as it was originally will likely make future maintenance and patch backports much easier. Backporting Joan's patches when the code for the drivers diverges takes significantly more experience with the driver than many of those willing to help have. (me included) Thank you again for helping with these differences and let me know how you want to proceed.

canolucas · 2025-05-21 02:32:26

It seems there is a patch proposal in the comments of the AUR package, it was posted today by ventureo. instead of relying on wrapper functions, it uses vm_flags_reset directly, instead of the "from now on GPL only" vm_flags_set / vm_flags_clear when linux version is > 6.15

https://github.com/CachyOS/CachyOS-PKGB … c2d3dcd016
Yes, the approach is different, it doesn't use Joans' wrapper functions, but besides that, it looks good to me. At least we have something to test when Linux 6.15 gets released.

Last edited by canolucas (2025-05-21 02:36:58)

boomshalek · 2025-05-28 17:40:40

Hi
First, thanks a lot for putting all this work in to make our old cards running with upstream kernel changes !
I have installed kernel-lts510. There the build fails an dkms install
(Error ! Bad return status for module build on kernel: 5.10.236-1-lts510)
Unfortunately the make.log seems not to be available

On kernel-lts it installs fine.

Any ideas how to make it install on lts510 ?

TIA

seth · 2025-05-28 18:25:46

It will be helpful to post the build log to see where and why it fails, but you might simply have to skip the patches for newer kernels?

boomshalek · 2025-05-28 20:43:14

seth wrote:

It will be helpful to post the build log to see where and why it fails, but you might simply have to skip the patches for newer kernels?

Hi. Thank you for trying to help me.
I have kernel-lts510 installed since years, without related nvidia-390xx problems, so my question is, which patch(es) might be the one(s).
I was thinking it was related to recent gcc upgrades instead.

While having kernel-lts and kernel-lts510 installed at the same time I do find the make.log for kernel-lts' nvidia module but there is no folder for kernel-lts510 nvidia module created where i could find the make.log for that compilation. Any hints on that?

Last edited by boomshalek (2025-05-28 20:44:32)

seth · 2025-05-28 21:12:53

seth wrote:

It will be helpful to post the build log

boomshalek · 2025-05-30 17:07:07

My bad; I have used a user repository with precompiled lts510 as it takes more than 4 hours to compile the kernel on my system.
The repo package has not been updated for about 30 days.

After I had compiled lts510 today against all recent system packages myself, nvidia-390xx-dkms built and installed fine.

Sorry seth, thank you anyway!

drankinatty · 2025-05-31 16:52:31

@Seth, yes, I just finished looking over https://github.com/CachyOS/CachyOS-PKGBUILDS/...2d3dcd016 and that left me scratching my head a bit. It would be great if we can avoid changing any of the wrappers in kernel/comon/inc/nv-mm.h. I'm a bit concerned with ending up with a hybrid patch set. Some of Joan's patches, some from CachyOS, all blended together. The only reason I say that is then future patches for the 470 driver won't be a straight forward backport.

6.15 should hit testing shortly and we can see how it goes. Many thanks to @canolucs for getting the 6.15 patch. I look forward to testing it.

canolucas · 2025-06-05 23:53:20

@drankinatty
Ok so now the patch was been rewritten to match Joans function nomenclature.
Here is the latest version of ventureos patch: https://github.com/CachyOS/CachyOS-PKGB … 6.15.patch

So by using this patch we will be calling to our own wrapper functions, which in turn will call vm_flags_reset or vm_flags_set/vm_flags_clear based on the kernel version, this has some advantages:
* we will avoid breaking support for previous versions of the kernel
* we are now matching Joans codebase, so it will be much easier to merge future patches as well

when 6.15 hits the Core-Testing repo, I think that we are ready to test the patch in its current form. It looks good as far as I'm concerned.

canolucas · 2025-06-06 00:43:43

===
Please ignore this post
===

I think that the only portion of the original 6.3 patch that we are missing is adding the following check to conftest.sh

+diff --color -ur NVIDIA-Linux-x86_64-390.157-no-compat32.orig/kernel/conftest.sh NVIDIA-Linux-x86_64-390.157-no-compat32/kernel/conftest.sh
+--- NVIDIA-Linux-x86_64-390.157-no-compat32.orig/kernel/conftest.sh	2022-10-11 18:00:50.000000000 +0200
++++ NVIDIA-Linux-x86_64-390.157-no-compat32/kernel/conftest.sh	2023-05-27 21:33:14.502405255 +0200
+@@ -4646,6 +4646,25 @@
+ 
+             compile_check_conftest "$CODE" "NV_ACPI_VIDEO_BACKLIGHT_USE_NATIVE" "" "functions"
+         ;;
++
++        vm_area_struct_has_const_vm_flags)
++            #
++            # Determine if the 'vm_area_struct' structure has
++            # const 'vm_flags'.
++            #
++            # A union of '__vm_flags' and 'const vm_flags' was added 
++            # by commit bc292ab00f6c ("mm: introduce vma->vm_flags
++            # wrapper functions") in mm-stable branch (2023-02-09)
++            # of the akpm/mm maintainer tree.
++            #
++            CODE="
++            #include <linux/mm_types.h>
++            int conftest_vm_area_struct_has_const_vm_flags(void) {
++                return offsetof(struct vm_area_struct, __vm_flags);
++            }"
++
++            compile_check_conftest "$CODE" "NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS" "" "types"
++        ;;
+     esac
+ }
+

This would allow us to support even older kernel versions:

static inline void nv_vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
    // Since Linux 6.15, vm_flags_set and vm_flags_clear call a GPL-only symbol
    // for locking (__vma_start_write), which can't be called from non-GPL code.
    // However, it appears all uses on the driver are on VMAs being initially
    // mapped / which are already locked, so we can use vm_flags_reset, which
    // doesn't lock the VMA, but rather just asserts it is already write-locked.
    vm_flags_reset(vma, vma->vm_flags | flags);
#else
    #if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
        vm_flags_set(vma, flags);
    #else
        vma->vm_flags |= flags;
    #endif
#endif
}

static inline void nv_vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
    // See above
    vm_flags_reset(vma, vma->vm_flags & ~flags);
#else
    #if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
        vm_flags_clear(vma, flags);
    #else
        vma->vm_flags &= ~flags;
    #endif
#endif
}

This will support kernel version < 6.3.
Linux 6.3 is the kernel version in which the following patch was included:
mm: introduce vma->vm_flags wrapper functions

So, Linux 6.3 was the first kernel version in which:

* the vm_flags field was changed to be read-only.
* vm_flags_init, vm_flags_reset, vm_flags_set, vm_flags_clear and vm_flags_mod access functions were added.

Previous kernel versions would need the above code modifications to be able to modify the flags (flag set / flag clear) directly (it will be allowed without using the helper functions because in Linux versions prior to 6.3 the vm_flags field will not be read-only yet).

EDIT: Sorry there is no real need for doing this, we already define vm_flags_set / vm_flags_clear if needed

+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 3, 0)
+// Rel. commit "mm: introduce vma->vm_flags wrapper functions" (Suren Baghdasaryan, 26 Jan 2023)
+static inline void vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags |= flags;
+}
+
+static inline void vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags &= ~flags;
+}
+#endif
+

===
Please ignore this post
===

Last edited by canolucas (2025-06-12 23:14:40)

UpbeatBlacksmith · 2025-06-10 22:47:13

Hi guys, while upgrading my system, i broke my 390xx driver,

==> dkms install --no-depmod nvidia/390.157 -k 6.15.1-arch1-2

Error! Bad return status for module build on kernel: 6.15.1-arch1-2 (x86_64)
Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information.
==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.15.1-arch1-2' exited 10

This was the error that came, last time when this error came it was due to gcc-15 but this i dont think thats the reason this time, as i fixed it using gcc-15.patch.
I tried upgrading nvidia-390xx package but error was still there.

here is the make.log
https://justpaste.it/g4kcc

I think error is due to

 #include "nv-misc.h"

Here are the details of my system:
gcc : 15.1.1 20250425
linux : 6.15.1

Sorry if post it in wrong format, it was first time I'm asking question on ArchWiki
I hope somebody can help me

Edit: I find the problem is with the latest kernel, i installed linux-lts 6.12.32.1-lts, drivers were successfully builded
Edit 2: Fixied after kernel 6.15 patch

Last edited by UpbeatBlacksmith (2025-06-11 19:07:16)

Arch Linux

#176 2025-05-09 18:27:33

Re: nvidia-390xx AUR package discussion thread

#177 2025-05-09 19:14:16

Re: nvidia-390xx AUR package discussion thread

#178 2025-05-11 02:15:00

Re: nvidia-390xx AUR package discussion thread

#179 2025-05-13 02:03:49

Re: nvidia-390xx AUR package discussion thread

#180 2025-05-20 07:16:53

Re: nvidia-390xx AUR package discussion thread

#181 2025-05-21 02:32:26

Re: nvidia-390xx AUR package discussion thread

#182 2025-05-28 17:40:40

Re: nvidia-390xx AUR package discussion thread

#183 2025-05-28 18:25:46

Re: nvidia-390xx AUR package discussion thread

#184 2025-05-28 20:43:14

Re: nvidia-390xx AUR package discussion thread

#185 2025-05-28 21:12:53

Re: nvidia-390xx AUR package discussion thread

#186 2025-05-30 17:07:07

Re: nvidia-390xx AUR package discussion thread

#187 2025-05-31 16:52:31

Re: nvidia-390xx AUR package discussion thread

#188 2025-06-05 23:53:20

Re: nvidia-390xx AUR package discussion thread

#189 2025-06-06 00:43:43

Re: nvidia-390xx AUR package discussion thread

#190 2025-06-10 22:47:13

Re: nvidia-390xx AUR package discussion thread

Board footer