Bug #1070

hammer panic

Added by swildner almost 10 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Creating a multi volume filesystem spanning 2 partitions and then trying
to mount_hammer only the first partition triggers an assertion. I can
provide a dump if necessary but it should be fairly reproducable.

Unread portion of the kernel message buffer:
HAMMER(obj) Start Recovery 300000001c642ca8 - 300000001c643500 (2136
bytes of UNDO)(RW)
HAMMER: UNDO record, cannot access buffer 2010000026bbe000
HAMMER(obj) UNDO record at 300000001c643228 failed
HAMMER(obj) End Recovery
Failed to recover HAMMER filesystem on mount
panic: assertion: volume->io.lock.refs == 0 in hammer_unload_volume
panic: from debugger
Uptime: 16m15s

dumping to dev #ad/0x20001, blockno 2097456
dump 1023 [...]

GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-dragonfly".
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc01d5162 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:375
#2 0xc01d5283 in panic (fmt=0xc03c0145 "from debugger") at
#3 0xc01515b1 in db_panic (addr=-1070076140, have_addr=0, count=-1,
modif=0xe60cd858 "") at /usr/src/sys/ddb/db_command.c:447
#4 0xc0151c1c in db_command_loop () at /usr/src/sys/ddb/db_command.c:343
#5 0xc0154194 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#6 0xc037f067 in kdb_trap (type=3, code=0, regs=0xe60cd950) at
#7 0xc038daf7 in trap (frame=0xe60cd950) at
#8 0xc037fd77 in calltrap () at
#9 0xc037ef14 in Debugger (msg=0xc03c8e23 "panic") at ./cpu/cpufunc.h:73
#10 0xc01d527a in panic (fmt=0xc03bd6bf "assertion: %s in %s") at
#11 0xc0304426 in hammer_unload_volume (volume=0xc2653d48, data=0x0) at
#12 0xc0302a1f in hammer_vol_rb_tree_RB_SCAN (head=0xe981f00c,
scancmp=0xc0302929 <hammer_vol_rb_tree_SCANCMP_ALL>, callback=0xc03043d2
data=0x0) at /usr/src/sys/vfs/hammer/hammer_ondisk.c:83
#13 0xc030a143 in hammer_free_hmp (mp=0xcc2b20d8) at
#14 0xc030a8fb in hammer_vfs_mount (mp=0xcc2b20d8, mntpt=0xbfbffbb1
<Address 0xbfbffbb1 out of bounds>, data=0xbfbff920 <Address 0xbfbff920
out of bounds>,
cred=0xc2606c08) at /usr/src/sys/vfs/hammer/hammer_vfsops.c:519
#15 0xc0222585 in sys_mount (uap=0xe60cdcf0) at
#16 0xc038d492 in syscall2 (frame=0xe60cdd40) at
#17 0xc037fe26 in Xint0x80_syscall () at
#18 0x08049864 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


#1 Updated by dillon almost 10 years ago

Try it with the 61F commit. I added an all-volumes-present check.

Matthew Dillon

#2 Updated by aoiko over 9 years ago

Is this still valid?

#3 Updated by aoiko over 9 years ago

Probably ("90% sure") fixed according to originator

Also available in: Atom PDF