UFS+J panics on HEAD

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Wed May 23 00:40:39 UTC 2012


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


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

More information about the freebsd-current mailing list