On Thu, 31 May 2007, Jeffrey Altman wrote:
Adam Megacz wrote:
In case this leaves anybody else scratching their head...
I discovered that with OpenAFS 1.4.4 and linux 2.6.20.4, if ThisCell
refers to a cell which has no volume called root.afs, and you forget
to specify -dynroot, afsd will hang on startup, and attempts to shut
it down will cause this:
slab error in kmem_cache_destroy(): cache `afs_inode_cache': Can't free all
objects
[<c0159294>] kmem_cache_destroy+0x7c/0xbf
[<f898a656>] cleanup_module+0x1e/0x53 [openafs]
[<c0131986>] sys_delete_module+0x130/0x194
[<c014b8a8>] remove_vma+0x31/0x36
[<c014c256>] do_munmap+0x16e/0x1c1
[<c0102e30>] syscall_call+0x7/0xb
[<c0400033>] rpc_timeout_upcall_queue+0x35/0xc4
=======================
I wouldn't call this a bug; it's a gross user configuration error --
but the failure mode is wierd enough that I thought I should mention
it so that it turns up when people google the error message.
- a
Actually, I do consider this a bug, its just such a low priority bug
that no one has gotten around to fixing it.
When there is no dynroot, afsd must obtain the root.afs volume in order
to complete its startup. It will attempt to mount it forever.
The Windows AFS client will panic if the volume cannot be loaded after
some period of time and freelance mode is not in use.
Actually, the issue here is we don't note if the kmem cache was actually
created before destroying it. We should fix it for 1.4.5
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
