Using nvidia drivers on Debian Squeeze 64-bit with backported kernel

This article consists of notes I’ve written while attempting to get the official nvidia drivers to work on Debian Squeeze with a backported kernel.

For the record, on my system I am using kernel version 2.6.39-bpo.2-amd64.

I forget the exact forum page I found, but it seems using DKMS is now the preferred way of installing the official drivers in Debian. http://wiki.debian.org/NvidiaGraphicsDrivers seems to confirm this, although it is not immediately obvious.

Anyway, basically the procedure should be as simple as:

apt-get install -t squeeze-backports dkms nvidia-kernel-dkms

However, if you look carefully, an error likely occurred. If you missed the error, you should be able to reproduce it via:

dpkg-reconfigure nvidia-kernel-dkms

The output should be something like:

------------------------------
Deleting module version: 195.36.31
completely from the DKMS tree.
------------------------------
Done.
Loading new nvidia-195.36.31 DKMS files...
Building only for 2.6.39-bpo.2-amd64
Building initial module for 2.6.39-bpo.2-amd64

Error! Bad return status for module build on kernel: 2.6.39-bpo.2-amd64 (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/nvidia/195.36.31/build/ for more information.

Looking at /var/lib/dkms/nvidia/195.36.31/build/make.log, I found the following errors:

$ grep -ie error /var/lib/dkms/nvidia/195.36.31/build/make.log 
/var/lib/dkms/nvidia/195.36.31/build/nv-linux.h:22:28: error: linux/autoconf.h: No such file or directory
/var/lib/dkms/nvidia/195.36.31/build/nv-linux.h:92:75: error: linux/smp_lock.h: No such file or directory
make[4]: *** [/var/lib/dkms/nvidia/195.36.31/build/nv.o] Error 1
make[3]: *** [_module_/var/lib/dkms/nvidia/195.36.31/build] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make: *** [modules] Error 2

Okay, we’re missing some include files. It seems these are files which are not included in recent kernel versions.

Reference for smp_lock.h: http://idratherhack.blogspot.com/2011/04/nvidia-drivers-fail-without-smplockh.html

References for autoconf.h:

  1. https://bugs.launchpad.net/ubuntu/+source/dahdi-linux/+bug/591375
  2. http://alxrem.blogspot.com/2011/05/nvidia-drivers-on-debian-squeeze-with.html

Basically, smp_lock.h is for the now obsolete Big Kernel Lock, and autoconf.h got moved.

So, how do we kludge together a fix? The following is what I could come up with. Copy/paste this into a bash shell:

(
    set -o errexit

    die () {
        echo "$@" > /dev/stderr
        exit 1
    }

    if (($(id -u) != 0)); then
        die "This snippet must be run as root."
    fi

    # Install prerequisites
    apt-get install -t squeeze-backports dkms nvidia-kernel-dkms

    # Create fake smp_lock.h
    cd /lib/modules/$(uname -r)/source/include/linux
    if [ ! -e "smp_lock.h" ]; then
        touch smp_lock.h
        echo "Created dummy smp_lock.h."
    fi

    # Link to relocated autoconf.h
    cd /lib/modules/$(uname -r)/build/include/linux
    ln -sv ../generated/autoconf.h

    # Patch header file in nvidia sources
    # (Patch based on: http://alxrem.blogspot.com/2011/05/nvidia-drivers-on-debian-squeeze-with.html)
    cd /usr/src/nvidia-195.36.31
    cp -v nv-linux.h{,.bak}
    patchfile=$(tempfile)
    cat <<"EOF" > $patchfile
--- a/nv-linux.h     2011-05-11 12:26:22.206190191 +0400
+++ b/nv-linux.h  2011-05-04 15:36:27.163263047 +0400
@@ -975,8 +975,13 @@
 #endif
 
 #if defined(NV_ACQUIRE_CONSOLE_SEM_PRESENT)
-#define NV_ACQUIRE_CONSOLE_SEM() acquire_console_sem()
-#define NV_RELEASE_CONSOLE_SEM() release_console_sem()
+# if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 38)
+#  define NV_ACQUIRE_CONSOLE_SEM() console_lock()
+#  define NV_RELEASE_CONSOLE_SEM() console_unlock()
+# else
+#  define NV_ACQUIRE_CONSOLE_SEM() acquire_console_sem()
+#  define NV_RELEASE_CONSOLE_SEM() release_console_sem()
+# endif
 #else
 #define NV_ACQUIRE_CONSOLE_SEM()
 #define NV_RELEASE_CONSOLE_SEM()
EOF
    patch -Np1 -i $patchfile
    rm $patchfile

    # Reconfigure kernel sources (which will automatically build the nvidia DKMS module)
    dpkg-reconfigure linux-headers-$(uname -r)

    # Explicitly reconfigure the nvidia bits (sometimes this seems to be done automatically, sometimes not...)
    dpkg-reconfigure nvidia-kernel-dkms
)

Okay, that was a little long, but the above should successfully install the kernel module. (No warranty, but I developed and tested this on my two amd64 Debian Squeeze machines.)

For full disclosure, side effects of the above snippet are as follows:

  1. New empty header: /usr/src/linux-headers-$(uname -r)/include/linux/smp_lock.h
  2. New symlink: /usr/src/linux-headers-$(uname -r)/include/linux/autoconf.h (-> ../generated/autoconf.h)
  3. Modified header: /usr/src/nvidia-195.36.31/nv-linux.h (original is backed up as /usr/src/nvidia-195.36.31/nv-linux.h.bak)

From here, what typically remains is:

apt-get install -y nvidia-glx  # or one of the nvidia-glx-legacy-* modules
apt-get install -y nvidia-glx-ia32  # optional
apt-get install -y nvidia-xconfig nvidia-settings
if [ -e "/etc/X11/xorg.conf" ]; then
    echo "/etc/X11/xorg.conf exists; please change the display driver to "nvidia".
else
    nvidia-xconfig
fi

At this point, reboot, and you should be up and running!

Note that none of what I’ve done here is really original; I’ve just assembled notes from others and put them together in a few bash snippets. Just hope it’ll help someone get up and running faster than it took me. =)


