UFS+J panics on HEAD

Hi,

I have a machine that since updated to r235609 started to constantly =
panic
in the FS code while building universe, first with

ufs_dirbad: /scratch: bad dir ino 1137225 at offset 17920: mangled entry

which a clri and a fully forced fsck -y -f seems to have cleared (thanks =
to
kib) and now it is giving me:

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 =
0x7fffffffc998, rbp =3D 0x10 ---

/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.

Anyone an idea on what's going on there or what had changed since =
Feb/March
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 =
and
see if I can still reproduce it afterwards or whether it just got into a =
state
that fsck is failing to correct...

/bz

--=20
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"