Bug #1489

panic: ufs_dirbad: bad dir

Added by rumcic about 5 years ago. Updated over 1 year ago.

Status:FeedbackStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

After a previous panic I got this panic while building world. After cleaning
out /usr/obj I have been unable to repeat this panic again, so it's not
reproducable (for now).

Dump at leaf:~rumko/crash/bad_dir/ and the backtrace is:
#0 dumpsys () at ./machine/thread.h:83
#1 0xc01e6d95 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc01e705a in panic (fmt=0xc0447c39 "ufs_dirbad: bad dir")
at /usr/src/sys/kern/kern_shutdown.c:802
#3 0xc0323b53 in ufs_dirbad (ip=0xf57c9e00, offset=0, how=0xc0447c90 "mangled
entry") at /usr/src/sys/vfs/ufs/ufs_lookup.c:610
#4 0xc0324463 in ufs_lookup (ap=0xf5dccabc)
at /usr/src/sys/vfs/ufs/ufs_lookup.c:275
#5 0xc0325faa in ufs_vnoperate (ap=0xf5dccabc)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:2303
#6 0xc0240948 in vop_old_lookup (ops=0xd554ca50, dvp=0xf5815ee8,
vpp=0xf5dccb24, cnp=0xf5dccb04) at /usr/src/sys/kern/vfs_vopops.c:172
#7 0xc022f252 in vop_compat_nresolve (ap=0xf5dccb58)
at /usr/src/sys/kern/vfs_default.c:225
#8 0xc022ec59 in vop_defaultop (ap=0xf5dccb58)
at /usr/src/sys/kern/vfs_default.c:153
#9 0xc0325faa in ufs_vnoperate (ap=0xf5dccb58)
at /usr/src/sys/vfs/ufs/ufs_vnops.c:2303
#10 0xc0241092 in vop_nresolve (ops=0xd554ca50, nch=0xf5dccb98, dvp=0xf5815ee8,
cred=0xc5be6b98) at /usr/src/sys/kern/vfs_vopops.c:951
#11 0xc022b87f in cache_resolve (nch=0xf5dccbd4, cred=0xc5be6b98)
at /usr/src/sys/kern/vfs_cache.c:2135
#12 0xc0233f4d in nlookup (nd=0xf5dccc80)
at /usr/src/sys/kern/vfs_nlookup.c:499
#13 0xc023c576 in kern_stat (nd=0xf5dccc80, st=0xf5dccc18)
at /usr/src/sys/kern/vfs_syscalls.c:2444
#14 0xc023c714 in sys_stat (uap=0xf5dcccf0)
at /usr/src/sys/kern/vfs_syscalls.c:2485
#15 0xc03fa8e9 in syscall2 (frame=0xf5dccd40)
at /usr/src/sys/platform/pc32/i386/trap.c:1339
#16 0xc03e7be6 in Xint0x80_syscall ()
at /usr/src/sys/platform/pc32/i386/exception.s:876
#17 0x08063527 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
--
Regards,
Rumko

History

#1 Updated by dillon about 5 years ago

:After a previous panic I got this panic while building world. After cleaning
:out /usr/obj I have been unable to repeat this panic again, so it's not
:reproducable (for now).
:
:Dump at leaf:~rumko/crash/bad_dir/ and the backtrace is:
:#0 dumpsys () at ./machine/thread.h:83
:#1 0xc01e6d95 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
:#2 0xc01e705a in panic (fmt=0xc0447c39 "ufs_dirbad: bad dir")

This typically means the (ufs) filesystem got corrupted somehow.
The panic is usually delayed significantly from the cause (by minutes,
hours, or days), so by the time the panic occurs the original cause
will have been lost.

-Matt

#2 Updated by tuxillo over 1 year ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Assignee deleted (0)

Hi

As per Matt's comment it seems unlikely to find a root cause for this. Additionally, extensive UFS stressing has been performed by Venk recently and as far as I know this problem has not appeared.

In the case there isn't feedback which proves this wrong, this ticket will be closed.

Cheers,
Antonio Huete

Also available in: Atom PDF