Bug 13150 - panic: ufs_dirbad: bad dir
Summary: panic: ufs_dirbad: bad dir
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Kirk McKusick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-08-15 11:00 UTC by mcmahon
Modified: 2002-02-11 00:34 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mcmahon 1999-08-15 11:00:01 UTC
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:291
#1  0xc0140f44 in at_shutdown (
    function=0xc01f1527 <__set_sysuninit_set_sym_M_UFSIHASH_uninit_sys_uninit+163>, arg=0xce78aff0, queue=-632091404) at ../../kern/kern_shutdown.c:515
#2  0xc0197396 in ufs_dirbad (ip=0xc3a85800, offset=49136,
    how=0xc01f14e0 "mangled entry") at ../../ufs/ufs/ufs_lookup.c:566
#3  0xc0196c8f in ufs_lookup (ap=0xda530d30) at ../../ufs/ufs/ufs_lookup.c:243
#4  0xc019bc3d in ufs_vnoperate (ap=0xda530d30)
    at ../../ufs/ufs/ufs_vnops.c:2316
#5  0xc01635b1 in vfs_cache_lookup (ap=0xda530d88) at vnode_if.h:55
#6  0xc019bc3d in ufs_vnoperate (ap=0xda530d88)
    at ../../ufs/ufs/ufs_vnops.c:2316
#7  0xc0165c93 in lookup (ndp=0xda530eec) at vnode_if.h:31
#8  0xc01657a7 in namei (ndp=0xda530eec) at ../../kern/vfs_lookup.c:152
#9  0xc016d8f5 in vn_open (ndp=0xda530eec, fmode=2562, cmode=420)
    at ../../kern/vfs_vnops.c:89
#10 0xc016a677 in open (p=0xda4ec020, uap=0xda530f80)
    at ../../kern/vfs_syscalls.c:980
#11 0xc01d0b0a in syscall (frame={tf_fs = 134742063, tf_es = 47,
      tf_ds = -1078001617, tf_edi = 135520327, tf_esi = 134789008,
      tf_ebp = -1077990984, tf_isp = -632090668, tf_ebx = 0,
      tf_edx = 134792784, tf_ecx = 12, tf_eax = 5, tf_trapno = 7, tf_err = 2,
      tf_eip = 403462628, tf_cs = 31, tf_eflags = 518, tf_esp = -1078002072,
      tf_ss = 47}) at ../../i386/i386/trap.c:1056
#12 0xc01bc2a1 in Xint0x80_syscall ()
#13 0x804dc47 in ?? ()
#14 0x805cd43 in ?? ()
#15 0x805d2bb in ?? ()
#16 0x805d646 in ?? ()

Fix: 

Unknown.  Also occurs in 3.2-RELEASE.
How-To-Repeat: Run NNTPCache with several hundred connections and lots of disk I/O.
Comment 1 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 01:08:41 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 01:46:52 UTC
Responsible Changed
From-To: freebsd-bugs->mckusick


Assigning to Kirk McKusick.  Kirk, I'm hoping you have some insights 
into why this might be happening.
Comment 3 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 01:52:10 UTC
State Changed
From-To: feedback->analyzed


The originator's responsed was added to the Audit-Trail.
Comment 4 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 02:00:00 UTC
Adding to Audit-Trail...

On Fri, Jul 20, 2001 at 07:37:26PM -0500, Michael S. McMahon wrote:
> > Does this problem still occur in newer versions of FreeBSD,
> > such as 4.3-RELEASE?
> >
> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13150
> 
> 	If you want to close the PR, I wouldn't object.  Thanks for asking.
> 
> 	Yes, it still does happen with heavy disk activity (defined as trying
> to remove thousands of files while writing hundreds of new ones in the space
> of a few minutes), and versions up to and including 4.2-RELEASE still exhibit
> the problem.
> 	However, I am now using different software than is described in the
> PR, and I am trying to eliminate other possible causes (such as flaky memory,
> bad cable, faulty controller, etc.).  I have not tried the most recent
> -STABLE.  Hence, it may be my fault, and the PR may no longer apply.
> 
> 
> 	Mike
> -- 
> Michael S. McMahon
> mcmahon@novia.net
>
Comment 5 Kirk McKusick freebsd_committer freebsd_triage 2002-02-11 00:33:07 UTC
State Changed
From-To: analyzed->closed

This problem has not been reported in the last six months. 
I therefore believe that it no longer exists.