Date: Tue, 27 Mar 2001 11:56:39 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: obrien@FreeBSD.org, alpha@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu>, markm@FreeBSD.org Subject: Re: dump(8) (vfs_object_create() panics: found the problem) Message-ID: <XFMail.010327115639.jhb@FreeBSD.org> In-Reply-To: <XFMail.010326172439.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27-Mar-01 John Baldwin wrote:
>
> 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. :(
Ok, as I said earlier, only the pointer to the vnop function table is spammed,
the rest of the vnode is ok. I tracked this down to the big /dev/random
overhaul commits of March 11. Removing 'device random' from my kernel gets rid
of the panic but breaks ssh. :( A kernel just before the Mar 11 /dev/random
commits boots fine, and one just after panics. :( Hopefully Mark can trace
down where the data corruption is coming from. I'm willing to test any patches.
--
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.010327115639.jhb>