To build nvidia kernel module failed in kernel-2.6.23-0.41.rc0.git14.fc8

[bugmeplz]

Will NVIDIA fix it upstream?

[zander]

Yes, we plan on addressing this in the regular and legacy drivers, eventually.

[snaboofypop]

Hi. I'm running 9639. I've patched the nv source, and am running the 2.6.23-rc1-git3 kernel. The build seems to go okay, but when I try to load the kernel, it refuses. On closer inspection, nv.c line 110 gives an error message: nv.c: At top
level:
/data/kernel/temp/nv/NVIDIA-Linux-x86-1.0-9639-pkg1/usr/src/nv/nv.c:110: err
or: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ bef
ore ‘*’ token
... so it seems that its trying to perform a mathematical product, rather than declaring a pointer (and setting its value), the line being (on my slightly modified nv.c file)
static kmem_cache_t *nv_pte_t_cache = NULL;
(lines following the first error message from other files stating that nv_pte_t_cache is undeclared. So it seems that somehow kmem_cache_t is not recognized as a data type. I can go back to 2.6.22-git2 as everything was still working then.

[zander]

@snaboofypop: please see post #9 (http://www.nvnews.net/vbulletin/show...86&postcount=9).

[johngeeaswell]

Replacing with 'void *' it builds fine but trying to load it I get:
nvidia: Unknown symbol __you_cannot_kmalloc_that_much

nv ver: 9631
kern ver: 2.6.23-rc3

I understand the sentiment that it's a beta kernel so what do you expect, etc. etc. Sometimes it can't be helped when trying to get new hardware devices working.

Any ideas are welcome


PS: Nvidia site insists on linking to the 9755 driver for GeForce4 and under....... ?

[zander]

@johngeeaswell: you can avoid the __you_cannot_kmalloc_that_much unresolved symbol problem by either using the SLUB allocator or removing the '-O' compiler flag from ../usr/src/nv/Makefile.kbuild.

[johngeeaswell]

Excellent,
I removed the -0 from the EXTRA_CFLAGS and recompiled. It loaded no problem.

Thanks zander



Curious, the absence of that setting will probably slow things down a little, would that be correct?

[crow]

What about patching 8776? That's the latest version that works with interlaced modes (see various threads on 1080i).

[Iceberg69]

Originally Posted by zander

@sangu: you may be able to get 1.0-9755 to build by replacing the 'kmem_cache_t' references with 'void *'.

'void *' is not the proper replacement for 'kmem_cache_t'. The driver compilation was broken by this patch: http://git.kernel.org/?p=linux/kerne...bc51c94e127fbc
I therefore suggest the following patch:

diff -urN a/nv/nv.c b/nv/nv.c
--- a/nv/nv.c	2007-08-16 14:04:49.000000000 +0200
+++ b/nv/nv.c	2007-09-27 16:19:36.000000000 +0200
@@ -107,7 +107,7 @@
 
 static int nv_mmconfig_failure_detected = 0;
 
-static kmem_cache_t *nv_pte_t_cache = NULL;
+static struct kmem_cache *nv_pte_t_cache = NULL;
 
 // allow an easy way to convert all debug printfs related to events
 // back and forth between 'info' and 'errors'

BTW, kmem_cache_t has been deprecated since 2.6.20 (since the beggining of February).

[zander]

Older kernels have 'struct kmem_cache_s'/'kmem_cache_t', but not the recently introduced 'struct kmem_cache'. Handling the type difference across kernels would require a compile test; since the NVIDIA Linux graphics driver doesn't use the cache pointer directly, using 'void *' and avoiding the addition of another compile test was deemed a better choice.

[CraigG4C]

There's my patch for 9755 to allow it to compile under 2.6.23 at
http://home.hiwaay.net/~craigg/linux/NV_patch.html

-- 100 doesn't restore my screen correctly.

[hvw59601]

I had the failure in the 9631 driver on 2.6.23.1 with the ck patch applied.

Your patch fit with offset and appears to fix the problem.

Thanks.

Hugo