[OpenAFS] Kernel module on sparc64

[Gunnar Krull]

On Wednesday 06 December 2006 23:49, Jeffrey Hutzelman wrote:
> On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull
>
> <gklists@cs.uni-goettingen.de> wrote:
> ># modprobe libafs
> > Found system call table at 0x4164b8 (exported)
> > Found 32-bit system call table at 0x416000 (exported)
> >
> > (Shouldn't it be a 64-bit system call table ?)
>
> There are two tables - one for "native" programs, and one for 32-bit
> programs.  We found both.
>
> > * With OpenAFS 1.5.10 and 1.5.11
> >
> ># modprobe libafs
> > Warning: Unable to find the address of authtab
> > NFS Translator hooks will not be installed
> > To correct, specify authtab_addr=<authtab>
>
> That's normal; unless you patch your kernel to export this symbol or
> provide its address on the command line, the NFS translator will not be
> supported.  Unlike the system call table, this is not something we can scan
> for.
>
> ># rmmod libafs
> > BUG: warning at fs/proc/generic.c:732/remove_proc_entry()
> > Call Trace:
> >  [0000000000406bd4] linux_sparc_syscall32+0x3c/0x40
> >  [0000000000010f2c] 0x10f34
>
> That's the whole trace?  That's pretty useless.  But no, this is not the
> cause of your problem.

Yes, that's the whole trace. Nothing more the kernel want's to say.
The same result now with version 1.5.12.


>
> > I think that's the reason why my token gets discarded when trying to
> > access a  protected folder of our afs filespace:
> >   afs: Tokens for user of AFS id 1032 for cell ****** are discarded
> > (rxkad  error=19270410)
>
> 19270410 is RXKADSEALEDINCON, which effectively means that either you or
> the fileserver is not encrypting data correctly.  Usually it means that one
> of you is using the wrong key, but in this case, there is a known problem
> on some 64-bit platforms, which should be fixed in the next release.

The encryption and keys on the server side are correct. I've checked this to 
be sure that the problem is the client. Sparc64 in combination with 
Linux/Debian is the only effected architecture here.

So, I'm waiting impatiently for the fixed release ...


>
> > The 1.5.11 version improves the amd64 system call table range checking.
> > Is  this also the case for sparc64 systems?
>
> IIRC, the issue in question only affected amd64 systems.
>
> -- Jeff


Thanks a lot for your answers!

Gunnar