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?

Updated - original was the 535 patch -- the edit below is the 390xx rewrite

Okay, I have the patch, rewritten from the Herecura 535 patch for 390xx, nvidia-390xx-utils built, 6.10 kernel installed -- and it works like a champ.

The patch

diff -ruNb a/kernel/conftest.sh b/kernel/conftest.sh
--- a/kernel/conftest.sh        2024-07-19 04:36:26.183701185 -0500
+++ b/kernel/conftest.sh        2024-07-19 04:36:26.230366381 -0500
@@ -4464,20 +4464,22 @@
             compile_check_conftest "$CODE" "NV_DRM_GEM_OBJECT_VMAP_HAS_MAP_ARG" "" "types"
         ;;

-        unsafe_follow_pfn)
+        follow_pfn)
             #
-            # Determine if unsafe_follow_pfn() is present.
+            # Determine if follow_pfn() is present.
             #
-            # unsafe_follow_pfn() was added by commit 69bacee7f9ad
-            # ("mm: Add unsafe_follow_pfn") in v5.13-rc1.
+            # follow_pfn() was added by commit 3b6748e2dd69
+            # ("mm: introduce follow_pfn()") in v2.6.31-rc1, and removed
+            # by commit 233eb0bf3b94 ("mm: remove follow_pfn")
+            # from linux-next 233eb0bf3b94.
             #
             CODE="
             #include <linux/mm.h>
-            void conftest_unsafe_follow_pfn(void) {
-                unsafe_follow_pfn();
+            void conftest_follow_pfn(void) {
+                follow_pfn();
             }"

-            compile_check_conftest "$CODE" "NV_UNSAFE_FOLLOW_PFN_PRESENT" "" "functions"
+            compile_check_conftest "$CODE" "NV_FOLLOW_PFN_PRESENT" "" "functions"
         ;;

         drm_plane_atomic_check_has_atomic_state_arg)
diff -ruNb a/kernel/nvidia/nvidia.Kbuild b/kernel/nvidia/nvidia.Kbuild
--- a/kernel/nvidia/nvidia.Kbuild       2022-10-12 04:29:57.000000000 -0500
+++ b/kernel/nvidia/nvidia.Kbuild       2024-07-19 05:17:39.148448922 -0500
@@ -165,7 +165,7 @@
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += ktime_get_real_ts64
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += ioremap_nocache
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += vga_tryget
-NV_CONFTEST_FUNCTION_COMPILE_TESTS += unsafe_follow_pfn
+NV_CONFTEST_FUNCTION_COMPILE_TESTS += follow_pfn
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += acpi_bus_get_device
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += acpi_video_backlight_use_native

diff -ruNb a/kernel/nvidia/os-mlock.c b/kernel/nvidia/os-mlock.c
--- a/kernel/nvidia/os-mlock.c  2022-10-12 04:30:26.000000000 -0500
+++ b/kernel/nvidia/os-mlock.c  2024-07-19 04:36:26.230366381 -0500
@@ -18,10 +18,10 @@
                                 unsigned long address,
                                 unsigned long *pfn)
 {
-#if defined(NV_UNSAFE_FOLLOW_PFN_PRESENT)
-    return unsafe_follow_pfn(vma, address, pfn);
-#else
+#if defined(NV_FOLLOW_PFN_PRESENT)
     return follow_pfn(vma, address, pfn);
+#else
+    return -1;
 #endif
 }

Give it a shot.

I see 6.10 is now out. I've yet to locate a patch (and I've looked, but by search foo is failing me). I haven't attempted the update, but apparently somebody flagged the package as out of date on the 17th, so there must be issues. (my 390xx is in a production server, so it makes it a bit difficult to knock people offline simply to test)

It would have been helpful it the person flagging could have left error messages to give us more to add to our patch search.

If no word and no luck on the search, I'll go ahead and do the update on the server and go from there. I'll post the error messages here when I do. Worse-case scenario, I'll drop to LTS while we work on a patch.

Hah, normal spot has 535 driver patch that may work for 390, e.g. Herecura linux-6.10.patch I haven't tested yet.

We will need to adjust the nvidia.Kbuild patch, e.g.

** kernel-6.10 patch**

patching file kernel/conftest.sh
Hunk #1 succeeded at 4464 with fuzz 1 (offset -717 lines).
patching file kernel/nvidia/nvidia.Kbuild
Hunk #1 FAILED at 161.
1 out of 1 hunk FAILED -- saving rejects to file kernel/nvidia/nvidia.Kbuild.rej
patching file kernel/nvidia/os-mlock.c
Hunk #1 succeeded at 18 (offset -18 lines).

Linux 6.10 is upon us. Any try building against it to see if a further patch is needed? Not yet in the testing repo, but we can count on seeing it within the next 10 days or so. The changes for 6.10 do not look that significant, so no telling if it will require a patch (though better safe than stuck...)

So far this vague kernel patch (not driver patch) is all I've come up with: NVIDIA proprietary driver on 6.10-RC2 kernel build error

And one other referencing the same issue: 550.78 won't compile on 6.10-rc1 due to GPL violations No telling if these will impact the 390 build, but usually patches flow downhill.

I've added the fix mentioned by duht, thanks!

@duht agreed, i wasn't getting the problem when starting my WM through sddm but with startx did still run into the freeze, the fix you mention works.

@vnctdj please add fix added in current nvidia-utils from extra link.

@loup correkt me if I'm wrong: You are using up-to-date Arch with systemd v256 and this NVIDIA drivers with rodrigorc patch and you can suspend/hibernate your laptop without any issues? That is correct?

@duht Thank's for such a nice comment ! As i said " i am way over my head on this " For the answer to your question i do not have a problem =1 + i am using rodrigorc patch =1 total 2 you have a problem = 0 you are using another patch = 1 total 1 ....... 2 being grater than 1, i would at least try.

By the way github systemd readme note specificy at line 224 that gcc is required to bild systemd. link:https://github.com/systemd/systemd/blob/main/README From rodrogorc link: https://gcc.gnu.org/gcc-14/porting_to.html the section title: Turning errors back into warnings is from where i am coming from.

@loup what are you talking about? We're talking about "fix for systemd 256 suspend/hibernate issues" not about gcc-14/rodrigorc patch that was added over a month ago to this package...
@vnctdj they fixed it in current nvidia-utils from extra link.

@ duht

Hi, maybe for the time being until vnctdj answer your request, you could test rodrigorc patch. I am using this patch since kernel 6.9 without any problem at all. I am way over my head on this, but i suspect that his approach could solve your problem.

Good luck