From owner-freebsd-current@FreeBSD.ORG Tue Aug 21 03:49:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 171F416A417 for ; Tue, 21 Aug 2007 03:49:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4E813C467 for ; Tue, 21 Aug 2007 03:49:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1INKjs-000LCW-Nm; Tue, 21 Aug 2007 06:49:17 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7KKq1FK059254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 23:52:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7KKq1x8049102; Mon, 20 Aug 2007 23:52:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7KKq1Ng049101; Mon, 20 Aug 2007 23:52:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Aug 2007 23:52:01 +0300 From: Kostik Belousov To: Nikolay Pavlov Message-ID: <20070820205201.GW2738@deviant.kiev.zoral.com.ua> References: <200708202340.29678.qpadla@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vLS+sh2tCBRapC7G" Content-Disposition: inline In-Reply-To: <200708202340.29678.qpadla@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: dc9851233e967de4527dd65bbc92362e X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1391 [August 20 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 03:49:20 -0000 --vLS+sh2tCBRapC7G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2007 at 11:40:29PM +0300, Nikolay Pavlov wrote: > I am testing latest coda client code.=20 > After simple ls -l /coda i am getting this panic: >=20 > Unread portion of the kernel message buffer: > KDB: stack backtrace: > db_trace_self_wrapper(c0a9e0a9,e69729b0,c07c7933,0,e69729b0,...) at=20 > db_trace_self_wrapper+0x26 > kdb_backtrace(0,e69729b0,c0a15cf5,e69729c0,c821ac3c,...) at=20 > kdb_backtrace+0x29 > vfs_badlock(c4448c80,e69729c0,c0b7efc0,c821ac3c,0) at vfs_badlock+0x23 > assert_vop_locked(c821ac3c,c0acdaac,810,0,c65aca00,...) at=20 > assert_vop_locked+0x50 > VOP_OPEN_APV(c4448c80,e6972a18,1,c483a500,c4867ab0,...) at=20 > VOP_OPEN_APV+0x8a > coda_open(e6972a8c,c0acdaac,c4864c00,0,e6972b80,...) at coda_open+0x11e > VOP_OPEN_APV(c83ee6e0,e6972a8c,e6972a78,246,c8242984,...) at=20 > VOP_OPEN_APV+0xc5 > vn_open_cred(e6972b80,e6972c78,0,c483a500,c48358b8,...) at=20 > vn_open_cred+0x43b > vn_open(e6972b80,e6972c78,0,c48358b8,0,...) at vn_open+0x33 > kern_open(c4864c00,281b280c,0,1,0,...) at kern_open+0xe7 > open(c4864c00,e6972cfc,c,c0aa0d7e,c0b48838,...) at open+0x30 > syscall(e6972d38) at syscall+0x2d3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip =3D 0x2819af0b, esp =3D 0xbfbfe= 64c,=20 > ebp =3D 0xbfbfe688 --- > VOP_OPEN: 0xc821ac3c is not locked but should be > KDB: enter: lock violation > exclusive sleep mutex Giant r =3D 0 (0xc0bb0a30) locked=20 > @ /usr/src/sys/kern/vfs_lookup.c:658 > Locked vnodes >=20 > 0xc8242984: tag coda, type VDIR > usecount 7, writecount 0, refcount 7 mountedhere 0 > flags (VV_ROOT) > lock type coda: EXCL (count 1) by thread 0xc4864c00 (pid 1247)#0=20 > 0xc073efc0 at _lockmgr+0x560 > #1 0xc07bcb30 at vop_stdlock+0x40 > #2 0xc0a18ea5 at VOP_LOCK1_APV+0xa5 > #3 0xc07d6a68 at _vn_lock+0xf8 > #4 0xc07bfbe0 at lookup+0xf0 > #5 0xc07c0bce at namei+0x35e > #6 0xc07d6529 at vn_open_cred+0x2b9 > #7 0xc07d67c3 at vn_open+0x33 > #8 0xc07d5417 at kern_open+0xe7 > #9 0xc07d5900 at open+0x30 > #10 0xc0a01ea3 at syscall+0x2d3 > #11 0xc09e8190 at Xint0x80_syscall+0x20 >=20 > panic: filesystem goof: vop_panic[vop_print] > cpuid =3D 0 > Uptime: 15m52s > Physical memory: 1003 MB > Dumping 205 MB: 190 174 158 142 126 110 94 78 62 46 30 14 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc074ec7e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :409 > #2 0xc074ef3b in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc07bca9d in vop_panic (ap=3DCould not find the frame base=20 > for "vop_panic". > ) at /usr/src/sys/kern/vfs_default.c:152 > #4 0xc0a15f25 in VOP_PRINT_APV (vop=3D0xc83ee6e0, a=3D0xe6972634) at=20 > vnode_if.c:1873 > #5 0xc07c84af in vn_printf (vp=3D0xc8242984, fmt=3D0xc0a64c81 "%s\n") at= =20 > vnode_if.h:978 > #6 0xc07cabf1 in lockedvnodes (addr=3D-1065918974, have_addr=3D0, count= =3D-1,=20 > modif=3D0xe697279c "") at /usr/src/sys/kern/vfs_subr.c:2662 > #7 0xc048d255 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 > #8 0xc048e9c5 in db_trap (type=3D3, code=3D0)=20 > at /usr/src/sys/ddb/db_main.c:222 > #9 0xc0775c86 in kdb_trap (type=3D3, code=3D0, tf=3D0xe6972944)=20 > at /usr/src/sys/kern/subr_kdb.c:502 > #10 0xc0a026eb in trap (frame=3D0xe6972944)=20 > at /usr/src/sys/i386/i386/trap.c:621 > #11 0xc09e812b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0xc0775e02 in kdb_enter (msg=3D0xc0aa6bc4 "lock violation") at=20 > cpufunc.h:60 > #13 0xc07c7969 in vfs_badlock (msg=3D0xc0aa6c19 "is not locked but should= =20 > be", str=3D0xc0acdaac "VOP_OPEN", vp=3D0xc821ac3c)=20 > at /usr/src/sys/kern/vfs_subr.c:3432 > #14 0xc07ca360 in assert_vop_locked (vp=3D0xc821ac3c,=20 > str=3D0xc0acdaac "VOP_OPEN") at /usr/src/sys/kern/vfs_subr.c:3456 > #15 0xc0a1841a in VOP_OPEN_APV (vop=3D0xc4448c80, a=3D0xe6972a18) at=20 > vnode_if.c:369 > #16 0xc83ea78e in ?? () > #17 0xc4448c80 in ?? () > #18 0xe6972a18 in ?? () > #19 0x00000001 in ?? () > #20 0xc483a500 in ?? () > #21 0xc4867ab0 in ?? () > #22 0xe6972a30 in ?? () > #23 0x00000001 in ?? () > #24 0xc483a500 in ?? () > #25 0xc4864c00 in ?? () > #26 0xc0b7f080 in vop_mknod_desc () > #27 0xc821ac3c in ?? () > #28 0x00000001 in ?? () > #29 0xc483a500 in ?? () > #30 0xc4864c00 in ?? () > #31 0x00000000 in ?? () > #32 0xc821ac3c in ?? () > #33 0xc83ee6e0 in ?? () > #34 0xe6972a8c in ?? () > #35 0x00000001 in ?? () > #36 0xe6972a5c in ?? () > #37 0xc0a18455 in VOP_OPEN_APV (vop=3D0x0, a=3D0xc65aca00) at vnode_if.c:= 371 > Previous frame identical to this frame (corrupt stack?) >=20 > P.S. I forgot the original CODA maintainer email, could some forward this= =20 > to him? Quite often, the "impossible" panics with vnode locking are happens because some other thread already paniced the kernel. Then, lockmgr passes all lock requests without actually locking. I would suggest looking around to make sure this is not the case there. --vLS+sh2tCBRapC7G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGyf7wC3+MBN1Mb4gRAiu5AKCIdwuAPZwq6hH+o9vspxXdq709AgCguhTs /mPnOPAgVh/jE86QElyftxg= =hPhV -----END PGP SIGNATURE----- --vLS+sh2tCBRapC7G--