[OpenAFS] Kernel module on sparc64

[Jeffrey Hutzelman]

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.



> 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 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