Linux 6.7.3 + 545.29.06/550.40.07: ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock'

In my case on 6.1.0-17-amd64 kernel everything works fine.

1 Like

i get this too but im failing to upgrade from 6.1.0-15-amd64 to 6.1.0-18-amd64 on Debian 12 (bookworm) so at least my machine isnt toast, but i get this while upgrading:

dpkg: dependency problems prevent configuration of linux-headers-amd64:
linux-headers-amd64 depends on linux-headers-6.1.0-18-amd64 (= 6.1.76-1); however:
Package linux-headers-6.1.0-18-amd64 is not configured yet.

i get this in my /var/log/nala/dpkg-debug.log:

Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information.

Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-18-amd64 (–configure):
installed linux-image-6.1.0-18-amd64 package post-installation script subprocess returned error exit status 1
Setting up linux-headers-6.1.0-18-amd64 (6.1.76-1) …

im reading the nvidia log now and so far I see this:

ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ‘__rcu_read_lock’
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ‘__rcu_read_unlock’

this is with Nvidia driver version 525.147.05-4~deb12u1

1 Like

Because Devuan Daedalus (5.0) is also based on Debian 12, I am experiencing this issue after upgrading to kernel 6.1.0-18-amd64.

Since NVIDIA is aware of this bug, one can remove this update until a bugfix is applied:

apt purge linux-image-6.1.0-18-amd64 linux-headers-6.1.0-18-amd64
apt upgrade
apt autoremove

and stay with 6.1.0-17-amd64.

Current driver version is 525.147.05. This driver builds correctly with 6.1.0-17-amd64 kernel.

2 Likes

Same here on Debian 12:

ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock'
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock'
make[3]: *** [/usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost:126: /var/lib/dkms/nvidia-current/545.23.08/build/Module.symvers] Fehler 1
make[2]: *** [/usr/src/linux-headers-6.1.0-18-common/Makefile:1991: modpost] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-6.1.0-18-amd64“ wird verlassen
make[1]: *** [Makefile:250: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/src/linux-headers-6.1.0-18-common“ wird verlassen
make: *** [Makefile:82: modules] Fehler 2

Did rolling back solve your problem? I was wondering if I should rather wait till the bug-fix is released.

1 Like

I believe it is the same thing on Debian 12 too, because Devuan is just Debian without systemd. You can try to purge the new kernel image, then it will default to the former kernel, that worked before, and must be already installed. On Devuan, purging the new kernel image triggers the DKMS compile to the old kernel, reverting things back, I think it will run for Debian too.

I guess that it is ok to stay with the old kernel until a fix for this issue is released. You can also revert to the Noveau driver with loss of functionality (mostly on gaming). This option is the last resort, because the Nouveau driver has it’s own problems.

To check if the old kernel is enough for you, hold shift key while booting to get into the grub bootloader screen, then choose the former kernel. You probably will boot with no issues. Debian keeps the last three kernels installed, and purging the most recent one will revert the default to the former version.

It is a NVIDIA problem, not a kernel one, but at least your system will run as before.

1 Like

Thanks! Removed 6.1.0-18, working fine now!

2 Likes

This seemed to work for me

1 Like

Hi Nvidia,

Thank you for the years of joy and wonders, using NVIDIA graphics. Lately, I am wondering about the stagnant updates for Linux users. The following are the bug fixes that I am doing for the various drivers.

path_regex1="NVIDIA-Linux-x86_64-.*\.run$"
path_regex2="nvidia_driver-linux-x86_64-.*-archive\.tar\.xz"
path_regex3="vulkan-.*-linux$"

nvver1=$(echo "$inst_file" | cut -f4 -d- | cut -f1 -d.)
nvver2=$(echo "$inst_file" | cut -f4 -d- | cut -f2 -d.)

apply_drm_hotplug_patch=0
apply_gpl_pfn_valid_patch=0
backport_egl_gbm=0

# Check for broken egl-gbm (<=530/vulkan, 535<=154, 545<=23).
# https://github.com/NVIDIA/egl-wayland/issues/93
if [[ ${nvver1} -le 530 || "$inst_file" =~ $path_regex3 ]]; then
    apply_drm_hotplug_patch=1
    apply_gpl_pfn_valid_patch=1
    backport_egl_gbm=1
elif [[ ${nvver1} -eq 535 && ${nvver2} -le 154 ]]; then
    apply_drm_hotplug_patch=1
    apply_gpl_pfn_valid_patch=1
    backport_egl_gbm=1
elif [[ ${nvver1} -eq 545 && ${nvver2} -le 23 ]]; then
    apply_drm_hotplug_patch=1
    apply_gpl_pfn_valid_patch=1
    backport_egl_gbm=1
elif [[ ${nvver1} -eq 545 && ${nvver2} -le 29 ]]; then
    apply_drm_hotplug_patch=1
    apply_gpl_pfn_valid_patch=1
elif [[ ${nvver1} -eq 550 && ${nvver2} -le 40 ]]; then
    apply_gpl_pfn_valid_patch=1
fi

I never intended to do this sort of thing. Back porting the egl_gbm library from 545.29.06 resolves eglinfo crashing in x11.

Will I need to continue this for the next 535 or 545 update?

Thank you for your time.

I would personally recommend packaging (and compiling) egl-gbm separately using the latest version, it’s open source like egl-wayland and you can control everything about it.

1 Like

Also it’s doubtful there will be another 545 update, 550 will likely become the next production branch once it’s out beta and the NFB 545 won’t be relevant anymore.

Imagine 535 will be supported for some time still though, anything below 535 is probably nearing its end except the LTS 470.

1 Like

Is there a way to subscribe to updates on bug 4336331? I turned off kernel auto-upgrades because of this and I’d like to know when I can turn it back on.

1 Like

Using the 6.5.0-0-amd64 kernel from bookworm-backports continues to work well for me. However, in hindsight I could have just sudo apt purge linux-image-6.1.0-18-amd64 (you don’t have to purge or remove the headers).

If I did that right away I would have still had 6.1.0-15 and 6.1.0-17, if I would have done that later I still would have had 6.1.0-15 which is fine for my 7-yr old machine w/ approx 10 yr old hardware (it wasn’t anything cutting edge when I bought it). In hindsight, that’s really the point of having a fallback kernel. But for some reason there is always a strong appeal of a “new” kernel with a bigger number. I think (and I could be wrong) unless there is a specific issue you are having, or you know something is included in the new kernel that will help you, there is no reason to think you need that “new” one with a bigger number. Same logic applies to nvidia drivers. But if you have very new hardware, then the logic is different and there is a better chance keeping up with available upgrades will benefit you.

How would i know when it is good to go back to 6.1?

When is the fix expected to ship? Want to update kernel past 6.1.0-17 without lumping in all of Backports.

3 Likes