Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Jan 2006 08:46:36 -0700
From:      Scott Long <scottl@samsco.org>
To:        obrien@freebsd.org
Cc:        freebsd-current@freebsd.org
Subject:   Re: It still here... panic: ufs_dirbad: bad dir
Message-ID:  <43BA9C5C.9010307@samsco.org>
In-Reply-To: <20060102222723.GA1754@dragon.NUXI.org>
References:  <20060102222723.GA1754@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote:

> Just in case anyone thought the bug had been fixed...
> 
> FreeBSD 7.0-CURRENT #531: Mon Jan  2 11:32:17 PST 2006 i386
> 
> panic: ufs_dirbad: bad dir
> cpuid = 1
> KDB: stack backtrace:
> kdb_backtrace(c06c9ba1,1,c06c03c6,eae718c8,c8a91480) at 0xc053657e = kdb_backtrace+0x2e
> panic(c06c03c6,c85bf1f8,dade11,580,c06c0380) at 0xc0516618 = panic+0x128
> ufs_dirbad(c9171bdc,580,c06c0380,0,eae7193c) at 0xc0616e4d = ufs_dirbad+0x4d
> ufs_lookup(eae719e8,c916c528,eae71bc4,c916c528,eae71a24) at 0xc06165cd = ufs_lookup+0x3ad
> VOP_CACHEDLOOKUP_APV(c06f2a80,eae719e8,eae71bc4,c8a91480,cac28d80) at 0xc068cd4e = VOP_CACHEDLOOKUP_APV+0x9e
> vfs_cache_lookup(eae71a90,eae71a90,c916c528,c916c528,eae71bc4) at 0xc057275a = vfs_cache_lookup+0xca
> VOP_LOOKUP_APV(c06f2a80,eae71a90,c8a91480,c106fc88,0) at 0xc068cc66 = VOP_LOOKUP_APV+0xa6
> lookup(eae71b9c,0,c06b5c8e,b6,c057f7ed) at 0xc057760e = lookup+0x44e
> namei(eae71b9c,eae71b3c,60,0,c8a91480) at 0xc0576ecf = namei+0x44f
> kern_stat(c8a91480,8106f20,0,eae71c10,e0) at 0xc05863dd = kern_stat+0x3d
> stat(c8a91480,eae71d04,8,43c,c8a91480) at 0xc058636f = stat+0x2f
> syscall(3b,3b,3b,80dbe80,8106f20) at 0xc0682b43 = syscall+0x323
> Xint0x80_syscall() at 0xc066d33f = Xint0x80_syscall+0x1f
> 

Please include the console printf that is right about the panic message.
It will say either something about a mangled entry or an isize too
small.  Since this problem is happening consistently for you, but there
seem to be no other problem reports from others, I'd highly suspect that
you have filesystem damage that isn't getting detected by fsck.  I 
assume that you are running fsck in the foreground and not in the 
background, yes?  The easiest solution here might be to figure out which
directory is causing the problem, and just clri its inode and then clean
up the mess.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43BA9C5C.9010307>