Bug #1444

DFBSD 2.3.2 - Panic while installworld on a vn device

Added by tuxillo over 4 years ago. Updated over 4 years ago.

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

0%

Category:-
Target version:-

Description

Hi,

Details:
P4 1.5GB
2.3.2 (28 July)
HAMMER root (/)

----
While doing a 'make reinstall32' in test/vkernel, I got a panic.
Currently I'm trying to reproduce it.
The memfile is 1.5GB so I doubt I could be able to upload it.

Unread portion of the kernel message buffer:
/dev/vn0s1a: bad dir ino 159 at offset 0: mangled entry
panic: ufs_dirbad: bad dir
Trace beginning at frame 0xe0fe9ac8
panic(e0fe9aec,d70f1118,e0755200,0,e0fe9af0) at panic+0x8c
panic(c058872a,c4640000,e0fe9b78,c0467ecf,e0755200) at panic+0x8c
ufs_dirbad(e0755200,0,c0588781,2,e0fe9b20) at ufs_dirbad+0x3a
ufs_lookup(e0fe9b90,e0fe9bb4,c03616f4,e0fe9b90,c0627de8) at ufs_lookup+0x2eb
ufs_vnoperate(e0fe9b90,c0627de8,c38781b0,2,e0724828) at ufs_vnoperate+0x11
vop_old_lookup(c38781b0,e0724828,e0fe9bdc,e0fe9be0,e0fe9be0) at vop_old_lookup+0x2c
vop_compat_nremove(e0fe9c30,e0fe9c24,c0469bc5,e0fe9c30,e0fe9c5c) at
vop_compat_nremove+0x97
vop_defaultop(e0fe9c30,e0fe9c5c,c0362295,e0fe9c30,c0627f80) at vop_defaultop+0x11
ufs_vnoperate(e0fe9c30,c0627f80,c38781b0,d70f3998,0) at ufs_vnoperate+0x11
vop_nremove(c38781b0,e0fe9c84,e0724828,c3727bc8) at vop_nremove+0x31
kern_unlink(e0fe9c84,e06bbca8,d70f1118,c36e6d58,d70e6618) at kern_unlink+0x44
sys_unlink(e0fe9cf0,6,0,0,d70f3998) at sys_unlink+0x2a
syscall2(e0fe9d40) at syscall2+0x1ef
Xint0x80_syscall() at Xint0x80_syscall+0x36
Uptime: 31m37s

Backtrace
------------------------------------------------
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc030cc32 in boot (howto=260) at
/home/source/dfbsd/sys/kern/kern_shutdown.c:375
#2 0xc030cd53 in panic (fmt=0xc058872a "ufs_dirbad: bad dir")
at /home/source/dfbsd/sys/kern/kern_shutdown.c:801
#3 0xc04675bf in ufs_dirbad (ip=0xe0755200, offset=0, how=0xc0588781 "mangled
entry")
at /home/source/dfbsd/sys/vfs/ufs/ufs_lookup.c:610
#4 0xc0467ecf in ufs_lookup (ap=0xe0fe9b90) at
/home/source/dfbsd/sys/vfs/ufs/ufs_lookup.c:275
#5 0xc0469bc5 in ufs_vnoperate (ap=0xe0fe9b90) at
/home/source/dfbsd/sys/vfs/ufs/ufs_vnops.c:2445
#6 0xc03616f4 in vop_old_lookup (ops=0xc38781b0, dvp=0xe0724828,
vpp=0xe0fe9bdc, cnp=0xe0fe9be0)
at /home/source/dfbsd/sys/kern/vfs_vopops.c:171
#7 0xc0350575 in vop_compat_nremove (ap=0xe0fe9c30)
at /home/source/dfbsd/sys/kern/vfs_default.c:838
#8 0xc034fac5 in vop_defaultop (ap=0xe0fe9c30) at
/home/source/dfbsd/sys/kern/vfs_default.c:153
#9 0xc0469bc5 in ufs_vnoperate (ap=0xe0fe9c30) at
/home/source/dfbsd/sys/vfs/ufs/ufs_vnops.c:2445
#10 0xc0362295 in vop_nremove (ops=0xc38781b0, nch=0xe0fe9c84, dvp=0xe0724828,
cred=0xc3727bc8)
at /home/source/dfbsd/sys/kern/vfs_vopops.c:1182
#11 0xc035c2a3 in kern_unlink (nd=0xe0fe9c84) at
/home/source/dfbsd/sys/kern/vfs_syscalls.c:2240
#12 0xc035c2d5 in sys_unlink (uap=0xe0fe9cf0) at
/home/source/dfbsd/sys/kern/vfs_syscalls.c:2257
#13 0xc0511883 in syscall2 (frame=0xe0fe9d40)
at /home/source/dfbsd/sys/platform/pc32/i386/trap.c:1339
#14 0xc0501df6 in Xint0x80_syscall () at
/home/source/dfbsd/sys/platform/pc32/i386/exception.s:876
#15 0x0804aabf in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

History

#1 Updated by dillon over 4 years ago

:New submission from Antonio Huete Jimenez <>:
:
:Hi,
:
:Details:
:P4 1.5GB
:2=2E3.2 (28 July)
:HAMMER root (/)
:
:----
:While doing a 'make reinstall32' in test/vkernel, I got a panic.
:Currently I'm trying to reproduce it.
:The memfile is 1.5GB so I doubt I could be able to upload it.
:
:Unread portion of the kernel message buffer:
:/dev/vn0s1a: bad dir ino 159 at offset 0: mangled entry
:panic: ufs_dirbad: bad dir

It's possible you tried to do something while a vkernel was still
running on the disk image, and the UFS image got mangled. That is
about the only thing that could cause that sort of corruption.

The vkernel Makefile does issue a fsck when it mounts the vn to try
to clean up the filesystem (since often people just kill -9 the vkernel
instead of shutdown/halting it normally). 'make mount' does the fsck
and mounts the vn and 'make umount' will unmount it.

-Matt
Matthew Dillon
<>

#2 Updated by corecode over 4 years ago

can we close this?

#3 Updated by ahuete.devel over 4 years ago

Yes, please. It's not happening anymore afaict

2009/8/20 Simon 'corecode' Schubert (via DragonFly issue tracker)
<>:
>
> Simon 'corecode' Schubert <> added the comment:
>
> can we close this?
>
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue1444>
> _____________________________________________________
>

Also available in: Atom PDF