kernel panic + process hang with md()/ccd()/gbde

I've been having problems of late when writing to a gbde attached ccd()
filesystem (composed of md() devices pointed at files on a ufs1
filesystem).  Copying around 2-3gb of data onto one of these filesystems
usually results in the encrypted filesystem getting hung up on something.
The rest of the system remains stable enough, but any interaction with the
gbde/ccd()/md() filesystem hangs another vt, kill -9 doesn't help.  I
tried running ktrace and watched for syscalls, but instead of a hang I
recieved a kernel panic.  The trace is below:

db> trace
Debugger(c0399acd,c03fe9c0,c03a7293,cfcb0884,1) at Debugger+0x54
panic(c03a7293,ad23,12030,c1ff60d4,81a4) at panic+0xab
ffs_valloc(c1f70c8c,81a4,c217e780,cfcb08dc,c25c2d40) at ffs_valloc+0x175
ufs_makeinode(81a4,c1f70c8c,cfcb0bec,cfcb08c00,602) at ufs_makeinode+0x69
ufs_create(cfcb0a64,cfcb0b20,c026e52f,cfcb0a64,cfcb0a60) at ufs_create+0x39
ufs_vnoperate(cfcb0a64,cfcb0a60,2,c04018c8,c223bbe0) at ufs_vnoperate+0x18
vn_open_cred(cfcb0bd8,cfcb0cd8,1a4,c217e780,cfcb0cc4) at vn_open_cred+0x19f
vn_open(cfcb0bd8,cfcb0cd8,1a4,2ab,c0231b63) at vn_open+0x29
kern_open(c223bbe0,805b048,0,602,81a4) at kern_open+0x13d
open(c223bbe0,cfcb0d10,c03afd77,3fb,3) at open+0x30
syscall(2f,2f,2f,807a700,11) at syscall_0x26e
Xint0x80_syscall() at Xin0x80_syscall+0x1d
--- syscall (5, FreeBSD ELF32, open), eip = 0x804ae67, esp = 0xbfbff8dc,
ebp = xbfbff928 ---

The hangs are not entirely consistent in where/when they tend to occur.

The filesystem was created as such:  4x files 1175000000b in size were
used by md() to create /dev/md1 (through md4), ccdconfig concatenated
these together into ccd0 - I init'd ccd0 with gbde and used a sector_size
of 8192, attached successfully, newfs followed (newfs -b 65536 -m0%
/dev/ccd0.bde), and the filesystem was mounted successfully.  I know the
flags are a bit odd, but the plan was to fill the filesystem once, burn
the 4x files to a dvd-r, and use the filesystem as read-only (encrypted!)
storage.  The hangs are always during a cp -Vr operation from a ufs1
filesystem (ar0s1e) to the filesystem as described above.

I've seen this problem in -current from 5/9/03 and 5/11/03.  Let me know
if there is any other information that would be helpful - thanks in
advance everyone.

-m