Sidenote #1: On the Debian wiki page, if you don’t know about DKMS and try to read this page, you’ll likely end up assuming that module-assistant is the way to go, but I found that this would not work in my case, probably due to the backported kernel. (I don’t exactly remember the error.)

Sidenote #2: Installing nvidia-kernel-dkms adds a blacklist rule for the nouveau module, but Xorg’s defaults will cause nouveau to be loaded anyway unless an appropriate Xorg.conf file exists.

Sidenote #3: Found someone who had nearly an identical problem: http://alxrem.blogspot.com/2011/05/nvidia-drivers-on-debian-squeeze-with.html The notes are almost a complete solution, minus the smp_lock.h fix. I’m guessing it was written before the BKL was completely removed.

UPDATE #1: Unfortunately WordPress decided to butcher my source code and replace HTML special characters with character entities. I’ve fixed the code; hopefully the character replacements were the only changes it “helped” me with. Please let me know if this works.

UPDATE #2: Thank you everyone for your feedback. I was pretty late getting back to this but have finally updated the procedure based on your comments. Thanks!

UPDATE #3: Just a quick note, as I haven’t had time to fully apply and test this myself. I’ve noticed an update is necessary for this to work with the new backported 3.2 kernel. At a minimum, the following patch looks to be needed. (Note: the sourcecode WordPress plugin is not preserving tabs in the patch, so please apply manually.)

--- /usr/src/nvidia-195.36.31/Makefile.bak	2012-02-14 20:31:03.000000000 -0800
+++ /usr/src/nvidia-195.36.31/Makefile	2012-02-14 22:57:22.000000000 -0800
@@ -155,8 +155,9 @@
 
 # Check for kernel versions that we don't support.
 
