panic: bad dir with recent -current

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

Since updating a machine from sources of around 201110270000Z (and again
about 24 hours later), said machine panics with the following traceback
(recovered from dmesg):

[...]
wsdisplay0: screen 4 added (80x25, vt100 emulation)
wsdisplay0: screen 5 added (80x25, vt100 emulation)
/: bad dir ino 434153 at offset 0: mangled entry
panic: bad dir
cpu1: Begin traceback...
printf_nolog(c063daba,cd0bb2f8,69fe9,0,0,c05f95f1,1,d0ecc0c0,200,d0ecc0c0) at 
netbsd:printf_nolog
ufs_dirbadentry(d0ecc0c0,0,c05f95f1,0,ce2bf960,0,c05e0db8,d0ec4b00,d0ec5b78,ec4b00)
 at netbsd:ufs_dirbadentry
ufs_lookup(ce2bf9b4,d0ecb008,ce2bf9cc,c0562f85,ce2bf9bc,d0ec4b00,ce2bf9fc,c05519c7,d0ec3e80,ce2bf9e3)
 at netbsd:ufs_lookup+0x3fc
VOP_LOOKUP(d0ecb008,ce2bfa20,ce2bfbd4,2,0,cd0c3840,ce2bfa3c,d0ec4b00,1,d0ec4b14)
 at netbsd:VOP_LOOKUP+0x33
lookup_once(ce2bfafc,ce2bfaf8,4,c03b511b,0,ce23bcc0,0,ce0a2e60,cd58d000,bb905) 
at netbsd:lookup_once+0x19b
namei_tryemulroot(0,1,0,8,1,c065edf4,ce2bfcf4,c0543d50,bb90801c,cdfb8800) at 
netbsd:namei_tryemulroot+0x220
namei(ce2bfbb0,ce2bfbf0,2000,4752c9,cec2a100,ce07c180,ce2bfbf0,0,ce07c19c,0) at 
netbsd:namei+0x29
do_sys_stat(bb90801c,40,ce2bfc18,0,a,cec2a0c0,ce2bfc9c,ce2bfc3c,1,5430a) at 
netbsd:do_sys_stat+0x47
sys___stat50(ce1cb2a0,ce2bfcf4,ce2bfd1c,cdd341d4,c03b26f6,cdd341e8,cdd341d4,cdd68acc,764d8000,cdd347b8)
 at netbsd:sys___stat50+0x2a
syscall(ce2bfd48,bbb900b3,ab,bfbf001f,bbb9001f,8062298,5,bfbfd138,bfbfd0b4,bb908080)
 at netbsd:syscall+0xa4
cpu1: End traceback...

dumping to dev 0,1 offset 133223
dump Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011
    The NetBSD Foundation, Inc.  All rights reserved.
[...]

although there appears to be a core dump recovered by savecore, gdb
complains that it is an unrecognized format.

Just prior to the panic recovered above, I rebooted in single-user mode
and forced a full filesystem check on all filesystems.  The root file
system (as indicated in the panic message) had accumulated a number of
unreferenced files.

Surveying the files indicated that they had no business being on the
root filesystem at all, but were files that should have been on another
local filesystem (which passed its fsck).  The panic was prompted by
attempting to build ".../pkgsrc/multimedia/gnash" from pkgsrc-HEAD.
An earlier panic (from the night before) was prompted by the nightly
maintenance script.

So, it seems to behave as if the mounted filesystem becomes detached
and writes start happening on the "parent" filesystem...  All filesystems
are mounted with the "log" option and fsck always pronounces them "already
clean", even after the panic reboot.

(Given the time at which I'm composing this, the machine has just
now fallen over again due to the nightly maintenance activity.)

It's going to take at least one more panic to find which directory
has the inode complained about.  I'm guessing its the one on which
is the mount point for the filesystem in question.

--
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645