From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 05:16:23 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47DBF16A418; Fri, 16 Nov 2007 05:16:23 +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 23C5113C48E; Fri, 16 Nov 2007 05:16:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IstYc-0007Na-PA; Fri, 16 Nov 2007 07:15:59 +0200 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 lAG5Ftds001572; Fri, 16 Nov 2007 07:15:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAG5FtQt001571; Fri, 16 Nov 2007 07:15:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Nov 2007 07:15:55 +0200 From: Kostik Belousov To: Scott Long Message-ID: <20071116051555.GC78396@deviant.kiev.zoral.com.ua> References: <473B9A43.5060401@FreeBSD.org> <473CC522.5080904@FreeBSD.org> <20071116044858.GB78396@deviant.kiev.zoral.com.ua> <473D2516.9080805@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <473D2516.9080805@samsco.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 1e0f9aa0c43ce3c3744db576a35a93a3 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1789 [Nov 15 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists 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: ups@freebsd.org, tegge@freebsd.org, current@freebsd.org Subject: Re: panic: ffs_reallocblk: start == end 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: Fri, 16 Nov 2007 05:16:23 -0000 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2007 at 10:05:26PM -0700, Scott Long wrote: > Kostik Belousov wrote: > >On Thu, Nov 15, 2007 at 11:16:02PM +0100, Kris Kennaway wrote: > >>Kris Kennaway wrote: > >>>I got this panic on an 8 core amd64 running 8.0 when writing to a ufs = on=20 > >>>a md device: > >>> > >>>panic: ffs_reallocblk: start =3D=3D end > >>> > >>>db> wh > >>>Tracing pid 59911 tid 100115 td 0xffffff0003b90000 > >>>kdb_enter() at kdb_enter+0x31 > >>>panic() at panic+0x1c0 > >>>ffs_reallocblks() at ffs_reallocblks+0xb11 > >>>VOP_REALLOCBLKS_APV() at VOP_REALLOCBLKS_APV+0xb9 > >>>cluster_write() at cluster_write+0x38a > >>>ffs_write() at ffs_write+0x575 > >>>VOP_WRITE_APV() at VOP_WRITE_APV+0x147 > >>>vn_write() at vn_write+0x213 > >>>dofilewrite() at dofilewrite+0x9a > >>>kern_writev() at kern_writev+0x4f > >>>write() at write+0x4b > >>>syscall() at syscall+0x301 > >>>Xfast_syscall() at Xfast_syscall+0xab > >>>--- syscall (4, FreeBSD ELF64, write), rip =3D 0x800a65d0c, rsp =3D=20 > >>>0x7fffffffd268, rbp =3D 0x2800 --- > >>> > >>>Kris > >>> > >>Another one of these on a different machine. Looks like something is= =20 > >>definitely broken. > >> > >Kris, > >this is consequence of the checks moved from DIAGNOSTIC to INVARIANTS > >ifdef for ffs, and actually being compiled as result. Peter Holm reported > >the "ffs_truncate3" panic. >=20 > So does this check identify a real problem that needs to be fixed? I believe so for ffs_truncate3. It seems that vtruncbuf sometime skips the indirect blocks when cleaning buffer queues (at least when truncating to zero length). --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHPSeKC3+MBN1Mb4gRAmTPAJ9Byr61E+cE1B6kvErss45vtpLE+gCgnL1F OtrDgyInVdmYPMQLooNb7xo= =KbxK -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq--