Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Mar 2001 17:24:39 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        alpha@FreeBSD.org, obrien@FreeBSD.org
Subject:   Re: dump(8)
Message-ID:  <XFMail.010326172439.jhb@FreeBSD.org>
In-Reply-To: <15039.59182.857539.804159@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <jhb@FreeBSD.org> -- 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010326172439.jhb>