Package Details: nvidia-390xx-dkms 390.157-13

Git Clone URL: https://aur.archlinux.org/nvidia-390xx-utils.git (read-only, click to copy)
Package Base: nvidia-390xx-utils
Description: NVIDIA drivers - module sources
Upstream URL: https://www.nvidia.com/
Licenses: custom
Provides: NVIDIA-MODULE
Submitter: svenstaro
Maintainer: jonathon (vnctdj)
Last Packager: vnctdj
Votes: 60
Popularity: 2.69
First Submitted: 2020-03-11 17:29 (UTC)
Last Updated: 2024-11-25 23:34 (UTC)

Pinned Comments

jonathon commented on 2022-05-26 09:46 (UTC)

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

jonathon commented on 2021-12-26 22:44 (UTC) (edited on 2021-12-26 22:44 (UTC) by jonathon)

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?

jonathon commented on 2020-10-19 12:41 (UTC) (edited on 2021-05-11 14:18 (UTC) by jonathon)

PACKAGE NEEDS LONG TERM MAINTAINER

I have adopted the 390xx packages to keep them secure. I do not run any 390xx hardware so will not notice any breakages and cannot test any changes.

Until such time as someone else steps up to maintain these packages - ideally someone who actually has 390xx hardware - I have to rely on you to tell me what changes are needed.

Don't expect a response if you post only "this doesn't work", and do not email me to complain about the package not working!

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

A binary package is also available in my kernel-lts unofficial user repository.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 26 Next › Last »

LukeMe commented on 2024-05-18 19:39 (UTC)

if it can be of any help, the patch posted by drankinatty does work with both the latest linux and linux-lts kernels

canolucas commented on 2024-05-18 14:43 (UTC) (edited on 2024-05-18 14:44 (UTC) by canolucas)

@drankinatty does this driver work applying only the gcc-14 patch ? Is that case, maybe we can avoid using -fpermissive to make the maintainance easier in the future. I agree that it can be tedious to rely on enabling and disabling this flag for debugging future kernel updates. I would add -fpermissive as a last resort, only if there is no other alternative.

drankinatty commented on 2024-05-18 00:39 (UTC)

