> From: Jukka Marin <jmarin@teeri.jmp.fi>
> Date: Wed, 3 Apr 1996 22:51:11 +0300 (EET DST)
> X-Mailer: ELM [version 2.4 PL25]
> Content-Type: text
> Sender: owner-current-users@NetBSD.ORG
> Precedence: list
> X-Loop: current-users@NetBSD.ORG
> 
> Two easy ways to crash a NetBSD system - is it only my system or...?
> 
> 1. main(void) { while(1) fork(); }
> 
> 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).

  2a. Put a lot of RAM in your machine (like >= 64 Megs), and you will
      get these ptdi panics periodically even if you have increased
      NKPDE and don't make huge reads from raw devices.

  3. Blast 8K UDP packets at a NetBSD machine over a local ethernet.
     You will run out of mbufs, and so m_reclaim() will drain the
     protocol queues.  If you were traversing the ipq or in ip_freef()
     when the network interrupt arrives, the fragment may be freed
     underneath you resulting in a page fault when you return to
     ipintr().

Doesn't mean I'm not a NetBSD fan--I just thought I'd add mine while
we were making a list.

David

P.S.  If you are desperate about 3 as I was, you can simply change the
mbuf code not to call m_reclaim when M_DONTWAIT is requested.  In at
least some cases you can get lower IP packet loss this way.  I'm not
advocating this as the proper fix, though.