Arch Linux User Repository

Use this forum thread for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1946926

Please don't flag this package out-of-date unless a new version has been released by NVIDIA.

The DKMS package guidelines are explicit that linux-headers should not be a dependency of any DKMS package.

As a concrete example of why including that as a hard dependency is a bad idea, what happens when linux is not an installed kernel?

I've just added gcc-15.patch from bufferunderrun.

Thanks to all of you who took part in patch research and testing!

just to add one more confirmation: after adding gcc-15.patch the build works perfectly here, many thanks for your work! -s

gcc-15.patch worked fine here as well. So, it seems we can add that patch to the package right ?

Considering:

* package is broken in its current state

* the patch is required for this package to be compatible with archlinux's current version of gcc

I just used the patch gcc-15.patch of bufferunderrun here and upgrading to kernel 6.14.5-arch1-1 and gcc-15 was successful.

I could be missing something obvious,

Of course I'd forgotten to the patch entry to prepare(). Thanks @bufferunderrun.

And sorry to everyone else for the spam. Incredible work with the patches, investigations and brainstorming.

I assume you added it with a relative path and it's not adding the patch. This should work:

patch -Np1 -i "${srcdir}/gcc-15.patch" -d "${srcdir}/${_pkg}"

No issues with linux 6.14.5

EDIT: I used makepkg -sifc

I could be missing something obvious, since I normally use paru and haven't done this manually recently.

1. Downloaded the content of gcc-15.patch from @bufferunderrun, with and without the addition from @drankinatty.

2. Modified PKGBUILD

3. updpkgsums

4. makepkg -sic

pacman "succeeded", but dkms install --no-depmod nvidia/390.157 -k 6.14.4-arch1-2 exited 10. In the make.log, there were a lot of issues with conftest.sh. A snippet from ~600 lines is given below:

In file included from ././common/inc/conftest.h:5,
                 from ././common/inc/nv_stdarg.h:29,
                 from ././common/inc/os-interface.h:27,
                 from nvidia/nv-frontend.c:12:
././conftest/functions.h:15:2: error: #error kmem_cache_create() conftest failed!
   15 | #error kmem_cache_create() conftest failed!
      |  ^~~~~
././conftest/functions.h:16:2: error: #error on_each_cpu() conftest failed!
   16 | #error on_each_cpu() conftest failed!
      |  ^~~~~
././conftest/functions.h:17:2: error: #error smp_call_function() conftest failed!
   17 | #error smp_call_function() conftest failed!
      |  ^~~~~
././conftest/functions.h:22:2: error: #error acpi_walk_namespace() conftest failed!
   22 | #error acpi_walk_namespace() conftest failed!
      |  ^~~~~
././conftest/functions.h:24:2: error: #error dma_mapping_error() conftest failed!
   24 | #error dma_mapping_error() conftest failed!
      |  ^~~~~
././conftest/functions.h:71:2: error: #error wait_on_bit_lock() conftest failed!
   71 | #error wait_on_bit_lock() conftest failed!
      |  ^~~~~
././conftest/functions.h:76:2: error: #error radix_tree_replace_slot() conftest failed!
   76 | #error radix_tree_replace_slot() conftest failed!
      |  ^~~~~

Does anyone know what could be wrong?

I have put a write-up on The bbs.archlinux.org discussion page outlining where I think the 6.15 kernel problem will be. If you can take a look and add any thoughts you have on the differences with the 390 driver common/inc/nv-mm.h and how to backport the patch from the 470 driver to that file -- that is where I'm stuck.

I should add that kernel 6.15 will drop EXTRA_CFLAGS backward compatibility, so one would need to switch to ccflags-y when it's out. But judging from drankinatty's comments 6.15 will break quite a few other things, so people should prepare for a bumpy ride.

The 6.15 and gcc-15 was a mix-up. @bufferunderrun probably has the better location for adding the -std=gnu17 option. I stumbled on it at Nvidia building with gcc-15 fails. I also added the -Wno-int-conversion option from the Fedora make.log error and combined both in conftest.sh, e.g.

--- a/kernel/conftest.sh        2025-05-02 22:11:41.841797003 -0500
+++ b/kernel/conftest.sh        2025-05-04 19:32:38.569127659 -0500
@@ -151,10 +151,11 @@
 }

 build_cflags() {
-    BASE_CFLAGS="-O2 -D__KERNEL__ \
+    BASE_CFLAGS="-O2 -D__KERNEL__ -std=gnu17 \
 -DKBUILD_BASENAME=\"#conftest$$\" -DKBUILD_MODNAME=\"#conftest$$\" \
 -nostdinc -isystem $ISYSTEM \
--Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-incompatible-pointer-types"
+-Wno-implicit-function-declaration -Wno-strict-prototypes \
+-Wno-incompatible-pointer-types -Wno-int-conversion"

     if [ "$OUTPUT" != "$SOURCES" ]; then
         OUTPUT_CFLAGS="-I$OUTPUT/include2 -I$OUTPUT/include"

This builds and the dkms modules build fine with gcc-15 and linux-6.14. I'll let the smarter folks decide where the option should go. I tend to like Kbuild as @bufferoverrun did, but we should also look at including -Wno-int-conversion as looks like a future issue as well. But we likely don't need it in both BASE_CFLAGS and EXTRA_CFLAGS. So I guess the deciding factor comes down to whether you consider -std=gnu17 a BASE or EXTRA flag.

But looking at the linux-6.15 requirements kernel/common/inc/nv-mm.h changes appear a bit more involved. It may end up not being as bad as I image. The core issue is the 470 driver uses a nv_vm_flags_xxx naming convention while the 390 driver was never updated from get_user_pages_xxx function names. The 470 linux-6.15 patch uses vm_flags_reset(vma, vma->vm_flags | flags); as part of the nv_vm_flags_set() function to avoid the now prohibited kernel file locks from the driver. vm_flags_reset() is provided by ../linux/mm.h so it is available to the 390 driver, but how/where it must be integrated is unclear given the driver differences and the 390 driver having no nv_vm_flags_set(). We will cross that bridge when we get there.