Ugh. Of course it takes forever for gdb to get going on the crash dump
because of the lousy paging performance... but...

Jukka Marin writes:
>Two easy ways to crash a NetBSD system - is it only my system or...?
>
>1. main(void) { while(1) fork(); }
>


GDB 4.11 (i386-netbsd), Copyright 1993 Free Software Foundation, Inc...
panic: vm_map_entry_create: out of map entries
#0  0xf81abdf7 in vm_fork (p1=0xf7fdf000, p2=0x2)
    at ../../../../vm/vm_glue.c:223
223             p2->p_vmspace = vmspace_fork(p1->p_vmspace);
(kgdb) print panicstr
$1 = 0xf81acc3d "vm_map_entry_create: out of map entries"
(kgdb) 


Running gdb, I get the kernel message 
"/netbsd: mb_map full".. same as a friend of mine gets right before X
brings down his machine (hard resets it...) Hmm...

>2. use dd to copy data from a raw disk partition to /dev/null and set
>   the block size to a big value (like 8 megs).
>
(70)tuba:/var/crash>su
Password:
tuba# dd if=/dev/rwd0a of=/dev/null bs=8000k count=1k
rlogin: read: Connection reset by peer.
                                       rlogin: connection closed.
(63)trumpet:~>

GDB 4.11 (i386-netbsd), Copyright 1993 Free Software Foundation, Inc...
panic: ptdi %x
#0  0x40e000 in ?? ()
(kgdb) where
#0  0x40e000 in ?? ()
(kgdb) print panicstr
$1 = 0xf81b909c "ptdi %x"
(kgdb) 

f81b8f44 T _pmap_protect
f81b90a4 T _pmap_enter
f81b92f0 T _pmap_page_protect

Cute!

>I'm not trying to start a war - I just don't feel comfortable with the
>possibility that _any_ user can crash the system with a 1-line C program.
>
>I'm running a 960210 kernel, if that matters.

960323 sources here.