Unable to build kernel module on v190->260 on last few major kernel revisions

[ckolivas]

On a fujitsu laptop I'm unable to build any kernel modules on kernels since about 2.6.33 till the latest 2.6.36-rc with any driver versions, including the latest 260.19.06. The error is error: #error acpi_walk_namespace() conftest failed!

Attached is a gzip of the nvidia installer log.

Thanks!

[ckolivas]

Attached is the output from nvidia-bug report as well, in case it's helpful.

[piotrq__]

Take a look at this thread, Con: http://www.nvnews.net/vbulletin/showthread.php?t=142794

[ckolivas]

Doesn't help I'm afraid. Those changes already exist in the newer drivers. This appears to be something else. Thanks though!

[mlord]

Mmm.. the first error in the nvidia log you posted was "ERROR: Kernel configuration is invalid.". So the installer is having trouble recognizing or finding your configured kernel source tree.

If you can get over that hump, then rest assured it does build (and run) with the latest 2.6.35.7 kernel, and earlier ones too.

Is that really Con ?

Cheers
-ml

[mlord]

So.. the build script "knows" about these two paths on your system:

/lib/modules/2.6.36-rc7-ck1/source
/lib/modules/2.6.36-rc7-ck1/build

Ordinarily, both would be symlinks pointing to exactly the same place.
But if you have the kbuild output files in a separate tree, pointed to by "build", then they will differ. I wonder if that confuses the nvidia build scripts?

[ckolivas]

Yes I am me

No, the driver hasn't had a problem with separate source/build directories for a long time. In this case, also, they are not separate. I used to have an older patched kernel that worked, but I can't figure out who patched what and where I got it from since it was months and months ago. The error of not finding the source tree is an invalid error. Many times in the past I tried forcing it to exactly where everything was and it still came up with the same error.

edit: I'll check to see just *what* was patched in the one that did work... maybe it'll give me a hint.

[ckolivas]

I've checked what was in the patched one and got the following patch:

diff -Nurp ./pkg-history.txt ./pkg-history.txt
--- ./pkg-history.txt 2009-12-19 13:45:52.000000000 +1100
+++ ./pkg-history.txt 2010-01-25 13:39:10.000000000 +1100
@@ -4,3 +4,5 @@ NVIDIA-Linux-x86_64-195.30: Initial pack

NVIDIA-Linux-x86_64-195.30-pkg1: Added precompiled kernel interfaces for:
NVIDIA-Linux-x86_64-195.30-pkg2: Added 32 bit compatibility libraries
+NVIDIA-Linux-x86_64-195.30-pkg2-custom: Applied patch file: /home/fester/nvidia-195-2.6.33.patch.txt
+
diff -Nurp ./usr/src/nv/conftest.sh ./usr/src/nv/conftest.sh
--- ./usr/src/nv/conftest.sh 2009-12-19 13:44:00.000000000 +1100
+++ ./usr/src/nv/conftest.sh 2010-01-25 13:39:10.000000000 +1100
@@ -33,14 +33,14 @@ test_xen() {
# CONFIG_XEN and CONFIG_PARAVIRT are present, text_xen() treats
# the kernel as a stand-alone kernel.
#
- FILE="linux/autoconf.h"
+ FILE="generated/autoconf.h"

if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE ]; then
#
# We are looking at a configured source tree; verify
# that it's not a Xen kernel.
#
- echo "#include <linux/autoconf.h>
+ echo "#include <generated/autoconf.h>
#if defined(CONFIG_XEN) && !defined(CONFIG_PARAVIRT)
#error CONFIG_XEN defined!
#endif
@@ -110,7 +110,7 @@ build_cflags() {
fi
}

-CONFTEST_PREAMBLE="#include <linux/autoconf.h>
+CONFTEST_PREAMBLE="#include <generated/autoconf.h>
#if defined(CONFIG_XEN) && \
defined(CONFIG_XEN_INTERFACE_VERSION) && !defined(__XEN_INTERFACE_VERSION__)
#define __XEN_INTERFACE_VERSION__ CONFIG_XEN_INTERFACE_VERSION
@@ -1305,10 +1305,10 @@ case "$6" in
RET=1
FILE=""

- if [ -f $HEADERS/linux/utsrelease.h ]; then
- FILE="$HEADERS/linux/utsrelease.h"
- elif [ -f $OUTPUT/include/linux/utsrelease.h ]; then
- FILE="$OUTPUT/include/linux/utsrelease.h"
+ if [ -f $HEADERS/generated/utsrelease.h ]; then
+ FILE="$HEADERS/generated/utsrelease.h"
+ elif [ -f $OUTPUT/include/generated/utsrelease.h ]; then
+ FILE="$OUTPUT/include/generated/utsrelease.h"
elif [ -f $HEADERS/linux/version.h ]; then
FILE="$HEADERS/linux/version.h"
elif [ -f $OUTPUT/include/linux/version.h ]; then
@@ -1365,7 +1365,7 @@ case "$6" in
#
RET=1
VERBOSE=$7
- FILE="linux/autoconf.h"
+ FILE="generated/autoconf.h"

if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE ]; then
#
@@ -1419,7 +1419,7 @@ case "$6" in
#
RET=1
VERBOSE=$7
- FILE="linux/autoconf.h"
+ FILE="generated/autoconf.h"

if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE ]; then
#
diff -Nurp ./usr/src/nv/nvacpi.c ./usr/src/nv/nvacpi.c
--- ./usr/src/nv/nvacpi.c 2009-12-19 13:43:56.000000000 +1100
+++ ./usr/src/nv/nvacpi.c 2010-01-25 13:39:10.000000000 +1100
@@ -48,6 +48,10 @@ static const struct acpi_device_id nv_vi
};
#endif

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 33)
+#define acpi_walk_namespace(a,b,c,d,e,f) acpi_walk_namespace(a,b,c,d,e,f,NULL)
+#endif
+
static struct acpi_driver *nv_acpi_driver;
static acpi_handle nvif_handle = NULL;
static acpi_handle dsm_handle = NULL;

This last part looked familiar:
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 33)
+#define acpi_walk_namespace(a,b,c,d,e,f) acpi_walk_namespace(a,b,c,d,e,f,NULL)
+#endif

so I applied it to the equivalent file in the 260.19.06 driver but alas it still failed to build with the same error message.

[ckolivas]

Well, I can't for the life of me see why conftest fails on this one, but I just went in manually and edited the conftest.sh to force acpi_walk_namespace to 7 arguments, and then had to also force pci_dma_mapping_error to 2 arguments and it built fine. So now I have a driver, but I have no idea why the testing fails. NOTE: I do run a 64 bit kernel on a 32bit userspace so perhaps that's why? I usually install the 32bit driver without building a kernel module and build the module from the 64 bit driver... By the way, it would be nice if the driver could detect a 64 on 32 configuration and adapt accordingly. Thanks.

[ckolivas]

...No comment on this thread?