On Wednesday, November 15, 2006 09:44:56 AM +0100 Gunnar Krull <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
