[OpenAFS-devel] Problem with "afsmodname"
Derek Atkins
warlord@MIT.EDU
06 Nov 2001 08:34:55 -0500
The problem here is that you are building the Red HatRPM against
NON-RedHat kernel trees. Red Hat kernels pre-define all the version
symbol information for ALL processor/build types, which means you
can use a single source tree to build modules for ALL kernels.
It looks like you are configuring your own kernel but still using
the Red Hat OpenAFS SPEC file to build the kernel modules, and this
is not supported (Read: DOES NOT WORK).
What's going on is that you have a kernel that is SPECIFICALLY
configured for a SINGLE architecture type, but the SPEC file is trying
to (incorrectly) compile modules for alternate architecture types.
For example, assume your 'UP' kernel is configured for i386-up. You
_CANNOT_ build an athlon-smp module against this kernel source tree.
The short answer is: if you are trying to build against your own
kernels and not using Red Hat kernels, you have to build your kernel
modules (and SymTable) yourself. There is a one-to-one mapping of
kernel module -> locally-configured kernel tree. The SPEC file
assumes a many-to-one mapping of module -> kernel tree which is FALSE
for locally-configured kernels.
If you are going to use your own kernel trees then you will have to
either modify the SPEC to know which architectures to build for each
kernel or, better yet, change the SPEC to figure out which architecte
a kernel was built against. The SPEC as written will not work for if
you are doing what I believe you are.
Good Morning :)
-derek
Carsten Jacobi <carsten@ccac.rwth-aachen.de> writes:
> On Tue, Oct 30, 2001 at 10:44:59AM -0500, Jeffrey Hutzelman wrote:
> >
> > This patch indicates that you don't understand what afsmodname is actually
> > doing.
>
> Ok ok ... maybe I really still don't know what the script does, but I do
> want to understand what is going on there.
>
> > The point of afsmodname is that it works by examining kernel
> > symbol versions and loading a module that is compatible with the running
> > kernel. It does not make assumptions about the meaning of the module
> > filenames or the kernel version string; your patch would make it do both.
>
> Ok I see, the module version of the modules to load and the running
> kernel should match.
>
> > An SMP kernel and a non-SMP kernel which are otherwise configured
> > identically will have different symbol versions, so the wrong module will
> > simply fail to load.
>
> Ok, maybe here I face the problem. You also told me that my last posting lacked
> some information needed to track the problem. You may be interested in two
> different versions of the file /usr/vice/etc/modload/SymTable that I have
> on a UP and an MP machine; first a SymTable from the UP-machine:
>
> # SymTable, automatically generated
> # symbol version cpu module
>
> iget4 43e89402 - 2.4.8-athlon.mp
> iget4 43e89402 - 2.4.8-athlon
> iget4 43e89402 - 2.4.8-i386.mp
> iget4 43e89402 - 2.4.8-i386
> iget4 43e89402 - 2.4.8-i586.mp
> iget4 43e89402 - 2.4.8-i586
> iget4 43e89402 - 2.4.8-i686.mp
> iget4 43e89402 - 2.4.8-i686
>
> and a one from an MP-machine
>
> # SymTable, automatically generated
> # symbol version cpu module
>
> iget4 smp_0edf70fb - 2.4.13-SMP-athlon.mp
> iget4 smp_0edf70fb - 2.4.13-SMP-athlon
> iget4 smp_0edf70fb - 2.4.13-SMP-i386.mp
> iget4 smp_0edf70fb - 2.4.13-SMP-i386
> iget4 smp_0edf70fb - 2.4.13-SMP-i586.mp
> iget4 smp_0edf70fb - 2.4.13-SMP-i586
> iget4 smp_0edf70fb - 2.4.13-SMP-i686.mp
> iget4 smp_0edf70fb - 2.4.13-SMP-i686
> iget4 smp_00b8879f - 2.4.7-6custom-athlon.mp
> iget4 smp_00b8879f - 2.4.7-6custom-athlon
> iget4 smp_00b8879f - 2.4.7-6custom-i386.mp
> iget4 smp_00b8879f - 2.4.7-6custom-i386
> iget4 smp_00b8879f - 2.4.7-6custom-i586.mp
> iget4 smp_00b8879f - 2.4.7-6custom-i586
> iget4 smp_00b8879f - 2.4.7-6custom-i686.ep
> iget4 smp_00b8879f - 2.4.7-6custom-i686.mp
> iget4 smp_00b8879f - 2.4.7-6custom-i686
> iget4 smp_9457154e - 2.4.7-SMP-athlon.mp
> iget4 smp_9457154e - 2.4.7-SMP-athlon
> iget4 smp_9457154e - 2.4.7-SMP-i386.mp
> iget4 smp_9457154e - 2.4.7-SMP-i386
> iget4 smp_9457154e - 2.4.7-SMP-i586.mp
> iget4 smp_9457154e - 2.4.7-SMP-i586
> iget4 smp_9457154e - 2.4.7-SMP-i686.mp
> iget4 smp_9457154e - 2.4.7-SMP-i686
>
> One thing that strikes me here is that the module-version (the second
> culomn if I understood right) differs from kernel version to kernel
> version, but does not differ between SMP and UP-Kernels. So maybe that
> is why he loaded a UP-Module on my SMP-machine.
>
> > supporting a contributed AFS port to that platform. If the wrong module
> > is being loaded, then it is because your kernel has the wrong symbol
> > versions or no symbol versions.
>
> Ahh, maybe that is how it is supposed to be, but somehow on my machine also
> the UP libafs-modules got the same module versions as the SMP modules.
>
> > The most common cause of incorrect symbol versions is building more than
> > one kernel in the same source tree without an intervening 'make mrproper',
> > 'make dep', or explicit removal of include/linux/modules. RedHat used to
> > get this wrong, but they've fixed whatever their problem was.
>
> Aha, "mrproper" ... never heard about this target. But I will give it a try
> and post again when I have some more results ...
>
> > The most common cause of missing symbol versions is building without the
> > CONFIG_MODVERSIONS option defined. This used to be a problem when symbol
> > versions defaulted to 'off', but that hasn't been true for a while. In
> > any case, if you compile without symbol versions, afsmodname won't output
> > a module name at all; instead you'll get a message and the startup script
> > will end up trying to load libafs-`uname -r`.o. This could be your
> > problem, but probably is not.
>
> No the script is executed and tests the current kernel symbols and the
> recorded SymTable, I verified this by spreading some "print"s in "afsmodname".
> To me it seems as if the problem on my setup is derived by a "miscreation"
> of the SymTable not respecting correct module versions for UP and SMP-Kernels.
>
> By the way, is it a default that the module version of SMP-Kernels begins with
> the term "smp_"? I found this line in "afsmodname" (OpenAFS-1.2.2, line 31):
>
> if ($symbol =~ /^(.*)_R((?:smp)?(?:2gig)?_?[0-9a-f]{8})$/) {
> ^^^ ^
> ($symbol, $version) = ($1, $2);
>
> For me it seems that you already expect the key term "smp" in the module
> version as part of the syntax. Would it make sense to store the occurance
> of the keyterm "smp" as variable and use it later on to determine whether
> to load the UP or the MP-version of libafs? Ok, I don't know whether this
> will also work on 2.0.x-Kernels ... just a suggestion and I will try and
> see what "make mrproper" does.
> Regards
>
> Carsten Jacobi
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available