Bug #1850

volume-add on hammer root fs panic

Added by Johannes.Hofmann almost 4 years ago. Updated almost 4 years ago.

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

0%

Category:-
Target version:-

Description

Hi,

expanding a hammer root filesystem with hammer volume-add (which is
pretty cool btw) leads to a panic on shutdown:

panic: assertion: (bp->b_flags & B_LOCKED) == 0 && iou->io.running ==
0 in hammer_io_deallocate

After a reboot everything is ok.
The problem can be reproduced in a vkernel.

Johannes

PS: One minor issue: The values df reports seem a bit off after
the volume-add. They also are fine after a reboot.

Program received signal SIGTRAP, Trace/breakpoint trap.
Debugger (msg=0x8294114 "panic") at /usr/src/sys/platform/vkernel/i386/db_interface.c:334
334 in_Debugger = 0;
(gdb) bt
#0 Debugger (msg=0x8294114 "panic") at /usr/src/sys/platform/vkernel/i386/db_interface.c:334
#1 0x080e3bfd in panic (fmt=0x827b38c "assertion: %s in %s") at /usr/src/sys/kern/kern_shutdown.c:743
#2 0x08224a05 in hammer_io_deallocate (bp=0x5071f260) at /usr/src/sys/vfs/hammer/hammer_io.c:1093
#3 0x0812b79d in buf_deallocate (bp=0x5071f260) at /usr/src/sys/sys/buf2.h:239
#4 brelse (bp=0x5071f260) at /usr/src/sys/kern/vfs_bio.c:1273
#5 0x0813f901 in vinvalbuf_bp (bp=0x5071f260, data=0x544659dc) at /usr/src/sys/kern/vfs_subr.c:424
#6 0x0813c8ae in buf_rb_tree_RB_SCAN (head=0x567de51c, scancmp=0x813c7bc <buf_rb_tree_SCANCMP_ALL>,
callback=0x813f7e9 <vinvalbuf_bp>, data=0x544659dc) at /usr/src/sys/kern/vfs_subr.c:141
#7 0x0813f2b3 in vinvalbuf (vp=0x567de4c8, flags=1, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:334
#8 0x0813f434 in vclean_vxlocked (vp=0x567de4c8, flags=8) at /usr/src/sys/kern/vfs_subr.c:1142
#9 0x0813f622 in vgone_vxlocked (vp=0x567de4c8) at /usr/src/sys/kern/vfs_subr.c:1349
#10 0x0814212b in vflush_scan (mp=0x545c3fc0, vp=0x567de4c8, data=0x54465b4c) at /usr/src/sys/kern/vfs_mount.c:1252
#11 0x081422aa in vmntvnodescan (mp=0x545c3fc0, flags=2, fastfunc=0, slowfunc=0x81420ac <vflush_scan>, data=0x54465b4c)
at /usr/src/sys/kern/vfs_mount.c:1068
#12 0x081424cd in vflush (mp=0x545c3fc0, rootrefs=0, flags=2) at /usr/src/sys/kern/vfs_mount.c:1184
#13 0x08213aa3 in devfs_unmount (mp=0x545c3fc0, mntflags=524288) at /usr/src/sys/vfs/devfs/devfs_vfsops.c:142
#14 0x08150d79 in vfs_unmount (mp=0x545c3fc0, mntflags=524288) at /usr/src/sys/kern/vfs_vfsops.c:123
#15 0x08145e40 in dounmount (mp=0x545c3fc0, flags=524288) at /usr/src/sys/kern/vfs_syscalls.c:755
#16 0x0813e3ae in vfs_umountall_callback (mp=0x545c3fc0, data=0x0) at /usr/src/sys/kern/vfs_subr.c:1714
#17 0x081427fb in mountlist_scan (callback=0x813e39b <vfs_umountall_callback>, data=0x0, how=<value optimized out>)
at /usr/src/sys/kern/vfs_mount.c:900
#18 0x0813d9d3 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:1703
#19 0x080e3503 in boot (howto=8) at /usr/src/sys/kern/kern_shutdown.c:376
#20 0x080e3801 in sys_reboot (uap=0x54465c94) at /usr/src/sys/kern/kern_shutdown.c:204
#21 0x08271b77 in syscall2 (frame=0x54465d40) at /usr/src/sys/platform/vkernel/i386/trap.c:1221
#22 0x08271f42 in user_trap (frame=0x54465d40) at /usr/src/sys/platform/vkernel/i386/trap.c:410
#23 0x0827263e in go_user (frame=0x54465d38) at /usr/src/sys/platform/vkernel/i386/trap.c:1427
#24 0x0827290e in pmsg4 () at /usr/src/sys/platform/vkernel/i386/fork_tramp.s:103

History

#1 Updated by mneumann almost 4 years ago

Am 23.09.2010 22:50, schrieb Johannes Hofmann:
> Hi,
>
> expanding a hammer root filesystem with hammer volume-add (which is
> pretty cool btw) leads to a panic on shutdown:
>
> panic: assertion: (bp->b_flags & B_LOCKED) == 0 && iou->io.running ==
> 0 in hammer_io_deallocate
>
> After a reboot everything is ok.
> The problem can be reproduced in a vkernel.

Which version of DragonFly are you using? I remember a similar issue
while I developed volume-add, but I thought I have fixed it.

Regards,

Michael

Also available in: Atom PDF