Keeping Pascal Alive: Patching NVIDIA 580 DKMS for Linux Kernel 7.2+

thecrazygm(75)

Published in

Synergy Builders

Words

1031

Reading

5 min

Listen

Play

10h

Hey everyone,

If you are running a Linux workstation or server with a Pascal-generation GPU (like a GTX 1060, 1070, 1080, or 1080 Ti) alongside bleeding-edge kernels, you might have hit a brick wall recently.

A few days ago, XanMod pushed out Linux kernel 7.2.4. As usual, apt upgrade grabbed the new kernel and headers, triggered DKMS, and immediately blew up with:

Error! Bad return status for module build on kernel: 7.2.4-x64v3-xanmod1 (x86_64)
Consult /var/lib/dkms/nvidia/580.142/build/make.log for more information.

No module built, no driver signed, and an unbootable graphical session waiting on the other side of a reboot.

If you are running modern cards (RTX 20-series and newer), the standard advice is simple: just bump to the latest driver branch. But if you are holding onto Pascal silicon, that option does not exist.

Here is what broke in kernel 7.2, why legacy drivers are caught in the crossfire, and how to patch the nvidia-580 source to get your modules compiling and running cleanly.

The Hardware Dilemma: The Pascal Trap

First, some context on why this is even a problem.

NVIDIA officially dropped support for Pascal GPUs starting in the 595 driver branch. If you install 595 with a GTX 1080, the driver loads, acknowledges the card's existence, and explicitly refuses to initialize it.

That means anyone on Pascal is effectively pinned to the legacy 580.xx branch.

In an ideal world, when a new major kernel drops, NVIDIA backports compatibility patches to all active legacy branches, distro maintainers package them up, and everything "just works."

In the real world, upstream Linux kernel refactoring moves fast, XanMod and Arch track mainline closely, and legacy proprietary driver packages lag behind. If you want to run the newest kernel right now, you have to patch the driver source yourself.

What Broke in Linux 7.2

Digging through /var/lib/dkms/nvidia/580.142/build/make.log revealed two distinct breaking changes introduced in Linux 7.2:

1. `strncpy` Was Completely Removed

The Linux kernel has been slowly deprecating unsafe string functions for years in favor of strscpy. In Linux 7.2, kernel developers finally pulled the trigger: strncpy was purged entirely from include/linux/string.h and the kernel's exported symbols.

Unfortunately, nvidia-580.142 still has calls to strncpy scattered across multiple components: core driver code, display modesetting, and the Unified Virtual Memory (nvidia-uvm) module. With the kernel header no longer declaring the prototype, the compiler treats it as an error or fails at link time.

2. DRM Atomic State Was Renamed to Atomic Commit

The Direct Rendering Manager (DRM) subsystem in Linux 7.2 underwent a refactor around atomic modesetting. Specifically:

struct drm_atomic_state was renamed to struct drm_atomic_commit.
The corresponding state management functions (drm_atomic_state_alloc, drm_atomic_state_clear, drm_atomic_state_put, etc.) were renamed to match.

The NVIDIA driver uses a script called conftest.sh to probe the kernel headers at build time and determine which function signatures and structures are supported. The probe checks whether drm_plane_helper_funcs.atomic_check and drm_crtc_helper_funcs.atomic_check accept a struct drm_atomic_state * argument.

Because kernel 7.2 changed the argument type to struct drm_atomic_commit *, the conftest check failed. DKMS decided those arguments were missing entirely, leaving #undef NV_DRM_PLANE_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG and #undef NV_DRM_CRTC_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG. When the driver attempted to compile nvidia-drm, the function prototypes mismatched and compilation halted.

(Note: If you are upgrading across multiple kernel milestones, Linux 7.0 and 7.1 also dropped the legacy Device Tree header <linux/of_gpio.h>, which requires its own small stub. I will include that below for completeness).

The Fixes

To fix this, we need to apply two targeted patches directly to the source directory in /usr/src/nvidia-580.142/.

Patch 1: Providing an Inline `strncpy` Fallback

Instead of patching dozens of individual C files across the driver, the cleanest solution is to inject an inline implementation into a header included by every sub-module.

The compatibility header common/inc/nv-time.h is unconditionally included by the core driver, modeset, DRM, and UVM.

Open the file:

sudo nvim /usr/src/nvidia-580.142/common/inc/nv-time.h

Jump to the bottom of the file. Directly before the final #endif // __NV_TIME_H__, add:

#include <linux/version.h>
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(7, 2, 0))
static inline char *strncpy(char *dest, const char *src, size_t count)
{
    char *tmp = dest;
    while (count) {
        if ((*tmp = *src) != 0)
            src++;
        tmp++;
        count--;
    }
    return dest;
}
#endif

This ensures any component looking for strncpy on Linux 7.2+ gets a lightweight, inline fallback without touching kernel symbols.

