Problem with firewire disks with recent -CURRENT.

Tried upgrading one of my machines to -CURRENT yesterday and got the 
following panic when the sbp code did its probing of all the firewire 
devices:


sbp0: <SBP-2/SCSI over FireWire> on firewire0
sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:14 EUI:00048304ee01f418 node:
1 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:0:0 'DAT Optic Inc   ' 'Master  ' '000040'
sbp0: sbp_show_sdev_info: sbp0:0:1: ordered:1 type:14 EUI:00048304ee01f418 node:
1 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:0:1 'DAT Optic Inc   ' 'Master  ' '000040'
sbp0: sbp_show_sdev_info: sbp0:1:0: ordered:1 type:1 EUI:00d080043f208713 node:0
 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:1:0 'EXABYTE ' 'VXA-3a          ' '000201'
sbp1: <SBP-2/SCSI over FireWire> on firewire1
panic: mutex sbp not owned at /usr/src/sys/cam/cam_xpt.c:4549
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff81fe6837f0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff81fe6838a0
vpanic() at vpanic+0x126/frame 0xffffff81fe6838e0
panic() at panic+0x43/frame 0xffffff81fe683940
__mtx_assert() at __mtx_assert+0xc2/frame 0xffffff81fe683950
xpt_compile_path() at xpt_compile_path+0xa1/frame 0xffffff81fe6839a0
xpt_create_path() at xpt_create_path+0x5b/frame 0xffffff81fe6839f0
sbp_do_attach() at sbp_do_attach+0xe8/frame 0xffffff81fe683a30
fwohci_txd() at fwohci_txd+0x378/frame 0xffffff81fe683a90
fwohci_task_dma() at fwohci_task_dma+0x5d4/frame 0xffffff81fe683b30
taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xffffff81fe683b80
taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xffffff81fe683bb0
fork_exit() at fork_exit+0x84/frame 0xffffff81fe683bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xffffff81fe683bf0
--- trap 0, rip = 0, rsp = 0xffffff81fe683cb0, rbp = 0 ---

(alas, it happened too early to get an actual core file, but dcons let me get
the console data logged to another machine.)

I'm guessing the recent changes to cam_xpt and friends in mid-April might 
be to blame...