Date: Sat, 23 Feb 2008 09:28:26 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alec Kloss <alec-keyword-freebsd.org.a6e2e4@SetFilePointer.com> Cc: afs@FreeBSD.org, arla-drinkers@stacken.kth.se, Rasmus Kaj <kaj@kth.se> Subject: Re: Patches to get Arla running on FreeBSD 8-CURRENT Message-ID: <20080223092516.O23969@fledge.watson.org> In-Reply-To: <20080222125207.GD38141@hamlet.setfilepointer.com> References: <20080216035658.W93919@fledge.watson.org> <1203286882.16414.3.camel@heterodyne.kaj> <20080218012608.V96329@fledge.watson.org> <20080222125207.GD38141@hamlet.setfilepointer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 alec@SetFilePointer.com IM: angryspamhater@yahoo.com > PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E > "No Bunny!" -- Simon, from Frisky Dingo >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080223092516.O23969>