Peter, Hmm. Sounds like we might have a little bit of a problem here. Because the kernel identification string for the modules you built from source is different from what is actually running, that's why you got a brand new directory tree under /lib/modules. You can manually copy the c7000.o module into the old directory tree and run "depmod -a", but that might not be all you need.
If you had "module versioning" turned on, that will cause the module to not load unless you specify "-f" on the insmod command. You'll know if you do it without the "-f" because it will tell you the module version doesn't match the running kernel. Another way to find out is to "cd" to the same directory where you did the "make oldconfig" and issue this command "grep CONFIG_MODVERSIONS .config" . On my system, I get this back: # CONFIG_MODVERSIONS is not set Hopefully you will also. On my 2.4 system, the module is in /lib/modules/2.4.9-ac10/kernel/drivers/s390/net/c7000.o Mark Post -----Original Message----- From: Peter E. Abresch Jr. - at Pepco [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 10:26 AM To: [EMAIL PROTECTED] Subject: Re: Linux CLAW Woes OK, I got the linux source tree from SuSE. I was able to apply the UTSG Cisco CLAW patch successfully. I then did the following: make oldconfig There was a comment from UTS to reply "M" to the new configuration. I never saw this. make dep Ran for a little while but seemed to work OK make modules Ran for a while with a lot of output but appeared to work OK make modules_install Ran OK. Created a new directory in /lib/modules/ called 2.4.7.SMP. The old directory is called 2.4.7.SuSE-SMP. Anyway, I get the following from the insmod command: ibm9672:/lib/modules # insmod c7000 base=0x5100 lhost0="PEPC" uhost0="PEPCOCEC" noauto=1 insmod: c7000: no module by that name found It appears to be only searching the 2.4.7.SuSE-SMP and not the new 2.4.7.SMP. I am sure this is something simple, I will appreciate any suggestions. Thanks. Peter
