From owner-freebsd-hackers Thu Jul 24 18:50:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA07583 for hackers-outgoing; Thu, 24 Jul 1997 18:50:43 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA07578 for ; Thu, 24 Jul 1997 18:50:40 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14246; Thu, 24 Jul 1997 21:50:04 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 24 Jul 1997 21:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id VAA00234; Thu, 24 Jul 1997 21:11:26 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id VAA00269; Thu, 24 Jul 1997 21:20:21 -0400 (EDT) Date: Thu, 24 Jul 1997 21:20:21 -0400 (EDT) From: Thomas David Rivers Message-Id: <199707250120.VAA00269@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!cdsnet.net!mrcpu, ponds!lakes.water.net!rivers, ponds!dyson.iquest.net!toor, ponds!idi.ntnu.no!Tor.Egge Subject: A "data point" on my daily panics... Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - Just to let everyone know I haven't forgotten this point... If you recall, a few weeks ago; I posted a note about the seeming increase in news expiration times with 2.2.2. It's since come out that 2.2.2 may not have been the culprit; but just a series of several bad days in the control group creating *many* files. Anyway - to work around the problem; David G. had suggested increasing the number of NBUFs - to allow for more buffers, which should reduce the I/O. I did so - and got my news system under control... However - it had another surprising side-effect. I've had fewer panics. They now seem to come about every 5 to 6 days (i.e. a little over once a week instead of every day...) The panic continues to be "panic: ffs_valloc: dup alloc" I've also gotten the "bar dir" panic; which I believe is explained by the same scenario... (things not quite making it to disk...) One of the panic's is one I haven't yet seen: panic: ufs_ihashget: recursive lock not expected -- pid %d which, again, could be explained by the same phenomena... Details for those of you who haven't been through all of this: 386dx-33, w/Intel 387 - 8meg memory; 1+GIG IDE hard drive (although, I can duplicate it with an aha1542B and a SCSI drive), running a news feed... the panics seem to occur during the expire. I've duplicated this on two 386dx-33 machines.... the second has 12 meg of memory.... I can demonstrate the problem doing a newfs when the system isn't multiuser; so I don't believe it's "stress" related. So - increasing the number of buffers does seem to decrease the probability of hitting the problem - which could help to explain why those of you with large physical memory (on which the NBUF calculation is made, if you don't override it) can potentially mask the problem... - Dave Rivers -