Date: Mon, 20 Mar 2006 17:01:02 -0500 From: Kris Kennaway <kris@obsecurity.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: panic: ffs_valloc: dup alloc in 6.1-BETA4 Message-ID: <20060320220102.GA78361@xor.obsecurity.org> In-Reply-To: <200603201528.49007.jhb@freebsd.org> References: <4415E8BB.1080602@centtech.com> <441B1C28.1020808@centtech.com> <441B2049.20507@centtech.com> <200603201528.49007.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 20, 2006 at 03:28:46PM -0500, John Baldwin wrote: > On Friday 17 March 2006 15:47, Eric Anderson wrote: > > Eric Anderson wrote: > > > [moved to -current due to lack of response] > > > > > > Eric Anderson wrote: > > >> Mike Tancsa wrote: > > >>> At 04:48 PM 13/03/2006, Eric Anderson wrote: > > >>>> I get the above panic after nfs clients attach to this nfs server= =20 > > >>>> and being > > >>>> I do have dumps from two crashes so far. > > >>>> This is FreeBSD-6.1-PRERELEASE from Friday-ish. > > >>> > > >>> Dont know if it was fixed or not, but there were a lot of VM change= s=20 > > >>> committed last night that might help. > > >>> > > >>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023526= .html=20 > > >>> > > >> > > >> I just updated, and it still happens. More information for those=20 > > >> interested: > > >> > > >> mode =3D 0100600, inum =3D 58456203, fs =3D /mnt > > >> panic: ffs_valloc: dup alloc > > >> > > >> > > >> #0 doadump () at pcpu.h:165 > > >> 165 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > > >> (kgdb) backtrace > > >> #0 doadump () at pcpu.h:165 > > >> #1 0xc064482f in boot (howto=3D260) at=20 > > >> /usr/src/sys/kern/kern_shutdown.c:399 > > >> #2 0xc0644b55 in panic (fmt=3D0xc0890967 "ffs_valloc: dup alloc") a= t=20 > > >> /usr/src/sys/kern/kern_shutdown.c:555 > > >> #3 0xc077ee3c in ffs_valloc (pvp=3D0xc8eab440, mode=3D33152,=20 > > >> cred=3D0xc8a91d80, vpp=3D0xe83a5824) at /usr/src/sys/ufs/ffs/ffs_all= oc.c:945 > > >> #4 0xc07a5933 in ufs_makeinode (mode=3D33152, dvp=3D0xc8eab440,=20 > > >> vpp=3D0xe83a5acc, cnp=3D0xe83a5ae0) at /usr/src/sys/ufs/ufs/ufs_vnop= s.c:2165 > > >> #5 0xc07a2b0d in ufs_create (ap=3D0x0) at=20 > > >> /usr/src/sys/ufs/ufs/ufs_vnops.c:171 > > >> #6 0xc082dc98 in VOP_CREATE_APV (vop=3D0x0, a=3D0xe83a5a18) at=20 > > >> vnode_if.c:204 > > >> #7 0xc0737590 in nfsrv_create (nfsd=3D0xc8a91d00, slp=3D0xc8816700,= =20 > > >> td=3D0xc7d99780, mrq=3D0xe83a5c98) at vnode_if.h:111 > > >> #8 0xc0744e95 in nfssvc_nfsd (td=3D0x0) at=20 > > >> /usr/src/sys/nfsserver/nfs_syscalls.c:472 > > >> #9 0xc0744688 in nfssvc (td=3D0xc7d99780, uap=3D0xe83a5d04) at=20 > > >> /usr/src/sys/nfsserver/nfs_syscalls.c:181 > > >> #10 0xc081cd7f in syscall (frame=3D > > >> {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 1, tf_esi= =3D 0,=20 > > >> tf_ebp =3D -1077941448, tf_isp =3D -398828188, tf_ebx =3D 4, tf_edx = =3D=20 > > >> 672385208, tf_ecx =3D 25, tf_eax =3D 155, tf_trapno =3D 12, tf_err = =3D 2,=20 > > >> tf_eip =3D 671840155, tf_cs =3D 51, tf_eflags =3D 662, tf_esp =3D=20 > > >> -1077941476, tf_ss =3D 59}) at /usr/src/sys/i386/i386/trap.c:981 > > >> #11 0xc0809e8f in Xint0x80_syscall () at=20 > > >> /usr/src/sys/i386/i386/exception.s:200 > > >> #12 0x00000033 in ?? () > > >> Previous frame inner to this frame (corrupt stack?) > > >> (kgdb) > > >> > > >> Maybe that helps somebody? > > >> > > >> Should I sent this to -current instead, since it appears this would= =20 > > >> happen under -current also, and possibly there is a larger base of= =20 > > >> people watching the list? > > > > > > > > > Also, here's a screenshot of the crash, and I have a good dump if=20 > > > anyone wants me to get more debugging info. > > > > > > http://www.googlebit.com/freebsd/fbsd-6.1b4-nfscrash.png > > > > >=20 > > Oh yea, and I can reproduce at will, on two separate machines. >=20 > If you boot the machines in single user and run 'fsck -y' repeatedly > until fsck stops finding breakage does it work ok after that? It maybe > that you have corrupted disks that bgfsck just can't handle. Basically it seems to me that bg fsck is always dangerous: there is an assumption that the only kinds of filesystem damage that exist are the "harmless" kinds (from power failure) it can later repair. But this is clearly false, because the filesystem may be in an arbitrarily damaged state (e.g. after a panic), and the kernel does not handle the possibility that filesystem data may not be completely trustable at runtime (this was the point of foreground fsck). Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEHyYdWry0BWjoQKURArndAKDrd3ocqtalwjyfywPMZ4Lw3o3x1ACg1Nh2 gFT73i1RU14jN600BsAfu+M= =ZbOQ -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060320220102.GA78361>