Subject: Re: pool_reclaim panic [resolved]
To: Stephen Borrill <netbsd@precedence.co.uk>
From: Andrew Doran <ad@netbsd.org>
List: port-i386
Date: 09/12/2007 18:50:43
On Tue, Sep 11, 2007 at 08:34:00PM +0100, Stephen Borrill wrote:

> On Tue, 11 Sep 2007, Stephen Borrill wrote:
> >Here's a repeatable (happens every hour or so) panic on NetBSD 3.1_STABLE. 
> >This has been dictated on the phone by a customer, so might not be exact. 
> >This machine has 2x 512MB DIMMs, we've run memtest86 w/o probs and tried 
> >various combinations of RAM sticks and slots. This machine and software is 
> >pretty much the same as other machines at other sites which are not having 
> >this problem.
> >
> >uvm fault: kernel page fault trap
> >stopped in pid 20.1 pagedaemon at NetBSD:pool_reclaim+0x92:mov1
> >db> bt
> >pool_reclaim at NetBSD:pool_reclaim+0x92
> >pool_drain at NetBSD:pool_drain+0x45
> >uvm_pageout at NetBSD:uvm_pageout+0x11e
> >
> >Any idea where to start looking?
> 
> Heh (replying to my own mail). Upon further investigation, the customer in 
> question has a few PCs checking the OpenOffice.org update site 1000 times 
> a second (and being denied by squid access rules otherwise it would have 
> saturated their 2Mb 'net connection). Out of 79345566 requests in the 
> squid logs, 79216874 were for this page with about 1.1MB per second of 
> network traffic just being squid access denied pages.
> 
> So a fairly severe unintentional DoS attack and so sorry for bothering you 
> all. However, I'd be interested in opinions on whether NetBSD should have 
> been able to stand up to this.

It should be able to stand up to this, yes. Did you get a crashdump from the
system?

Thanks,
Andrew