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?

Almost time for linux-7.0

It looks like we should plan on seeing the linux-7.0 kernel released April 12, barring any extension of time. (the Arch package may be a week or so later) So far there is nothing new on Joan's patch page, and looking at the changes, other than more DRM changes, nothing sticks out as definitely causing issues for the driver. (hard to tell if a name change or change to a define will cause issues until it arrives). Drop a comment in you come across information that identifies any needed changes for the upcoming kernel.

Update - Found Joan's 470 Patch

I did find Joan's nvidia-470xx-fix-linux-7.0.patch, which thankfully doesn't look too bad. We'll see if this is an area of code where the 390 and 470 drivers are the same, or one of those odd areas where they look nothing alike. But so for, the 7.0 kernel has not entered the testing repo for Arch, so we should have at least another week.

470/390 Difference to Reconcile

The nv-linux.h and nvidia-dma-fence-helper.h changes map nicely into the 390 driver. However, all of the screen_info changes don't. Close, but enough different that it may take a couple of us to figure it out. The big difference is the 470 driver code is in nv.c and it involves a NV_CHECK_EXPORT_SYMBOL(screen_info) macro not present in the 390 code. Additionally, the 390 driver places the screen_info code in os-interface.c instead of nv.c.

There are minor C differences in whether checks of > or <= apply in the if (screen_info.orig_video_isVGA <= 1) block, but that's just a rearranging and negating of the test. The confusing part is the macro checks are code-inclusion checks which leaves the new #if (LINUX_VERSION_CODE >= KERNEL_VERSION(6, 20, 0)) || \ inclusion without a terminating #endif. I think the route we will have to take is to just create two blocks in os-interface.c, one to handle the existing kernels and one to handle linux 7.0. This is where I could use help/ideas from others involved. How best to incorporate the change from using the screen_info struct to using the si pointer to it? Ideas?

I've just added the patch, thanks guys for your work : drankinatty and loqs for analyzing the problem, canolucas for the test :)

I tested kernel-6.18-nv_workqueue_flush.patch by @drankinatty and it works fine here as well. Is it possible to add the patch to the PKGBUILD ? It improves stability and avoids kernel crashes on shutdown/reboot, it should also improve stability after suspension/hibernation

Shutdown Issue

All, we may have a shutdown hang related to the driver that we need to look at. I've noticed, but not really drilled down on (correction, the 90 sec delay is not related to the Nvidia driver, it was NUT). The issue is the system-wide flush that the driver uses on shutdown/removal of the driver.

Checking the journal, there is a kernel crash related to Xorg and the nvidia driver. I've put the journal entries here Arch nvidia-390xx-utils/Xorg shutdown crash. The start of the kernel crash indicates WARNING: Flushing system-wide workqueues will be prohibited in near future. and then in the call-trace you have os_flush_work_queue+0x41/0x60 [nvidia 0f3cb87a613037cd37443fc0f9e701834c4ef2b7]...

Has anyone else noticed this? I'm not great at reading kernel call-traces from the journal, so I don't know if it's the driver causing the crash, or simply it being flagged as the taint, but it sure looks like Xorg/nvidia is calling for a flush that the kernel doesn't like. It may just apply to the AMD processor/Nvidia 560 card I've got, but if anybody else is seeing this, we probably need to solve it.

Thankfully this is on shutdown, the driver is working well otherwise. Thoughts?

forum thread to investigate

I have opened a forum issues to track and discuss this matter Xorg signal 6/ABRT on shutdown, Flushing workques (legacy Nvidia). Please feel free to jump in there. (looks like we may have a solution to the shutdown flush crash, will test this week and report back)

patch created and ready for testing in the forum thread

I have created a patch to make the system-wide flush of workqueues a noop for kernels 16.8 and later (it's part of the forum link above). If you get a chance, test and let me know. I'll do the same and report back (have to wait until late at night to reboot the server)

patch test results -- success, no more stack dump on shutdown driver removal

Testing the patch to remove system-wide workqueue flush on shutdown is a success. The stack dump/call-trace no longer occurs on driver unload and the Xorg error is eliminated.

PKGBUILD change

source=('nvidia-drm-outputclass.conf'
        ...
        kernel-6.18-nv_workqueue_flush.patch
        kernel-4.16+-memory-encryption.patch)
...
    # developed to eliminate call to system-wide workqueue flush on shutdown causing
    # stackdump and call-trace.
    #   https://bbs.archlinux.org/viewtopic.php?id=312658
    patch -Np1 -i ../kernel-6.18-nv_workqueue_flush.patch

And the patch:

diff -ruNb a/kernel/common/inc/nv-linux.h b/kernel/common/inc/nv-linux.h
--- a/kernel/common/inc/nv-linux.h      2026-03-08 13:24:42.740759537 -0500
+++ b/kernel/common/inc/nv-linux.h      2026-03-16 20:05:14.506496123 -0500
@@ -1129,7 +1129,21 @@
 {
     (void)arg;
 }
-#define NV_KMEM_CACHE_DESTROY_FLUSH flush_scheduled_work
+
+/*
+ * On Linux, beginning with kernel 6.18 flushing system-wide workqueues was
+ * removed resulting in a stack dump on driver shutdown and removal. The
+ * following additions eliminate the system-wide workqueue flush on
+ * shutdown by making call to NV_KMEM_CACHE_DESTROY_FLUSH a noop for kenrels
+ * 6.18 and later. (below and at line 1541 for NV_WORKQUEUE_FLUSH)
+ *
+ * See discussion: https://bbs.archlinux.org/viewtopic.php?id=312658
+ */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 18, 0)
+    #define NV_KMEM_CACHE_DESTROY_FLUSH ((void)0)
+#else
+    #define NV_KMEM_CACHE_DESTROY_FLUSH flush_scheduled_work
+#endif
 #else
 #define nv_kmem_ctor_dummy NULL
 #define NV_KMEM_CACHE_DESTROY_FLUSH()
