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 will need help with this patch. I've attempted to adapt the gcc-15 patch 470xx driver, but there were API changes between the 390 and 470 drivers where for instance vm_flags_reset(vma, vma->vm_flags & ~flags); doesn't exist at all in the 390 driver in nv-mm.h. Additionally, for the module naming strings, the file nvidia-uvm/uvm.c doesn't exist in the 390 driver either.

I have put the attempted gcc-15.patch (non-working) to see if anyone can begin there and make progress. The attempted patch applies fine and the new packages build and can be installed -- but they produce no working driver due to the issues noted above. This could be a fun one....

After upgrading to gcc15 the driver cannot be compiled, downgrading the linux, linux-headers, gcc, gcc-libs packages helps temporary.

That is odd, the download works fine, sorry for the confusion. What exactly did you "work around" that is allowing it to build fine? I've not had any issues yet.

My build script is hitting some circular dependency for nvidia-390xx-utils itself and recursing until the build job times out. Is this intended design in the depends= variables?

I've added a check to my build script to work around circular dependencies and it seems to be building just fine now.

6.14 patch is now included, thanks again for your early tests guys! :)

@air-g4p ... not like I've never done anything like that myself ...

@drankinatty - Thank you for taking the time to correctly identify my made in haste 'failure to apply' oversight.

Completely understood on the potential 390 and 470 Wayland issues.

The correctly edited PKGBUILD with the kernel-6.14.patch builds, installs and operates correctly against the 6.14-X linux and linux-zen kernels.

@vnctd - Given the above, please consider incorporating the 6.14 patch.

Cheers

@air-g4p, the error:

nvidia-drm/nvidia-drm-drv.c:761:6: error: ‘struct drm_driver’ has no member named ‘date’
  761 |     .date                   = "20160202",
      |      ^~~~
nvidia-drm/nvidia-drm-drv.c:761:31: error: initialization of ‘unsigned int’ from ‘char *’ makes integer from pointer without a cast [-Wint-conversion]
  761 |     .date                   = "20160202",
      |                               ^~~~~~~~~~

Suggests that the 6.14 patch was NOT actually applied in your PKGBUILD. If you look at the patch, it's job is to remove the .date member from the struct by wrapping it in #if LINUX_VERSION_CODE < KERNEL_VERSION(6, 14, 0) ... #endif to only make the .date member available for kernels < 6.14. Did you add the patch as a source but forget to apply it?, e.g.

    # Adapted from https://gist.github.com/joanbm/d0cb8790ca610fbd2c2e43f30707ce18
    printf "\n** kernel-6.14 patch**\n\n"
    patch -Np1 -i ../kernel-6.14.patch

Double check your PKGBUILD and I'll double check for any further patches needed.

Update

There are no further patches to the 470 driver to backport to the 390 driver. Remember Wayland use with the 390 and 470 driver was not something the drivers supported as Wayland was just beginning to show up in Linux when the 470 driver was released, much less when then 390 driver was released. As long as x-compatibility is preserved in Wayland, it should run, but any special Wayland feature is likely not implemented in either the 470 or 390 drivers.

@drankinatty - Thank you for your 6-14 efforts to date.

1. I use Wayland
2. I appended the kernel-6.14.patch to the current PKGBUILD without removing the kernel-6.13.patch
3. The build failed against 6.14 linux-zen this way:

https://paste.rs/xQe7A

Please let me know if you understand why it failed.

I am willing to test alternative solutions.

Cheers

@canolucas I'm really on the fence about this. I'm not sure why the openSUSE build needed to revert the kernel-6.13.patch. I have not reverted it on Arch and there are no problems. I'm a bit confused about why the 6-13 KBuild patch for absolute paths for link creation would ever need to be reverted, but, that's not to say some interplay with the normal kernel files hasn't/won't make that unnecessary.

The openSUSE driver build is a bit strange. The 390xx driver is an actual supported package by openSUSE. Sometimes they are slow updating the legacy drivers on the Nvidia site, so I end up patching and building. What that also means is that their build (which isn't always available to check what it contains) may contain their own patch that duplicates my kernel-6.13.patch (which I suspect is what happened there leading to my earlier suggestion that it may need to be removed).

Currently 6.14 is in testing so I expect that any day. For Arch, I've left the 6.13 patch and added the 6.14 patch and that is what I'm running currently with the 6.13.8 kernel so nothing has changed on Arch that says you need to remove the 6.13 patch. I haven't seen any patch from https://gist.github.com/joanbm/ that wasn't needed, so I would leave the 6.13 patch. There has been no similar issue to openSUSE causing any problem on Arch -- which makes me suspect the only reason it was removed from the openSUSE build is that it ended up being applied twice when the the official maintainer added their own patch to the official package that contained the same changes.