DragonFlyBSD

Hi.
Running git-clone to a HAMMER filesystem instantly triggers a kernel panic
while just cpdup'ing the repository to a HAMMER filesystem doesn't. Both
kernel and the world is freshly built from the latest 2.0 source. I also
ran newfs_hammer to make sure I don't have stale filesystem. I can reproduce
the panic without running cpdup prior to git-clone. The git repo to be
cloned doen't need to be large, just a single change set is enough, but
it often locks up during the kernel dumping. I'm transfering the vmcore
to leaf right now, but it seems to take more than an hour.

1. cd
2. mkdir test && cd test && git init
3. echo TEST > TEST
4. git add TEST
5. git commit -m TEST

1. cd /HAMMER
2. cpdup /where/I/keep/git/pkgsrc cpdupped (no crash)
3. sync; sync; sync
4. git-clone --bare ~/test git (panic)

Fatal trap 12: page fault while in kernel mode
mp_lock = 00000000; cpuid = 0; lapic.id = 00000000
fault virtual address = 0x98
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0256ca9
stack pointer = 0x10:0xd5eb79e8
frame pointer = 0x10:0xd5eb79e8
code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1047 (git)
current thread = pri 6
<- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 00000000; cpuid = 0
boot() called on cpu#0

(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc0198cbd in boot (howto=256)
at /home/source/dragonfly/R2_0/src/sys/kern/kern_shutdown.c:375
#2 0xc0198f80 in panic (fmt=0xc02d8f68 "%s")
at /home/source/dragonfly/R2_0/src/sys/kern/kern_shutdown.c:800
#3 0xc02b13a2 in trap_fatal (frame=0xd5eb79a0, eva=<value optimized out>)
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1138
#4 0xc02b14dc in trap_pfault (frame=0xd5eb79a0, usermode=0, eva=152)
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1039
#5 0xc02b1b0c in trap (frame=0xd5eb79a0)
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:719
#6 0xc029e9c7 in calltrap ()
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/exception.s:785
#7 0xc0256ca9 in hammer_modify_inode (ip=0xd5e05500, flags=1)
at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_inode.c:1342
#8 0xc025e448 in hammer_ip_add_directory (trans=0xd5eb7af0, dip=0xd2981250,
name=0xc25091c0 "02d41ce21323b1cdc228c78cec2f81c054bd34", bytes=38,
ip=0xd5e05500)
at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_object.c:630
#9 0xc0267dab in hammer_vop_nlink (ap=0xd5eb7b2c)
at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_vnops.c:1010
#10 0xc01ecdfd in vop_nlink (ops=0xcc3b0170, nch=0xd5eb7c48, dvp=0xd5e223e8,
vp=0xd5e3ec28, cred=0xd5bd2c18)
at /home/source/dragonfly/R2_0/src/sys/kern/vfs_vopops.c:1091
#11 0xc01e84b1 in kern_link (nd=0xd5eb7c80, linknd=0xd5eb7c48)
at /home/source/dragonfly/R2_0/src/sys/kern/vfs_syscalls.c:2080
#12 0xc01e851c in sys_link (uap=0xd5eb7cf0)
at /home/source/dragonfly/R2_0/src/sys/kern/vfs_syscalls.c:2102
#13 0xc02b223f in syscall2 (frame=0xd5eb7d40)
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1384
#14 0xc029ea76 in Xint0x80_syscall ()
at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/exception.s:876
#15 0x282e6324 in ?? ()

Cheers.