--Boundary_(ID_Dv4JIxhr2GxjSa+ZyWgiyg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Hi,
Don's advice help solve the problem I was seeing. To summarize the
specifics of what I did (note TOPDIR is /usr/src/linux-2.2.10/ below):
1) modified the top level Makefile, in $(TOPDIR), to add 'rm -rf
include/linux/modules/*' for the 'clean' target.
2) modified the definition of UTS_RELEASE in include/linux/version.h to
"2.2.10-31smp" from "2.2.10-31".
3) edit the drivers/net/Makefile and add hamachi.o to the two lines that
had yellowfin.o listed. (hamachi is a replacement for yellowfin)
Now doing:
make oldconfig
make clean
make dep
make modules
suceeds in building loadable modules for the 2.2.10-31smp kernel. The
make oldconfig above is to use a .config file instead of having to
answer yes to a long list of questions. Now if I could be sure that the
config file I have is really the one used to build the Fermi
2.2.10-31smp kernel (I actually doubt it is quite right given some of
the modules that were rebuilt but not in the /lib/modules/2.2.10-31smp/"
area). It REALLY would be nice to be able to rebuild the exact same
kernel if the need arises (also from a standpoint of just understanding
what is in the kernel).
-- -Jerry-> gug@fnal.gov Pepe's Theory of everything: "Under the right circumstances, things happen."--Boundary_(ID_Dv4JIxhr2GxjSa+ZyWgiyg) Content-type: message/rfc822
Return-path: <djholm@fndaub.fnal.gov> Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.9.8]) by fndapg.fnal.gov (8.8.7/8.8.7) with ESMTP id UAA00431 for <gug@fndapg.fnal.gov>; Mon, 23 Aug 1999 20:42:19 -0500 Received: from fndaub.fnal.gov ([131.225.80.191]) by FNAL.FNAL.GOV (PMDF V5.2-32 #36665) with ESMTP id <01JF4C3Y8GWW000240@FNAL.FNAL.GOV> for gug@fndapg.fnal.gov (ORCPT rfc822;gug@fnal.gov); Mon, 23 Aug 1999 20:42:14 -0500 CDT Received: (from djholm@localhost) by fndaub.fnal.gov (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA08354; Mon, 23 Aug 1999 20:42:17 -0500 (CDT) Date: Mon, 23 Aug 1999 20:42:17 -0500 (CDT) From: Don Holmgren <djholm@fnal.gov> Subject: Re: unresolved symbols in modules (fwd) To: gug@fnal.gov Message-id: <Pine.SGI.3.91.990823204020.7900A-100000@fndaub.fnal.gov> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Mozilla-Status2: 00000000
Hi Jerry -
There's a bit of a bug in the kernel build tree which results in the files from which those "Rsmp..." suffixes are supposed to derive not being generated. Try the advice below...
Don H
---------- Forwarded message ---------- Date: Sat, 10 Apr 1999 22:07:09 -0500 (CDT) From: Don Holmgren <djholm@fnal.gov> To: Borries Demeler <demeler@bioc09.uthscsa.edu> Subject: Re: unresolved symbols in modules
Hi -
I've been bitten by this sort of problem a couple of time in the last two weeks.
I think what's happening is that version information per module is generated only once by the Makefile into files in /usr/src/linux/include/linux/modules An example for my system is mtrr.ver:
acpr5:/usr/src/linux/include/linux/modules$ cat mtrr.ver #define __ver_mtrr_add smp_56179c5f #define mtrr_add _set_ver(mtrr_add) #define __ver_mtrr_del smp_272d394e #define mtrr_del _set_ver(mtrr_del)
The "smp_" bit is added if you're building SMP.
The bug in the makefiles is that 'make clean' does not clean out these .ver files. A subsequent build indeed compiles new modules, but the symbols built into whatever kernel data structure is used when you 'cat /proc/ksyms' (or the equivalent system call in insmod, depmod, etc...) are stamped with whatever is in the .ver files.
In your case, your .ver files will not have "smp_" prefixes, but they require them.
The fix is to rm -rf /usr/src/linux/include/linux/modules/* before you make dep clean bzImage modules
Let me know if this helps -
Don Holmgren Fermilab
On Sat, 10 Apr 1999, Borries Demeler wrote:
> Greetings, > > I am stumped: I compiled a kernel (2.2.5, single processor mode) with a > bunch of modules in it, boot the new kernel, run "depmod -a" during boot, > it finds all modules and starts just fine. > > Now I recompile the kernel, exactly the same setup, same modules, > everything identical, except: this time it is an SMP kernel, and > under "Processor type and features" I turn on MTRR support and > SMP support (I got a dual PII450). I recompile the modules, reinstall > the modules (same ones) and reboot. This time "depmode -a" generates > tons of unresolved symbols for the modules, needless to say, they don't > load and of course, they don't work. > > Well, almost. Some of the modules don't generate error messages and > do load. What is going on here? I read modules.txt and smp.txt, but > no mention of this problem. > > I get the same error regardless of wether I compile/install the SMP > modules (rm /lib/modules/2.2.5; make modules; make modules_install), > or if I use the modules compiled with the single CPU setup. > > Anybody has got a clue? Please let me know... And please don't tell > me to hardcode the modules into the kernel, I already know that works. > > Thanks in advance! > > -Borries > - > Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/ > To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu >
--Boundary_(ID_Dv4JIxhr2GxjSa+ZyWgiyg)--