Building with both patches worked flawlessly. The 6.9.1 hit today, the dkms module rebuild went without issue and the Nvidia driver is happy (of course Virtualbox broke -- but you can't win them all...)

I incorporated both the original gcc-14 patch (largely unneeded now that -fpermissive was added by the kernel-6.9.patch), and the kernel-6.9.patch, as shown below and it worked fine.

Thanks to @canolucas for the kernel-6.9.patch.

drankinatty commented on 2024-05-17 15:25 (UTC)

The good news, as with you, with both patches (the gcc-14.patch) and the kernel-6.9.patch, the driver build is fine for both the current 6.8.9 and 6.6.30 LTS kernels. All we need now is the 6.9 kernel to see if that holds true on reboot after update.

Long term -fpermissive is a Bandaid that we will have to deal with at some time. We will need to remove it, let the build fail, get a good log and then develop a proper patch that brings the 390.xx code up to build in the current environment. I had to do that once for KDE with the kernel-4.6 changes way back when in the 2011? timeframe. Just tedious...

canolucas commented on 2024-05-17 04:35 (UTC) (edited on 2024-05-17 04:42 (UTC) by canolucas)

@drankinatty you are right, the patch posted by @rodrigorc is missing the changes in conftest.sh however this package built fine anyways.

From what I see in the docs:

-fpermissive

Downgrades some diagnostics about nonconformant code from errors to warnings.

https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/C_002b_002b-Dialect-Options.html#index-fpermissive-140

-Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-incompatible-pointer-types

Suppresses different types of warnings

So I guess all these flags are meant to work together to: First, convert the errors to warnings and secondly supress those warnings.

drankinatty commented on 2024-05-17 01:57 (UTC) (edited on 2024-05-17 02:17 (UTC) by drankinatty)

@canolucas Thank You! We will give it a go. I'd just posted about the code formatting -- but you fixed it while I was typing :)

Does this patch replace (incorporate) the gcc-14 patch as well? (I mean it is, but it is in a different form than the original -- so do we just toss the earlier patch used for gcc-14?)

I guess the answer is No since they appear to affect different parts of conftest.sh. I have the following as the original gcc-14 patch:


--- a/kernel/conftest.sh
+++ b/kernel/conftest.sh
@@ -153,7 +153,8 @@ test_headers() {
 build_cflags() {
     BASE_CFLAGS="-O2 -D__KERNEL__ \
 -DKBUILD_BASENAME=\"#conftest$$\" -DKBUILD_MODNAME=\"#conftest$$\" \
--nostdinc -isystem $ISYSTEM"
+-nostdinc -isystem $ISYSTEM \
+-Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-incompatible-pointer-types"

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

canolucas commented on 2024-05-17 01:45 (UTC) (edited on 2024-05-17 01:50 (UTC) by canolucas)

@vnctdj the patch posted by rodrigorc looks fine to me. Please tell us what you think and if it can be added to the PKGBUILD so we can test it against v6.9 of the kernel ?

Looks like the gcc 14 patch is the only patch needed for this driver to work with the new kernel, but when the new PKGBUILD is ready I'm sure we will give it a good test run to discard any compatibility issues.

--- a/kernel/Kbuild
+++ b/kernel/Kbuild
@@ -63,7 +63,7 @@

 EXTRA_CFLAGS += -I$(src)/common/inc
 EXTRA_CFLAGS += -I$(src)
-EXTRA_CFLAGS += -Wall -MD $(DEFINES) $(INCLUDES) -Wsign-compare -Wno-cast-qual -Wno-error
+EXTRA_CFLAGS += -Wall -MD $(DEFINES) $(INCLUDES) -Wsign-compare -Wno-cast-qual -Wno-error -fpermissive
 EXTRA_CFLAGS += -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"390.157\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -DNV_UVM_ENABLE -Wno-sign-compare -Wno-format-extra-args
 EXTRA_CFLAGS += $(call cc-option,-Werror=undef,)
 EXTRA_CFLAGS += -DNV_SPECTRE_V2=$(NV_SPECTRE_V2)
@@ -101,7 +101,9 @@
 NV_CONFTEST_CMD := /bin/sh $(NV_CONFTEST_SCRIPT) \
  "$(CC)" "$(HOST_CC)" $(ARCH) $(NV_KERNEL_SOURCES) $(NV_KERNEL_OUTPUT)

-NV_CONFTEST_CFLAGS := $(shell $(NV_CONFTEST_CMD) build_cflags)
+NV_CFLAGS_FROM_CONFTEST := $(shell $(NV_CONFTEST_CMD) build_cflags)
+
+NV_CONFTEST_CFLAGS = $(NV_CFLAGS_FROM_CONFTEST) $(EXTRA_CFLAGS) -fno-pie

 NV_CONFTEST_COMPILE_TEST_HEADERS := $(obj)/conftest/macros.h
 NV_CONFTEST_COMPILE_TEST_HEADERS += $(obj)/conftest/functions.h

drankinatty commented on 2024-05-15 18:09 (UTC) (edited on 2024-05-16 20:28 (UTC) by drankinatty)

It is official, the linux-6.9.1 package hit the core-testing repo at noon today. The only patches I have found are initial support patches for 6.9 for Cachyos that are a couple of months old at that point, e.g. https://github.com/CachyOS/kernel-patches/blob/master/6.9/misc/nvidia/ I doubt those will be complete and will need to be cherry picked for 470 and 390 if applicable.

Good news is it looks like it is just the GCC-14 patch that is needed, so there may be no other breakage by the kernel update from 6.8 - 6.9. Here is the nvidia forum link: https://forums.developer.nvidia.com/t/nvidia-modules-470-239-06-build-failure-with-gcc-14-due-to-conftest-sh/292645

This was referenced from a Slackware thread about failure to build with the 6.9 kernel. https://www.linuxquestions.org/questions/slackware-14/new-kernel-6-9-0-and-nvidia-drivers-4175737070/

sfranchi commented on 2024-05-15 09:43 (UTC)

@Minty95 I use the linux-zen kernel, so I added the following line to pacman.conf

IgnorePkg = linux-zen linux-zen-headers

Remove the "-zen" part of the names if you use the standard kernel