[OpenAFS] tasklist_lock undefined Linux 2.6.18, OpenAFS 1.4.2
Peter N. Schweitzer
Fri, 27 Oct 2006 15:20:29 -0400
Jeffrey Hutzelman wrote:
> On Friday, October 27, 2006 08:02:07 PM +0200 Stefaan
> <firstname.lastname@example.org> wrote:
>> On 10/24/06, Peter N. Schweitzer <email@example.com> wrote:
>>> Yes, I didn't mean to be unclear. The problem I'm having is with a
>>> 2.6.18 system building 1.4.2.
>> I can confirm this. amd64 box, linux vanilla 2.6.18, openafs 1.4.2,
>> both from their original sources
>> It does build perfectly, but afterwards
>> bubbles ~ # depmod -e -a -F /usr/src/linux-2.6.18/System.map 2.6.18
>> WARNING: /lib/modules/2.6.18/fs/openafs/libafs.ko needs unknown symbol
>> it seems that the module has an unresolved symbol.
>> I have the impression that the developers believe this is fixed. Can
>> there be something both Peter and I are doing wrong such that the fix
>> is ineffective? Or is something else missing?
> Well, the patch I sent to the list should have made the problem go away
> for the original poster, but was incomplete and never meant to be
> applied in that form. The gatekeepers cleaned it up before committing,
> but there is one case that was missed, which only affects amd64.
> What I'm about to suggest isn't the "right" fix; in particular, it will
> probably break syscall table scanning on older kernel versions. But it
> should make your module load and work.
> Go into src/afs/LINUX/osi_probe.c, and look for a line like this:
> (unsigned long)(&tasklist_lock) - 0x30000,
> Remove the "- 0x30000" and the unresolved symbol reference should go away.
I don't mean to be a pain, but this cannot possibly solve an unresolved
external reference. The key point is that tasklist_lock is defined as
extern rwlock_t and it isn't present in the vanilla 2.6.18 kernel as
I've compiled it. I can believe that there's some kernel config switch
that I need to set in order to make the symbol public, but I don't see
what that is; I've tried a variety of kernel config changes to no avail.
I do also wish to emphasize that this is not an AMD64 system, it's an x86-32.
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: firstname.lastname@example.org