> 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.