From owner-freebsd-current@FreeBSD.ORG Wed May 23 13:10:56 2012 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 95DEA106564A; Wed, 23 May 2012 13:10:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 178C18FC15; Wed, 23 May 2012 13:10:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4NDAkpk099305; Wed, 23 May 2012 16:10:46 +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.5/8.14.5) with ESMTP id q4NDAkF6056110; Wed, 23 May 2012 16:10:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4NDAk8N056109; Wed, 23 May 2012 16:10:46 +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: Wed, 23 May 2012 16:10:46 +0300 From: Konstantin Belousov To: "Bjoern A. Zeeb" Message-ID: <20120523131046.GC2358@deviant.kiev.zoral.com.ua> References: <38A5BC8F-A8FB-4371-AB1D-9548F5957254@lists.zabbadoz.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xhQBShgGdvjvx42z" Content-Disposition: inline In-Reply-To: <38A5BC8F-A8FB-4371-AB1D-9548F5957254@lists.zabbadoz.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current FreeBSD , Kirk McKusick Subject: Re: UFS+J panics on HEAD 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: Wed, 23 May 2012 13:10:56 -0000 --xhQBShgGdvjvx42z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2012 at 12:40:34AM +0000, Bjoern A. Zeeb wrote: > Hi, >=20 > I have a machine that since updated to r235609 started to constantly panic > in the FS code while building universe, first with >=20 > ufs_dirbad: /scratch: bad dir ino 1137225 at offset 17920: mangled entry >=20 > which a clri and a fully forced fsck -y -f seems to have cleared (thanks = to > kib) and now it is giving me: >=20 > mode =3D 040700, inum =3D 14560, fs =3D /scratch > panic: ffs_valloc: dup alloc > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x1ce > ffs_valloc() at ffs_valloc+0x70c > ufs_makeinode() at ufs_makeinode+0x86 > VOP_CREATE_APV() at VOP_CREATE_APV+0x44 > vn_open_cred() at vn_open_cred+0x4c8 > kern_openat() at kern_openat+0x1f9 > amd64_syscall() at amd64_syscall+0x61e > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (5, FreeBSD ELF64, sys_open), rip =3D 0x4b94bc, rsp =3D 0x7ff= fffffc998, rbp =3D 0x10 --- >=20 > /scratch has USF+J enabled as another hint. The machine is also reporting > ECC memory corrections once in a while (replacement is on its way) but had > done that the months before the update to the latest HEAD as well w/o the > FS trouble. >=20 > Anyone an idea on what's going on there or what had changed since Feb/Mar= ch > that could cause this? I am willing to try things if I manage to get a > kernel compile for testing;-) otherwise I might dump/dd/newfs/restore a= nd > see if I can still reproduce it afterwards or whether it just got into a = state > that fsck is failing to correct... >=20 This panic is another protective panic caused by on-disk inconsistent structures. The bitmap indicated that an inode was free, but actual inode context suggested that the inode is in use. I would not worry much about ffs code until known hardware problem on the machine are fixed. You could try another pass of the full fsck on the volume, but my expectations are that bad hardware causes continuous damage to the data and metainformation. --xhQBShgGdvjvx42z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+84dYACgkQC3+MBN1Mb4gY6wCg39ceaRxH+NV+Ek1+COsh06Xf M/gAoOKIU7uA9PsNO8NK9Yok0mhs39Wp =bT9D -----END PGP SIGNATURE----- --xhQBShgGdvjvx42z--