[OpenAFS-devel] Problem with "afsmodname"

[Carsten Jacobi]

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