I have confirmation of this on a system independent of my own, and now
we're trying to determine if this is an architectural issue or farther
reaching.

Net7300# mkdir /mfs
Net7300# mount_mfs -s 600m ffs /mfs
Net7300# cp -R /usr/* /mfs
panic: kernel diagnostic assertion "pcb->pcb_kmapsr == 0" failed: file
"../../..
/../arch/powerpc/powerpc/trap.c", line 546
Stopped in pid 371.1 (mount_mfs) at     netbsd:cpu_Debugger+0x10:
lwz r0, r1, 0x14
db{1}> bt
0xd521fc40: at panic+0x19c
0xd521fcd0: at __assert+0x28
0xd521fce0: at copyout+0x14c
0xd521fd70: at mfs_doio+0x84
0xd521fd90: at mfs_start+0xa8
0xd521fdd0: at sys_mount+0x414
0xd521fed0: at syscall_plain+0xc8
0xd521ff40: user SC trap #21 by 0x418839b8: srr1=0xf032
            r1=0xffffd990 cr=0x22000044 xer=0 ctr=0x418839b0


I'm posting here because it's been pointed out to me that if a
server is using a large mfs as /tmp, it might be possible for any user
that can download files in a web browser (like PDFs) to cause the above
kernel panic. This seems like a good forum for finding people willing to
test this on different archs (macppc -current kernel, RC4 userland for
me does this). I've tried 300M and below and I get file system full
errors, but 600M and higher cause kernel panics. I haven't pinpointed
the exact number, but I didn't figure that all that important.

thanks,
tim