@@ -1524,8 +1538,14 @@
 } nv_work_t;

 #define NV_WORKQUEUE_SCHEDULE(work) schedule_work(work)
+/* system-wide workqueue flust removal, cont. from 1151 */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 18, 0)
+#define NV_WORKQUEUE_FLUSH() do { } while (0)
+#else
 #define NV_WORKQUEUE_FLUSH()                           \
     flush_scheduled_work();
+#endif
+
 #if (NV_INIT_WORK_ARGUMENT_COUNT == 2)
 #define NV_WORKQUEUE_INIT(tq,handler,data)             \
     {                                                  \

Test and provide feedback. (note when you build/install the updated driver, the system is still running on the old until you reboot or manually unload old/load new -- easy way, install, reboot to load new module, reboot to test elimination of flush stack dump) I propose the addition of the kernel-6.18-nv_workqueue_flush.patch. Cleans up driver shutdown since system-wide workqueue flush was removed from the kernel and eliminates the stack dump from the journal.

Success

The updated package by @vnctdj is up and running on 6.19.6-arch1-1. Modules built fine on running 6.18 kernel, updated the nvidia-390xx-utils packages, then system update to 6.19 and rebooted, and lightdm is happily up and running on the 390xx driver. (LTS Moved to 6.18.16, I haven't tried booting it yet)

Thanks to @vnctdj, @canolucas and @Wargoth and all that helped. Sorry I didn't have more time this go round.

I just pushed an updated version of the patch that incorporates Wargoth's changes.

Thanks to Wargoth, of course, but also to drankinatty and canolucas for your testing!

Fixed the kernel-6.19.patch — now DKMS builds successfully on kernel 6.19. https://pastebin.com/Rhdy9KHe

Ok, so Linux 6.19 just arrived in the [core-testing] repo. As usual, I enabled the repo and ran the following command to update the relevant packages:

pacman -S linux linux-headers linux-firmware

However, DKMS fails when trying to build this package against the new kernel.

Here is the make.log: https://paste.opensuse.org/pastes/728f8044ea99

For now, I downgraded linux and linux-headers to the latest working version:

pacman -U /var/cache/pacman/pkg/linux-6.18.13.arch1-1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/linux-headers-6.18.13.arch1-1-x86_64.pkg.tar.zst

After downgrading, everything works normally again and the driver builds without issues.

In the log file there are several warnings, but the relevant error seems to be:

nvidia/os-interface.c: En la función ‘os_delay_us’:
nvidia/os-interface.c:513:9: error: declaración implícita de la función ‘in_irq’ [-Wimplicit-function-declaration]
  513 |     if (in_irq() && (MicroSeconds > NV_MAX_ISR_DELAY_US))
      |         ^~~~~~

(Sorry the log is in Spanish.)

It looks like the function in_irq() is no longer declared in kernel 6.19. Possibly it was replaced by in_hardirq(), since there were already attempts to replace in_irq() with in_hardirq() in Joan's patches.

So this line in nvidia/os-interface.c:

if (in_irq() && (MicroSeconds > NV_MAX_ISR_DELAY_US))

Needs to be replaced with:

if (in_hardirq() && (MicroSeconds > NV_MAX_ISR_DELAY_US))

There may also be other occurrences that need to be updated.

Edit: I just noticed the openSUSE patch posted by @drankinatty. It looks like they also replaced in_irq() with in_hardirq() and added:

#include <linux/hardirq.h>

So it seems all in_irq() calls may need to be replaced.

Patch reference: https://build.opensuse.org/projects/X11:Drivers:Video/packages/nvidia-gfxG04/files/kernel-6.19.patch?expand=1

I’m available to test again once the PKGBUILD is updated.

Hey guys, I'm waiting for 6.19 to hit the testing repo. I'll let you know if the driver works with the new kernel ASAP. If somebody has time to compile 6.19 sooner, please let us know. The patch looks good, hopefully it will compile and boot.

Update

I've run into an issue in the nvidia-drm-modeset.c file and I've got a Mayday e-mail sent to the SUSE/openSUSE 390 maintainer to see how he handled the issue. The problem is there is no equivalent code in our 390xx nvidia-drm-modeset.c file for the changes in Joan's patch. Essentially the static bool __will_generate_flip_event(...) function that Joan patches does not exist in our 390xx code. It looks like a helper function that was added to help remove the nv_drm (the purpose of this whole patch-cycle), but I haven't figured the logic out yet.

All suggestions welcome. I'll go back to the 470xx code and see if I can find where this rabbit-trail begins.

Very different patch used by openSUSE

As we work though this, the smart maintainer at openSUSE passed along the changes for 6.19 for the openSUSE 390 driver It takes a different approach to accomplish the same changes. We may end up with a mix, unless the patch from @vnctdj already solves the issues with for our code. Let me know if the current patch works (no 6.19 to test -- yet)

Wait, does the patch @vnctdj put together handle this already?

It looks like it does. Can anybody confirm? I don't have an Arch box with 6.19 yet, but the patch handles the issue above simply by adding the struct drm_crtc_state *new_crtc_state pointer. If all is well, then I'll quit chasing my tail on this patch. Let me know.

Testing @vnctdj Patch with Current and LTS kernels - All Good

While we still need the test with the 6.19 kernel, the patch @vnctdj provided works with the current (6.18.13) and LTS (6.12.74) building without issue. If anybody has a test on the 6.19 kernel, let us know.