From owner-freebsd-stable@FreeBSD.ORG Fri Aug 7 12:48:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A38B10656CF for ; Fri, 7 Aug 2009 12:48:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f218.google.com (mail-bw0-f218.google.com [209.85.218.218]) by mx1.freebsd.org (Postfix) with ESMTP id CD0988FC19 for ; Fri, 7 Aug 2009 12:48:38 +0000 (UTC) Received: by bwz18 with SMTP id 18so1388563bwz.7 for ; Fri, 07 Aug 2009 05:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oz0xRS8JMx2bV8IZmSkqYnngE7JalPBifCgsRkfU/vA=; b=M5dNpgRFJd/2R2x6r1JgOxjmnJJTWLXjKVAmeL5skgXPZVK5cyzfItavYSdBwmb8Yy I269ofyuBDhH7/nfutEzpu+H9Dsw+y2fcM/FEF0Wf4s++p5vHnVwPpTsPOAGMUH9RNah Uh8ZW9eHxZSJ2UuMMRStvZzggVYn2QKDpZq/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lhWm0K+rfMDHqfTIchtnm9vx5brucEM7IL2OiIujWiaxeYuG2HwSNEgiPgPRhkbNEm Jd8M781ZVaE2RBRTxczoKSBJvGPOJnFHv6hxr8oJ+IH4SRkZV+tYeT75oWHSEy53q78w 2mRbsjuM7NhKD9xHIZij3+XuHiZXZ4Os1eSo4= MIME-Version: 1.0 Received: by 10.103.2.1 with SMTP id e1mr491922mui.91.1249649317224; Fri, 07 Aug 2009 05:48:37 -0700 (PDT) In-Reply-To: <20090807124609.GX1884@deviant.kiev.zoral.com.ua> References: <20090807115309.GW1884@deviant.kiev.zoral.com.ua> <20090807124609.GX1884@deviant.kiev.zoral.com.ua> Date: Fri, 7 Aug 2009 16:48:37 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: panic in vgonel() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:48:40 -0000 2009/8/7 Kostik Belousov : > On Fri, Aug 07, 2009 at 04:37:07PM +0400, pluknet wrote: >> 2009/8/7 Kostik Belousov : >> > On Fri, Aug 07, 2009 at 03:37:11PM +0400, pluknet wrote: >> >> This is on 7.2-R amd64. >> >> >> >> I'm curious if it might be due to glusterfs on it. >> >> >> >> Fatal trap 12: page fault while in kernel mode >> >> cpuid =3D 3; apic id =3D 03 >> >> fault virtual address =A0 =3D 0x0 >> >> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page= not present >> >> instruction pointer =A0 =A0 =3D 0x8:0xffffffff805a52ba >> >> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xfffffffefc3474a0 >> >> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x10:0xfffffffefc347510 >> >> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D DPL 0, pres 1, lo= ng 1, def32 0, gran 1 >> >> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL = =3D 0 >> >> current process =A0 =A0 =A0 =A0 =3D 35425 (find) >> >> >> >> db> bt >> >> Tracing pid 35425 tid 100194 td 0xffffff003c165370 >> >> vgonel() at vgonel+0x1aa >> >> vnlru_free() at vnlru_free+0x36c >> >> getnewvnode() at getnewvnode+0x281 >> >> ffs_vgetf() at ffs_vgetf+0xdf >> >> ufs_lookup() at ufs_lookup+0x2dd >> >> vfs_cache_lookup() at vfs_cache_lookup+0xf3 >> >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x40 >> >> lookup() at lookup+0x598 >> >> namei() at namei+0x33e >> >> kern_lstat() at kern_lstat+0x5e >> >> lstat() at lstat+0x2a >> >> syscall() at syscall+0x256 >> >> Xfast_syscall() at Xfast_syscall+0xab >> >> --- syscall (190, FreeBSD ELF64, lstat), rip =3D 0x80071063c, rsp =3D >> >> 0x7fffffffea48, rbp =3D 0x800a06910 --- >> > >> > Did you got the vmcore ? If yes, please find the value for vgonel() >> > argument, vp, and print the vnode content. >> >> I didn't. Same problem as in my another mail. :( >> >> > >> > Regardless of this, look up the source line for vgonel+0x1aa. >> > >> >> I could resolve only address which belongs to instruction pointer >> =3D 0x8:0xffffffff805a52ba >> (eh, I don't know if I should sum these numbers, so I did this for both = cases): >> >> dev2# addr2line -e /boot/kernel/kernel.symbols 0xffffffff805a52ba >> /usr/src/sys/kern/vfs_subr.c:979 >> delmntque(): =A0 =A0 =A0 =A0TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmnt= vnodes); >> >> dev2# addr2line -e /boot/kernel/kernel.symbols 0xffffffff805a52c2 >> /usr/src/sys/kern/vfs_subr.c:981 >> delmntque(): =A0 =A0 =A0 =A0MNT_REL(mp); > > load kernel.debug into gdb, and then do "list *(vgonel+0x1aa)" > Ah, of course. Sorry. (gdb) list *(vgonel+0x1aa) 0xffffffff805a52ba is in vgonel (/usr/src/sys/kern/vfs_subr.c:979). 974 return; 975 MNT_ILOCK(mp); 976 vp->v_mount =3D NULL; 977 VNASSERT(mp->mnt_nvnodelistsize > 0, vp, 978 ("bad mount point vnode list size")); 979 TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmntvnodes); 980 mp->mnt_nvnodelistsize--; 981 MNT_REL(mp); 982 MNT_IUNLOCK(mp); 983 } --=20 wbr, pluknet