-BELOW26 := $(shell if [ $(VERSION) -lt 2 -o $(PATCHLEVEL) -lt 6 ]; then \
-		echo y; fi)
+#BELOW26 := $(shell if [ $(VERSION) -lt 2 -o $(PATCHLEVEL) -lt 6 ]; then \
+#		echo y; fi)
+BELOW26 :=
 
 ifeq ($(BELOW26),y)
 $(error Only 2.6.x and later kernels are supported \

Yes, I know this doesn’t “fix” the if condition; however it should allow the compilation to proceed. I’ll post more once I have details.

23 thoughts on “Using nvidia drivers on Debian Squeeze 64-bit with backported kernel

  • Thanks for the tip… Things looked perfect earlier. It’s not the code highlighting; rather the “‘s got converted to HTML quote entities for some strange reason which didn’t occur when I previewed the post… Should be fixed now.

  • Many Thanks. Debian Wiki states that ‘breakage’
    occurs as as dist upgrade with ‘legacy drivers’
    like the GE or LEForce 6150, etc. cards.
    Alas, I have not found better method for PACKAGING
    as deb package method rather than than the ‘shell
    script method’ to ‘PATCH THE SYSTEM.’
    Aug, 2011

  • Unfortunately, when “dpkg-reconfigure linux-headers-$(uname -r)” is run I get the following message:
    Examining /etc/kernel/header_postinst.d.
    run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.39-bpo.2-amd64
    dkms: running auto installation service for kernel 2.6.39-bpo.2-amd64:
    nvidia (195.36.31)…failed.

  • Allright, I solved it, the problem was that for some reason the script installed the autoconf.h symlink and the smp_lock.h empty file in “/usr/src/linux-headers-2.6.39-bpo.2-common/…” instead of “/usr/src/linux-headers-2.6.39-bpo.2-amd64/…”.
    Thank you for this post, It’s been very helpful.

  • I think there’s links to both the amd64 and common source directories within the /lib/modules/$(uname -r)/source/ tree; it depends on exactly which subdir you’re in. I don’t remember right now. But yeah, if one spot doesn’t work, I expect the other would.
    …Oh, I think autoconf.h is in the …-common subdir, so if the symlink is created in the other one, it may cause problems. I’ll try to double-check this when I get time; maybe I hand-created a link and forgot to update the script.
    Thanks for your feedback!

  • I’m dealing with the same error, failed with reconfigure, from where do you copy autoconf.h and smp_lock.h to /usr/src/linuxxxxxx.amd64
    Needing detailed instructions to avoid the failed result as mentioned above.
    Thanks

    • Hi,
      This post was intended as the “detailed instructions” you’re asking for. Did you try to run the bash snippet at the end of my post? If so, did you get any specific error message?
      In the big shell block, basically I create a dummy smp_lock.h, and I symlink autoconf.h from another directory. Additionally there’s a patch against the nvidia sources. Together these should fix the problem.
      If you have tried my procedure and you continue to have errors, can you copy/paste the exact error into a comment please?
      Thanks.

  • Yes, instead of /lib/modules/$(uname -r)/source/include/linux
    you need to use /lib/modules/$(uname -r)/build/include/linux
    This will create the autoconf header in the correct directory.
    Thanks very much for this script !

  • @Nick: Thanks for confirming. I’ll update the script shortly and test it on another box of mine.
    @All: I’ve been without regular access to the net for a few weeks, so apologies for being slow to update and approve comments. I just got regular net access back yesterday.

  • Thanks, the script didn’t run for me but the info here let me get it going. I was kinda stuck until now with my MythTV. The stock Squeeze kernel had video support but didn’t support audio over HDMI. The backport kernel had audio but no accelerated video. Now I have both. The problem was the 160ms delay in my TV and mythtv not having a way to permanently set an audio delay. Now with the audio going through the TV it takes care of everything.

  • Okay, I took some time to update the procedure based on your comments. I tried it again on another machine of mine and revised things a little bit. Should be a bit easier to follow through to completion now.

  • First of all, Thank You! This saved a ton of headbanging 🙂
    I tried to run the script on 2.6.39-bpo.2-686-pae. It still failed. It turned out that for some reason the script wasn’t actually patching nv- linux.h.
    I manually patched, dpkg-reconfigured and it worked!
    perhaps some checking post-patch to make sure it’s actually patched would be in order.

    • Happy it worked. Seems odd that the patching portion did not go; I haven’t encountered any issue there. I think you’re the first to report on the pae kernel though, so I’ll keep an ear out.
      Oh, the one issue I can think about is that this “snippet” solution, while convenient, doesn’t force a particular shell. Maybe that could be part of the problem… Or, maybe the version of the nvidia driver was updated?
      If anyone else can provide feedback on this, or at least confirm the issue, please do. =)

  • Pingback: dreckhände
  • Thanks, I used this when compiling a 3.x kernel and the nvidia module wouldn’t build. After manually applying the patches things seem to be running smoothly.

Leave a Reply to attikiouzel Cancel reply

Your email address will not be published. Required fields are marked *