Date: Sat, 8 Aug 2009 18:48:53 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: pluknet <pluknet@gmail.com> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: panic in vgonel() Message-ID: <20090808154853.GZ1884@deviant.kiev.zoral.com.ua> In-Reply-To: <a31046fc0908070548q2dc21411i18aa3e353a8027fa@mail.gmail.com> References: <a31046fc0908070437p2b1c96denf24268ce52107a34@mail.gmail.com> <20090807115309.GW1884@deviant.kiev.zoral.com.ua> <a31046fc0908070537h713d412cm870878c116ba2ee4@mail.gmail.com> <20090807124609.GX1884@deviant.kiev.zoral.com.ua> <a31046fc0908070548q2dc21411i18aa3e353a8027fa@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--h1d7ksSqXDyyuV0m
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 07, 2009 at 04:48:37PM +0400, pluknet wrote:
> 2009/8/7 Kostik Belousov <kostikbel@gmail.com>:
> > On Fri, Aug 07, 2009 at 04:37:07PM +0400, pluknet wrote:
> >> 2009/8/7 Kostik Belousov <kostikbel@gmail.com>:
> >> > 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 =9A =3D 0x0
> >> >> fault code =9A =9A =9A =9A =9A =9A =9A=3D supervisor write data, pa=
ge not present
> >> >> instruction pointer =9A =9A =3D 0x8:0xffffffff805a52ba
> >> >> stack pointer =9A =9A =9A =9A =9A =3D 0x10:0xfffffffefc3474a0
> >> >> frame pointer =9A =9A =9A =9A =9A =3D 0x10:0xfffffffefc347510
> >> >> code segment =9A =9A =9A =9A =9A =9A=3D base 0x0, limit 0xfffff, ty=
pe
> >> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =3D DPL 0, pres 1, =
long 1, def32 0, gran 1
> >> >> processor eflags =9A =9A =9A =9A=3D interrupt enabled, resume, IOPL=
=3D 0
> >> >> current process =9A =9A =9A =9A =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 bot=
h cases):
> >>
> >> dev2# addr2line -e /boot/kernel/kernel.symbols 0xffffffff805a52ba
> >> /usr/src/sys/kern/vfs_subr.c:979
> >> delmntque(): =9A =9A =9A =9ATAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nm=
ntvnodes);
> >>
> >> dev2# addr2line -e /boot/kernel/kernel.symbols 0xffffffff805a52c2
> >> /usr/src/sys/kern/vfs_subr.c:981
> >> delmntque(): =9A =9A =9A =9AMNT_REL(mp);
> >
> > load kernel.debug into gdb, and then do "list *(vgonel+0x1aa)"
> >
>=20
> Ah, of course. Sorry.
>=20
> (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 }
If you can reproduce the issue at will, please try to do reproduce it
on the kernel with INVARIANTS and possibly DEBUG_VFS_LOCKS on.
--h1d7ksSqXDyyuV0m
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkp9nmUACgkQC3+MBN1Mb4jVEQCePrkxYLu2/zzXtin4otUSCeO0
4j0AoIHMUwFSljUt/qsI8mu0qwH/QsUl
=uNaY
-----END PGP SIGNATURE-----
--h1d7ksSqXDyyuV0m--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090808154853.GZ1884>