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 = 040700, inum = 14560, fs = /scratch
panic: ffs_valloc: dup alloc
cpuid = 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 = 0x4b94bc, rsp = 0x7fffffffc998, rbp = 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

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