6.0 BETA2: dump to gmirror panic

I got the panic below when I tried dump | restore to a single disk
gmirror. I then went to retry the procedure to see whether the panic
was reproducible, and this time the restore provoked a loop: the box
still runs 20 hours after the dump got stuck, but the console keeps
spewing these messages (actual offsets and lengths vary):

g_vfs_done():mirror/gm0s1a[WRITE(offset=155058176, length=16384)]error = 6

I broke to the debugger, but kgdb doesn't like the core produced by
panic:

# kgdb kernel.debug /var/crash/vmcore.1
kgdb: kvm_read: invalid address (0xc23ffa3c)

The kernel is GENERIC minus scsi, usb, firewire, isa nics, witness- and
invariants- related options.

# cd /usr/obj/usr/src/sys/ZIGGY_0/
# kgdb kernel.debug /var/crash/vmcore.0 
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0  doadump () at pcpu.h:165
165             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:165
#1  0xc0432a53 in db_fncall (dummy1=0, dummy2=0, dummy3=-1067111529, 
    dummy4=0xd44b78b4 "ŕxKÔ\020\023eŔĚxKÔĐxKÔ\220\a") at /usr/src/sys/ddb/db_command.c:489
#2  0xc0432858 in db_command (last_cmdp=0xc0718764, cmd_table=0x0, aux_cmd_tablep=0xc06b0a18, 
    aux_cmd_tablep_end=0xc06b0a1c) at /usr/src/sys/ddb/db_command.c:349
#3  0xc0432920 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#4  0xc04344d1 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#5  0xc05098af in kdb_trap (type=3, code=0, tf=0xd44b79f4) at /usr/src/sys/kern/subr_kdb.c:473
#6  0xc066be24 in trap (frame=
      {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1, tf_esi = -1066771535, tf_ebp = -733251020, tf_isp = -733251040, tf_ebx = -733250976, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068460493, tf_cs = 32, tf_eflags = 524946, tf_esp = -733250988, tf_ss = -1068559525}) at /usr/src/sys/i386/i386/trap.c:601
#7  0xc065b9fa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#8  0x00000008 in ?? ()
#9  0x00000028 in ?? ()
#10 0x00000028 in ?? ()
#11 0x00000001 in ?? ()
#12 0xc06a5bb1 in ?? ()
#13 0xd44b7a34 in ?? ()
#14 0xd44b7a20 in ?? ()
#15 0xd44b7a60 in ?? ()
#16 0x00000000 in ?? ()
#17 0xc1015000 in ?? ()
#18 0x00000012 in ?? ()
#19 0x00000003 in ?? ()
#20 0x00000000 in ?? ()
#21 0xc0509633 in kdb_enter (msg=0x0) at cpufunc.h:60
#22 0xc04f135b in panic (fmt=0xc06a5bb1 "initiate_write_inodeblock_ufs2: already started")
    at /usr/src/sys/kern/kern_shutdown.c:537
#23 0xc060117a in initiate_write_inodeblock_ufs2 (inodedep=0xc1e10780, bp=0x0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:3812
#24 0xc0600a3f in softdep_disk_io_initiation (bp=0xcb351158)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:3552
#25 0xc06086c6 in ffs_geom_strategy (bo=0xc1dc80c0, bp=0xcb351158) at buf.h:422
#26 0xc0535234 in bufwrite (bp=0xcb351158) at buf.h:415
#27 0xc0608686 in ffs_bufwrite (bp=0xcb351158) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1664
#28 0xc0536ca3 in vfs_bio_awrite (bp=0xcb351158) at buf.h:399
#29 0xc0537a29 in flushbufqueues (flushdeps=0) at /usr/src/sys/kern/vfs_bio.c:2107
#30 0xc053752b in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1981
#31 0xc04dbde8 in fork_exit (callout=0xc0537448 <buf_daemon>, arg=0x0, frame=0xd44b7d38)
    at /usr/src/sys/kern/kern_fork.c:789
#32 0xc065ba5c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208
(kgdb) 


-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991