Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Apr 1999 07:33:42 -0500 (CDT)
From:      Bob Willcox <bob@luke.pmr.com>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/11132: panic: ufs_dirbad: bad dir
Message-ID:  <199904141233.HAA69412@luke.pmr.com>

next in thread | raw e-mail | index | archive | help

>Number:         11132
>Category:       kern
>Synopsis:       panic: ufs_dirbad: bad dir
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 14 05:40:01 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     Bob Willcox
>Release:        FreeBSD 3.1-STABLE i386
>Organization:
Power Micro Research
>Environment:

	FreeBSD obiwan.pmr.com 3.1-STABLE FreeBSD 3.1-STABLE #7: Sat Apr 10 09:50:56 CDT 1999     bob@obiwan.pmr.com:/usr2/src/sys/compile/OBIWAN  i386

        The system was built from 3.1-stable sources that were cvsupped
        and extracted immediatley before the kernel was built.

>Description:

        I often (about every 2nd or 3rd night) receive a "panic:
        ufs_dirbad: bad dir" on my news server system during the nightly
        amanda run (this machine is an amanda client).

        When the system reboots most of the time it drops into single
        user mode due to unexpected errors when fscking the news spool
        partition (/var/spool/news), requiring manual intervention.

        Thinking it might be due to a failing disk I replaced the news
        spool disk, but to no avail.  Note that the same hardware
        configuration had been running w/o incident for appx. a year on
        a 2.2.6-stable version of the system and that this problem has
        only appeared since upgrading to 3.1-stable.

	Here is a trace-back from gdb on the core file:

IdlePTD 3112960
initial pcb at 283f0c
panicstr: ufs_dirbad: bad dir
panic messages:
---
panic: ufs_dirbad: bad dir

syncing disks... 186 180 154 120 98 79 27 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up

dumping to dev 20401, offset 0
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
285                     dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:285
#1  0xf01523f9 in panic (fmt=0xf025cab7 "ufs_dirbad: bad dir")
    at ../../kern/kern_shutdown.c:446
#2  0xf01f52da in ufs_dirbad (ip=0xf163ca00, offset=1376, 
    how=0xf025ca71 "mangled entry") at ../../ufs/ufs/ufs_lookup.c:566
#3  0xf01f4b7e in ufs_lookup (ap=0xf6ccfd3c) at ../../ufs/ufs/ufs_lookup.c:243
#4  0xf01f9961 in ufs_vnoperate (ap=0xf6ccfd3c)
    at ../../ufs/ufs/ufs_vnops.c:2299
#5  0xf0172bb8 in vfs_cache_lookup (ap=0xf6ccfd98) at vnode_if.h:55
#6  0xf01f9961 in ufs_vnoperate (ap=0xf6ccfd98)
    at ../../ufs/ufs/ufs_vnops.c:2299
#7  0xf017508d in lookup (ndp=0xf6ccff00) at vnode_if.h:31
#8  0xf0174b60 in namei (ndp=0xf6ccff00) at ../../kern/vfs_lookup.c:152
#9  0xf017c2bb in vn_open (ndp=0xf6ccff00, fmode=1538, cmode=436)
    at ../../kern/vfs_vnops.c:88
#10 0xf017908d in open (p=0xf6c104a0, uap=0xf6ccff94)
    at ../../kern/vfs_syscalls.c:935
#11 0xf021ffab in syscall (frame={tf_es = 39, tf_ds = -272695257, 
      tf_edi = 138080262, tf_esi = 136699184, tf_ebp = -272642776, 
      tf_isp = -154337308, tf_ebx = -272640640, tf_edx = 104, 
      tf_ecx = 134826084, tf_eax = 5, tf_trapno = 12, tf_err = 2, 
      tf_eip = 672612076, tf_cs = 31, tf_eflags = 663, tf_esp = -272643156, 
      tf_ss = 39}) at ../../i386/i386/trap.c:1100
#12 0xf021698c in Xint0x80_syscall ()
#13 0x8052299 in ?? ()
#14 0x805b2a2 in ?? ()
#15 0x805c5fd in ?? ()
#16 0x805cd26 in ?? ()
#17 0x8057c25 in ?? ()
#18 0x805ad62 in ?? ()
#19 0x804da01 in ?? ()


>How-To-Repeat:

        I get this panic every couple of days.  It has always occurred
        during my nightly amanda backup run.

>Fix:

        I have reduced the failure from every night to every few nights
        by moving the innd expire to a different time from the amanda
        dumps.  Before they occurred at the same time and the panic
        would happen every night.


>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




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