Suse 9 nvnet problems

[synecdoche]

I am having some problems with Suse, which I decided to try tonight. This may take some explaining:

I had installed Red Hat 9, and installed the nvnet drivers for my nforce 2 onboard using the tar.gz files. I had downloaded them with my windows partition and put them onto a shared drive.

I decompressed them on the shared drive, and did the make and make install there, too.

Anyway, I was having some problems with Red Hat, and since I was just playing around, I decided to give Suse a try as I have never used it before. I was quite impressed-- it even suggested during the install that it recognized my ethernet card, something no distro has every done before (well, from the three or four I have tried).

Anyway, tried to go online, but still couldn't. So I went back to the shared drive and tried to make and make install again. Seemed to work okay, but still couldn't get on the net. Tried doing make uninstall, deleted nvnet.o from the drivers directory, and still no go.

Here is the output I get when I try to do a make at this point. Any help would be awesome. I think what i have to do is properly get rid of the old tar.gz stuff and then reinstall clean, but I've tried erasing the files and trying again, but to no avail:

linux:/windows/D/nforce/nvnet # make
cc -c -Wall -DLINUX -DMODULE -DEXPORT_SYMTAB -D__KERNEL__ -O -Wstrict-prototypes -DCONFIG_PM -fno-strict-aliasing -mpreferred-stack-boundary=2 -march=i686 -falign-functions=4 -DMODULE -I/lib/modules/2.4.20-4GB-athlon/build/include -DMODVERSIONS -include /lib/modules/2.4.20-4GB-athlon/build/include/linux/modversions.h nvnet.c
In file included from /lib/modules/2.4.20-4GB-athlon/build/include/linux/netdevice.h:147,
from nvnet.h:35,
from nvnet.c:21:
/lib/modules/2.4.20-4GB-athlon/build/include/linux/skbuff.h: In function `__pskb_pull':
/lib/modules/2.4.20-4GB-athlon/build/include/linux/skbuff.h:856: warning: comparison between signed and unsigned
/lib/modules/2.4.20-4GB-athlon/build/include/linux/skbuff.h: In function `pskb_may_pull':
/lib/modules/2.4.20-4GB-athlon/build/include/linux/skbuff.h:872: warning: comparison between signed and unsigned
ld -r -o temp.o nvnet.o nvnetlib.o
objcopy --strip-symbol="gcc2_compiled." temp.o
cp temp.o nvnet.o
rm temp.o
linux:/windows/D/nforce/nvnet # make install
mkdir -p //lib/modules/2.4.20-4GB-athlon/kernel/drivers/net
install -b -m 644 nvnet.o //lib/modules/2.4.20-4GB-athlon/kernel/drivers/net
linux:/windows/D/nforce/nvnet # modprobe nvnet
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o: kernel-module version mismatch
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o was compiled for kernel version 2.4.20-4GB
while this kernel is version 2.4.20-4GB-athlon.
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o: insmod /lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o failed
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o: insmod nvnet failed
linux:/windows/D/nforce/nvnet # insmod nvnet
Using /lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o: kernel-module version mismatch
/lib/modules/2.4.20-4GB-athlon/kernel/drivers/net/nvnet.o was compiled for kernel version 2.4.20-4GB
while this kernel is version 2.4.20-4GB-athlon.
linux:/windows/D/nforce/nvnet #

[deathadder]

Did you load the module? A make and make install just installs the module for you, after you need to load it with modprobe nvnet, or what ever the module happens to be called.

Sorry didn't see that you had used both modprobe and insmod, my mistake :)

Have you tried to include the path to your kernel source?

make inc=-i/usr/src/linux

[bwkaz]

No, /usr/src/linux is not the path to your Linux kernel source (or at least, it doesn't have to be -- mine are living in my home directory). /lib/modules/$(uname -r)/build is guaranteed to be, though, and that's what the nvnet Makefile is using.

The problem, from reading the error messages from insmod, is that SuSE isn't distributing a kernel source that exactly matches the kernel you're using. You need to edit /lib/modules/$(uname -r)/build/Makefile and add -athlon to the end of the EXTRAVERSION variable there (change -4GB to -4GB-athlon). Then, from /lib/modules/$(uname -r)/build, run make dep, and then go back and retry the nvnet driver.

Deleting the old nvnet.o isn't required, as the new one will overwrite it. You might have to "make clean" in the nvnet directory first though.

[alikilaij]

I had that problem too. I had it with the Sun Java Desktop System. It runs on some form of Suse, although I think Sun wants me to believe otherwise. Anyway, I found through reading the makefile in the nvnet folder within the nforce folder that it was using the version.h file in the /usr/src/linux{your_version_here]/include/linux folder.
this is what it read:

#define UTS_RELEASE "2.4.19-4GB"
#define LINUX_VERSION_CODE 132115
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

This is what I changed it to:

#define UTS_RELEASE "2.4.19-4GB-athlon"
#define LINUX_VERSION_CODE 132115
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

Saved changes.

Back to nforce folder.
make
make install

modprobe had some warnings, I don't remember what they were, but it didn't have any issues. I did have to reconfigure my network card in the hardware configuration utility on this system, but it is working, this email is proof.

Hope this helps.

[bwkaz]

You need to change the LINUX_VERSION_CODE too, though, I think. The best way to recreate that version.h file is to edit the top-level Makefile, change EXTRAVERSION, and make include/linux/version.h.

[maccorin]

well you have had lot's of great suggestions for getting it to work w/ your 2.4 kernel. I just wanted to put in my 2cents though. the forcenet (reverse engineered) drivers in the 2.6 kernel work beautifully w/ the nforce-net integrated cards (i have one myself) and are also opensource :)

If you are up to it i wuld suggest going 2.6 because i'm assming you have the nforce2 chipset, which i have found to be a much better performer under the 2.6.x kernels then the 2.4.x series

Just my 2 cents :P

Brandon Niemczyk