Debian sid with bf2.4?

[kal]

hello, i havn't found a precompiled driver interface for a stock debian kernel, the bf2.4 flavor. any help here? it says it cannot find it.

also i get a CC_Mismatch when i do the interface compiling in expert mode (since debian uses different directory structure for putting modules). how do i disable that since theres very little chance the same compiler is used for compiling bf2.4 as the one i have now.

since debian sid is updated nightly.

[Andy Mecham]

From the README:

Q: Compiling the NVIDIA kernel module gives this error:

You appear to be compiling the NVIDIA kernel module with
a compiler different from the one that was used to compile
the running kernel. This may be perfectly fine, but there
are cases where this can lead to unexpected behaviour and
system crashes.

If you know what you are doing and want to override this
check, you can do so by setting IGNORE_CC_MISMATCH.

In any other case, set the CC environment variable to the
name of the compiler that was used to compile the kernel.

A: You should compile the NVIDIA kernel module with the same compiler
version that was used to compile your kernel. Some Linux kernel data
structures are dependent on the version of gcc used to compile it;
for example, in include/linux/spinlock.h:

...
* Most gcc versions have a nasty bug with empty initializers.
*/
#if (__GNUC__ > 2)
typedef struct { } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { }
#else
typedef struct { int gcc_is_buggy; } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { 0 }
#endif

If the kernel is compiled with gcc 2.x, but gcc 3.x is used when the
kernel interface is compiled (or vice versa), the size of rwlock_t
will vary, and things like ioremap will fail.

To check what version of gcc was used to compile your kernel, you
can examine the output of:

cat /proc/version

To check what version of gcc is currently in your $PATH, you can
examine the output of:

gcc -v

----

If you know what you're doing, then you'll want to export IGNORE_CC_MISMATCH to a non-zero value, as indicated by the error message.

--andy

[kal]

Originally posted by Andy Mecham
From the README:

Q: Compiling the NVIDIA kernel module gives this error:

You appear to be compiling the NVIDIA kernel module with
a compiler different from the one that was used to compile
the running kernel. This may be perfectly fine, but there
are cases where this can lead to unexpected behaviour and
system crashes.

If you know what you are doing and want to override this
check, you can do so by setting IGNORE_CC_MISMATCH.

In any other case, set the CC environment variable to the
name of the compiler that was used to compile the kernel.

A: You should compile the NVIDIA kernel module with the same compiler
version that was used to compile your kernel. Some Linux kernel data
structures are dependent on the version of gcc used to compile it;
for example, in include/linux/spinlock.h:

...
* Most gcc versions have a nasty bug with empty initializers.
*/
#if (__GNUC__ > 2)
typedef struct { } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { }
#else
typedef struct { int gcc_is_buggy; } rwlock_t;
#define RW_LOCK_UNLOCKED (rwlock_t) { 0 }
#endif

If the kernel is compiled with gcc 2.x, but gcc 3.x is used when the
kernel interface is compiled (or vice versa), the size of rwlock_t
will vary, and things like ioremap will fail.

To check what version of gcc was used to compile your kernel, you
can examine the output of:

cat /proc/version

To check what version of gcc is currently in your $PATH, you can
examine the output of:

gcc -v

----

If you know what you're doing, then you'll want to export IGNORE_CC_MISMATCH to a non-zero value, as indicated by the error message.

--andy

thanks for your input, my kernel is compiled with the old 2.95, and recently debian upgraded to 3.2.3 or something.

how would i go ahead and export that variable as a non-zero value?

[Andy Mecham]

In bash and friends:
export IGNORE_CC_MISMATCH=1

--andy

[bwkaz]

If your system compiler is gcc 3, and your kernel was compiled with gcc 2, this WILL NOT WORK!

Read the README section that Andy posted again. It talks about this very thing -- the size of rwlock_t is different in gcc 2 vs. gcc 3. This will screw up your kernel module.

Recompiling your kernel with your current gcc version would be the best way to fix this problem. If you later upgrade from gcc 3.2.3 to gcc 3.2.4, then that might work with just exporting IGNORE_CC_MISMATCH, but even then, I'm not so sure. I know for a fact, though, that gcc 2 vs. gcc 3 does NOT work.

[verysoft]

why don't you just recompile your kernel, take care of your agp-support and kick out your dri?
works fine on my woody 3.0 bf24