From owner-freebsd-alpha Mon Mar 26 17:25:48 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 0941E37B718; Mon, 26 Mar 2001 17:25:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2R1P0G32932; Mon, 26 Mar 2001 17:25:00 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15039.59182.857539.804159@grasshopper.cs.duke.edu> Date: Mon, 26 Mar 2001 17:24:39 -0800 (PST) From: John Baldwin To: Andrew Gallatin Subject: Re: dump(8) Cc: alpha@FreeBSD.org, obrien@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 27-Mar-01 Andrew Gallatin wrote: > > David O'Brien writes: > > This broken dump(8) situation *must* get fixed. It is time to back out > > commits. Does anyone have any idea what commit(s) broke dump? > > Nope. > > Its almost certainly related to the linuxthreads problem I was talking > about last week where a userland app dies on an instruction fault > with a PC somwhere in witness_exit(). > > I haven't been able to figure it out yet.. Try turning preemption off (i.e. remove it from the kernel config). On the x86 side we've seen that non-preemption safe code can blow up in very bad ways. :( FWIW, I've tracked down the vfs_object_create() panic some more after adding in printf's to VOP_CREATEVOBJECT() as so: static __inline int VOP_CREATEVOBJECT( struct vnode *vp, struct ucred *cred, struct proc *p) { struct vop_createvobject_args a; int rc; a.a_desc = VDESC(vop_createvobject); a.a_vp = vp; a.a_cred = cred; a.a_p = p; printf("%s: a = %p, a.a_desc = %p\n", __func__, &a, a.a_desc); printf("vnop %s, offset %d, flags = %d\n", a.a_desc->vdesc_name, a.a_desc->vdesc_offset, a.a_desc->vdesc_flags); printf("vp->v_op = %p, VOFFSET(vop_createvobject) = %d\n", vp->v_op, VOFFSET(vop_createvobject)); printf("vnop to call = %p\n", vp->v_op[VOFFSET(vop_createvobject)]); rc = VCALL(vp, VOFFSET(vop_createvobject), &a); return (rc); } I get the following output prior to the panic: VOP_CREATEVOBJECT: a = 0xfffffe000917da88, a.a_desc = 0xfffffc00006421c0 vnop vop_createvobject, offset 44, flags = 0 vp->v_op = 0xfffffe00006e7600, VOFFSET(vop_createvobject) = 44 vnop to call = 0xfffffc0000541d80 VOP_CREATEVOBJECT: a = 0xfffffe000917d8a8, a.a_desc = 0xfffffc00006421c0 vnop vop_createvobject, offset 44, flags = 0 vp->v_op = 0xfffffe00006e7600, VOFFSET(vop_createvobject) = 44 vnop to call = 0xfffffc0000541d80 VOP_CREATEVOBJECT: a = 0xfffffe000917d788, a.a_desc = 0xfffffc00006421c0 vnop vop_createvobject, offset 44, flags = 0 vp->v_op = 0xfffffe00006e7600, VOFFSET(vop_createvobject) = 44 vnop to call = 0xfffffc0000541d80 VOP_CREATEVOBJECT: a = 0xfffffe000917da28, a.a_desc = 0xfffffc00006421c0 vnop vop_createvobject, offset 44, flags = 0 vp->v_op = 0x8441fd6f7a07947c, VOFFSET(vop_createvobject) = 44 fatal kernel trap: trap entry = 0x4 (unaligned access fault) a0 = 0x8441fd6f7a07947c a1 = 0x29 a2 = 0x11 etc. So it looks like the pointer to the vop function table is getting spammed. I'm not sure if the whole vp is spammed or not. :( > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message