> I want to bring this up again. I only got one confirmation from a macppc
> user, and one deny from a i386 user.
> 
> The procedure is to make a mfs partition 600M or larger by mounting it,
> and then copying something to it that is definately going to overfill
> it. I reproduced this again this morning.
> 
> 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 can get this with -current GENERIC and GENERIC.MP. Are there a lot of
> servers running /tmp as a large mfs?
> 
> tim

hi tim,

i have a few production machines running email-services and ClamAV -- 
that is, a sparc64 box and an i386.

/tmp is used for files temporarily created by clamdscan or clamscan 
while scanning them. i could create a 'real world' scenario by setting 
up another machine and throwing mails w/large attachments on it.

until now, both systems run rock solid (the sparc64 runs RC4, the i386 
runs 2.0BETA)... :))

regards,

timo

ps: yes, the 'another box to setup' would be a mac (G3 b&w or G4).