DragonFlyBSD

:Using HEAD of yesterday, Feb 8, 2009,
:I got this panic at shutdown.
:
:Have seen same panic a few times using 2.0.1.
:
:Uploading crash dump to leaf as .28.
:
: -thomas

Upload your hammer.ko module as well, I need it to debug the hammer
    part of the trace and related structures.

I just fixed a ref count issue in master that might be the cause.
    I won't be able to rule it in our out until I look at the core.

-Matt

Ahh, I don't have the hammer module for this build anymore
(just installed new kernel twice); will save it next time.

-thomas

New crash dump using HEAD of Feb 12, 2009.

Uploading to leaf as *.29 (with all modules in use).

-thomas

:Thomas Nikolajsen <thomas.nikolajsen@mail.dk> added the comment:
:
:New crash dump using HEAD of Feb 12, 2009.
:
:Uploading to leaf as *.29 (with all modules in use).
:
: -thomas

Thomas, I believe I have found it.  Please try the enclosed patch.
    When a buffer collision occurs under heavy loads a ref on the volume
    structure was not being undone, leading to a ref count leak on the
    volume structure which will result in a panic on umount.

This fix will not make it into 2.2.  It needs to be tested and verified
    to have fixed the problem, then I'll commit and MFC it.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

diff --git a/sys/vfs/hammer/hammer_ondisk.c b/sys/vfs/hammer/hammer_ondisk.c
index 711fe65..214e1ff 100644
--- a/sys/vfs/hammer/hammer_ondisk.c
+++ b/sys/vfs/hammer/hammer_ondisk.c
@ -639,8 +639,10 @ again: * Insert the buffer into the RB tree and handle late collisions.
/
if (RB_INSERT(hammer_buf_rb_tree, &hmp->rb_bufs_root, buffer)) {
- hammer_unref(&buffer->io.lock);
+ hammer_unref(&buffer->io.lock); / safety /
--hammer_count_buffers;
+ hammer_rel_volume(volume, 0);
+ buffer->io.volume = NULL; / safety */
kfree(buffer, hmp->m_misc);
goto again;
}

::Thomas Nikolajsen <thomas.nikolajsen@mail.dk> added the comment:
::
::New crash dump using HEAD of Feb 12, 2009.
::
::Uploading to leaf as *.29 (with all modules in use).
::
:: -thomas
:
: Thomas, I believe I have found it. Please try the enclosed patch.
: When a buffer collision occurs under heavy loads a ref on the volume
: structure was not being undone, leading to a ref count leak on the
: volume structure which will result in a panic on umount.
:
: This fix will not make it into 2.2. It needs to be tested and verified
: to have fixed the problem, then I'll commit and MFC it.
:
: -Matt
: Matthew Dillon
: <dillon@backplane.com>

I've committed the patch.  Did you try it and get any more crashes
    on umount from that particular volume.io.refs assertion?

-Matt

I have applied patch to 2.2.0-RELEASE, no panic seen.
Thank you for fixing, I have closed issue.

-thomas

panic at shutdown using 2.2-RELEASE from 17th Feb 2009
with patch from this case applied;
same as 530dd4947cb729aeaa1e5b57df82ff510cb0a49b.

Seems like panic doesn't occur so often after patch applied,
but it apparently still can happen.

Btw: it seems like commit isn't MFCed to 2.2-RELEASE yet (I could do this).

Uploading to leaf as *.30 (with all modules in use).

thomas

panic: assertion: volume->io.lock.refs == 0 in hammer_unload_volume
Trace beginning at frame 0xc4d59b4c
panic(c4d59b70,c0d9b308,c0e1d59c,d2064000,c4d59b88) at panic+0x8c
panic(c055c9b2,c055d1dc,c055c001,1108,c0d9b308) at panic+0x8c
hammer_unload_volume(c0d9b308,0,0,0,0) at hammer_unload_volume+0x6c
hammer_vol_rb_tree_RB_SCAN(d206400c,0,c05494fe,0,d206402c) at 
hammer_vol_rb_tree_RB_SCAN+0xad
hammer_free_hmp(c7a47a10,c7a47808,c4d59c2c,c01f1f61,c7a47808) at 
hammer_free_hmp+0x186
hammer_vfs_unmount(c7a47808,80000,80000,c7a47828,1) at hammer_vfs_unmount+0x33
dounmount(c7a47808,80000,c7a47808,1,c4d59c7c) at dounmount+0x1a8
vfs_umountall_callback(c7a47808,0,c0416534,0,1) at vfs_umountall_callback+0x13
mountlist_scan(c01eacc5,0,6) at mountlist_scan+0xe8
vfs_unmountall(0,0,3,c019dece,c0d66140) at vfs_unmountall+0x11
boot(4008,c4d59d34,c0305d25,c4d59cf0,6) at boot+0x21d
sys_reboot(c4d59cf0,6,98b6,0,c7a44f88) at sys_reboot+0x25
syscall2(c4d59d40) at syscall2+0x1ef
Xint0x80_syscall() at Xint0x80_syscall+0x36

Matt,

any update on this? did you figure out why the panic can still happen?

Cheers,
Alex Hornung