Re: Patches to get Arla running on FreeBSD 8-CURRENT

Robert Watson <[email protected]>
Newsgroups gmane.os.freebsd.devel.afs,gmane.comp.file-systems.arla.general
Message-ID <[email protected]>
On Fri, 22 Feb 2008, Alec Kloss wrote:

> Robert, I've been playing with your patches, etc. on 8-CURRENT. I've been 
> having to tweak up include/config.h a little so I wonder if you missed a few 
> autoconf things... but more important, running "ls /afs" results in:

This is a symptom of a failure to insmntque a vnode after creating it, a new 
requirement for vnodes in FreeBSD 7.x/8.x; previously, vnodes were 
automatically inserted on the mount vnode queue and had their mount pointer 
set up during getnewvnode(), but closing certain races motivated this change. 
The reason I know this is that I remember adding two calls to insmntque to 
nnpfs in my patches, so there are three possibilities: (1) I missed a call to 
getnewvnode, (2) the patches I posted didn't include that change, or (3) the 
patch didn't apply properly.  I'll investigate this later today once I've 
given my FOSDEM talk; chances are it's an issue with the patch.

Robert N M Watson
Computer Laboratory
University of Cambridge


>
> nnpfs: cdev: 0, syscall: 339
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x26c
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc2a7f1fc
> stack pointer           = 0x28:0xcd412a40
> frame pointer           = 0x28:0xcd412a5c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 4822 (ls)
> [thread pid 4822 tid 100176 ]
> Stopped at      nnpfs_getattr_common+0xc:       movl
> 0x26c(%eax),%eax
> db> bt
> Tracing pid 4822 tid 100176 td 0xc2783440 nnpfs_getattr_common(c297b110,cd412ab4,c24f1700,c2783440,cd412aa0,...) at nnpfs_getattr_common+0xc
> nnpfs_getattr(cd412aa0,0,c0b10208,cd412b48,cd412b28,...) at nnpfs_getattr+0x33
> VOP_GETATTR_APV(c2a854a0,cd412aa0,c0bd91a0,c297b110,cd412ab4,...) at VOP_GETATTR_APV+0xa5
> vn_stat(c297b110,cd412b48,c24f1700,0,c2783440,...) at vn_stat+0x49
> kern_stat(c2783440,8113138,0,cd412c18,c0c5d140,...) at kern_stat+0x81
> stat(c2783440,cd412cfc,8,cd412d38,c0ba1e60,...) at stat+0x2f
> syscall(cd412d38) at syscall+0x2b3
> Xint0x80_syscall() at Xint0x80_syscall+0x20
> --- syscall (188, FreeBSD ELF32, stat), eip = 0x281a3acb, esp = 0xbfbfe54c, ebp = 0xbfbfe5d8 ---
> db>
>
> If I'me reading this (and nnpfs_vnodeops_common.c) right, this is
> probably a NULL value for (xn or perhaps vap) in
>
>        *vap = xn->attr;
>
> (line 765) Any thoughts?  Or tips on what I can do to help?  I
> don't have gdb ready to go yet---but I probably can this weekend.
>
> -- 
> Alec Kloss  [email protected]   IM: [email protected]
> PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E
> "No Bunny!" -- Simon, from Frisky Dingo
>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.