Patch 2: Bridging the DRM Atomic Commit Refactor

For the DRM issue, we can inject a compatibility shim into nvidia-drm/nvidia-drm-conftest.h. This header is included by every single file in the nvidia-drm module before any kernel DRM headers are loaded.

Open the file:

sudo nvim /usr/src/nvidia-580.142/nvidia-drm/nvidia-drm-conftest.h

Jump to the very end of the file. Directly before #endif /* defined(__NVIDIA_DRM_CONFTEST_H__) */, add:

#include <linux/version.h>
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(7, 2, 0))
#undef NV_DRM_PLANE_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG
#define NV_DRM_PLANE_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG
#undef NV_DRM_CRTC_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG
#define NV_DRM_CRTC_ATOMIC_CHECK_HAS_ATOMIC_STATE_ARG
#define drm_atomic_state drm_atomic_commit
#define drm_atomic_state_alloc drm_atomic_commit_alloc
#define drm_atomic_state_clear drm_atomic_commit_clear
#define drm_atomic_state_get drm_atomic_commit_get
#define drm_atomic_state_put drm_atomic_commit_put
#define drm_atomic_state_init drm_atomic_commit_init
#define drm_atomic_state_default_clear drm_atomic_commit_default_clear
#define drm_atomic_state_default_release drm_atomic_commit_default_release
#define drm_atomic_state_free drm_atomic_commit_put
#endif

This overrides the failed conftest.sh checks by asserting that the atomic state arguments exist, and aliases the legacy drm_atomic_state_* calls to their new drm_atomic_commit_* counterparts.

Bonus: The Linux 7.0/7.1 `<linux/of_gpio.h>` Fix

If you are building on a clean 580 source tree that has not been patched for Linux 7.x yet, you will also need to fix the missing Device Tree GPIO header.

Open /usr/src/nvidia-580.142/common/inc/nv-linux.h:

sudo nvim /usr/src/nvidia-580.142/common/inc/nv-linux.h

Search for of_gpio.h (around line 1746) and replace:

#include <linux/gpio.h>
#include <linux/of_gpio.h>

With:

#include <linux/gpio.h>
#if defined(CONFIG_OF) && (LINUX_VERSION_CODE < KERNEL_VERSION(7, 0, 0))
#include <linux/of_gpio.h>
#else
struct device_node;
static inline int of_get_named_gpio(const struct device_node *np,
                                    const char *propname, int index)
{
    return -ENOSYS;
}
#endif

Building and Installing the Module

Once the patches are saved in /usr/src/nvidia-580.142/, you can trigger the build.

If you were in the middle of a broken apt upgrade, simply finish configuring the pending packages:

sudo dpkg --configure -a

If you want to manually build and install for the new kernel:

sudo dkms build nvidia/580.142 -k 7.2.4-x64v3-xanmod1
sudo dkms install nvidia/580.142 -k 7.2.4-x64v3-xanmod1
sudo update-initramfs -u -k 7.2.4-x64v3-xanmod1

Gotcha: "Directory not empty" / Build Locks

If a previous DKMS build hung or was forcibly terminated (Ctrl+C, killed apt process, etc.), DKMS might complain with:

rm: cannot remove '/var/lib/dkms/nvidia/580.142/build': Directory not empty

This happens when background compiler processes or file monitors are still clinging to handles inside that directory. Kill the lingering processes and clear the build folder before trying again:

sudo fuser -k -m /var/lib/dkms/nvidia/580.142/build
sudo rm -rf /var/lib/dkms/nvidia/580.142/build

Verification

Check that DKMS has registered and installed the driver for your kernels:

dkms status

You should see clean installed lines for each kernel target:

nvidia/580.142, 7.1.13-x64v3-xanmod1, x86_64: installed
nvidia/580.142, 7.2.4-x64v3-xanmod1, x86_64: installed

Once verified, you are safe to reboot into kernel 7.2. After booting, run nvidia-smi to confirm that the GPU is awake, rendering, and communicating with the driver:

Important Takeaway for Future Package Updates

DKMS automatically builds kernel modules for new kernels using whatever source code currently sits in /usr/src/nvidia-580.142/.

That means:

When XanMod releases 7.2.5: No action needed. DKMS will use these patched files and compile cleanly.
When Debian or upstream releases a nvidia-driver-580 update: The /usr/src/nvidia-580.*/ directory will be overwritten with fresh, unpatched upstream files. If upstream has not incorporated these fixes yet, the post-install build will fail again.

Keep these patch snippets handy. It only takes about two minutes with your editor to drop them back in and resume business as usual.

Pascal was one of the best GPU architectures NVIDIA ever built. A few kernel API renames should not be the reason a perfectly good card gets sent to the e-waste pile.

As always,
Michael Garcia a.k.a. TheCrazyGM