Date: Thu, 24 Jul 1997 21:20:21 -0400 (EDT) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> 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... Message-ID: <199707250120.VAA00269@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707250120.VAA00269>