Date: Wed, 23 May 2012 16:10:46 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-current FreeBSD <freebsd-current@freebsd.org>, Kirk McKusick <mckusick@freebsd.org> Subject: Re: UFS+J panics on HEAD Message-ID: <20120523131046.GC2358@deviant.kiev.zoral.com.ua> In-Reply-To: <38A5BC8F-A8FB-4371-AB1D-9548F5957254@lists.zabbadoz.net> References: <38A5BC8F-A8FB-4371-AB1D-9548F5957254@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120523131046.GC2358>