I urgently need to know what the highest kernel version is that 100.x.x work with.

[uOpt]

Subject says it all.

I get crashes with 169.12 and 2.6.24 every single day (kernel panic but of course I can't read the panic message). I previously thought this is sound related, but it is definitely a problem when Firefox opens new tabs. Since I have flashblock in there and no sound-playing plugins it is definitely not sound.

I am not ready to blame the NVidia drivers since I also changed hardware (Thunder K8W and two 2.4 GHz Opterons), but to narrow down what the problem is I need to run 100.x.x and I'll downgrade the kernel to whatever is the highest that works with them.

Or, even better, maybe somebody has patches to use 100.x.x with 2.6.24?

[jo794]

Running 100.14.19 here w/o any problems under 2.6.24.4. Needed a small modification:

--- NVIDIA-Linux-x86-100.14.19-pkg1/usr/src/nv/conftest.sh      2007-09-12 23:49:01.000000000 +0200
+++ NVIDIA-Linux-x86-100.14.19-pkg1.mod/usr/src/nv/conftest.sh  2008-04-13 23:16:54.000000000 +0200
@@ -28,7 +28,7 @@
 if [ "$OUTPUT" != "$SOURCES" ]; then
     ARCH=`uname -m | sed -e 's/i.86/i386/'`
     CFLAGS="$CFLAGS -I$OUTPUT/include2 -I$OUTPUT/include \
--I$HEADERS -I$HEADERS/asm-$ARCH/mach-default"
+-I$HEADERS -I$HEADERS/asm-$ARCH/mach-default -I$HEADERS/asm-x86/mach-default"
 else
     CFLAGS="$CFLAGS -I$HEADERS -I$HEADERS/asm/mach-default"
 fi

-jo

[uOpt]

Thanks, jo.

Turns out they compile out of the box on i386, I previously tried on amd64.

I'm up and running

BTW, I cannot see a "--try-compile-only" option for the installer. I actually have to take down the existing X11 session just to see whether the kernel module compiles. Surely there must be a way around that?

[Sasha_A]

Maybe it isn't necessarily the kernel version alone, but a combination of kernel, distro, driver, & hardware?

I use the latest nvidia driver as soon as I notice that there's a newer version, and am currently on 2.6.24.4 kernel, and not now or ever before have ANY combination of driver & kernel led to a single problem for me.. Never had to edit anything or set any weird variables or patch anything..
(Note I am on x86_32/i386 and Slackware)

[uOpt]

Originally Posted by Sasha_A

Maybe it isn't necessarily the kernel version alone, but a combination of kernel, distro, driver, & hardware?

I use the latest nvidia driver as soon as I notice that there's a newer version, and am currently on 2.6.24.4 kernel, and not now or ever before have ANY combination of driver & kernel led to a single problem for me.. Never had to edit anything or set any weird variables or patch anything..
(Note I am on x86_32/i386 and Slackware)

I didn't have stability problems with previous NVidia Linux drivers either. Specific applications trouble - sure. Kernel panics? No.

But the 169.x.x are being accused of not being SMP safe, or not being SMP safe on certain machines. Since I run on a dual single-core K8 here and have these panics I aimed at eliminating the 169.x.x drivers first.

%%

BTW, how do I see a panic message in Linux if I have to have a X11 server up? In FreeBSD I use a serial console, what do I do in Linux?

[logan]

On machines at work (redhat/fedora/centos), I configure console like so:

# /boot/grub/menu.lst
serial --unit=0 --speed=9600 --device=/dev/ttyS0
terminal --timeout=5 console serial
title Linux
kernel ... console=ttyS0,9600

# /etc/inittab
co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav

Note that booting with console=ttyS0 redirects everything during the boot process, it's not mirrored to both VGA and ttyS0. Once the system is up, you'll still get a getty. The agetty on ttyS0 is just to login on ttyS0 (add ttyS0 in /etc/securetty to login as root).

You could also use netconsole, but that may not be so good for this..

[Sasha_A]

Originally Posted by uOpt

...But the 169.x.x are being accused of not being SMP safe, or not being SMP safe on certain machines. Since I run on a dual single-core K8 here and have these panics I aimed at eliminating the 169.x.x drivers first.

Interesting, thank you for this added clarification. I wasn't aware till recently (and including this thread) of the SMP potential-issues with the 169xx drivers.
FWIW again, I am on a dual core (CORE2) E2160 Intel CPU, and still have no issues.

Anyone know if/what particular CPU's or ARCHs are maybe having these SMP issues? Or is it as yet kinda undiagnosed/unconfirmed?

Sasha

[jo794]

There are quiet some threads about SMP issues around in this forum. AFAIK there isn't even a recognized pattern for this problem. For me (AMD Athlon MP, (almost) plain vanilla Kernel, Debian) anything beyond 100.x.x is simply unusable.
BTW: Having problems compiling an old driver for a new kernel doesn't surprise me.

[chunkey]

Originally Posted by logan

On machines at work (redhat/fedora/centos), I configure console like so:

# /boot/grub/menu.lst
serial --unit=0 --speed=9600 --device=/dev/ttyS0
terminal --timeout=5 console serial
title Linux
kernel ... console=ttyS0,9600

# /etc/inittab
co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav

Note that booting with console=ttyS0 redirects everything during the boot process, it's not mirrored to both VGA and ttyS0. Once the system is up, you'll still get a getty. The agetty on ttyS0 is just to login on ttyS0 (add ttyS0 in /etc/securetty to login as root).

You could also use netconsole, but that may not be so good for this..

Hmm, you should choose a higher baudrate... something like 115200 and
if you put another console=tty0 (right next to "console=ttyS0,115200") you'll get the kernel messages on the serial port AND on your monitor!

[logan]

thanks for the info about console=tty0, I never thought of that..

[uOpt]

Originally Posted by jo794

There are quiet some threads about SMP issues around in this forum. AFAIK there isn't even a recognized pattern for this problem. For me (AMD Athlon MP, (almost) plain vanilla Kernel, Debian) anything beyond 100.x.x is simply unusable.
BTW: Having problems compiling an old driver for a new kernel doesn't surprise me.

I run fine on my 939 K8 dual-core PCIe at home with amd64.

The panics at work with a dual single-core K8 AGP i386 have so far disappeared since I downgraded to 100.x.x.