This was the mail I'd sent to Borries Demeler about the problems with
unresolved symbols in his modules after he rebuilt with SMP enabled. I've
cowardly waited until he confirmed that this fixed worked to send to
linux-smp.
The bug in the kernel build process (somewhat misreported below) is that
module.h includes modversions.h which includes various .ver files from
include/linux/modules/. These files only get rm'd in 'make mrproper' -
shouldn't they also get rm'd in 'make clean'? It's common, for me at
least, to build both SMP and non-SMP kernels with otherwise identical
.config files. To get the modxxx.ver files correct, I have to manually
blow away all the files in include/linux/modules/ between builds.
Don Holmgren
Fermilab
---------- Forwarded message ----------
Date: Sat, 10 Apr 1999 22:07:09 -0500 (CDT)
From: Don Holmgren <[EMAIL PROTECTED]>
To: Borries Demeler <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
>
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
