Project

General

Profile

Actions
Copy link

Bug #1444

closed

DFBSD 2.3.2 - Panic while installworld on a vn device

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

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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?)

Actions
Copy link
 #1

Updated by dillon over 15 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 
                    &lt;&gt;
Actions
Copy link
 #2

Updated by corecode over 15 years ago

can we close this?

Actions
Copy link
 #3

Updated by ahuete.devel over 15 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>
_____________________________________________

Actions
Copy link

Also available in: Atom PDF