From owner-freebsd-hackers Fri Jun 6 03:50:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA12863 for hackers-outgoing; Fri, 6 Jun 1997 03:50:50 -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 DAA12858 for ; Fri, 6 Jun 1997 03:50:47 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08947; Fri, 6 Jun 1997 06:50:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 6 Jun 1997 06: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 GAA09670; Fri, 6 Jun 1997 06:09:16 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id GAA03901; Fri, 6 Jun 1997 06:16:54 -0400 (EDT) Date: Fri, 6 Jun 1997 06:16:54 -0400 (EDT) From: Thomas David Rivers Message-Id: <199706061016.GAA03901@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Subject: Re: Speed of 2.2.1... & "daily panics" Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greeman writes: > > > > >I've noticed a strange thing seems to have happened in recent 2.2., > >uname: > >FreeBSD ponds.water.net 2.2-970510-RELENG FreeBSD 2.2-970510-RELENG #0: Fri May > >16 15:06:15 EDT 1997 rivers@lakes.water.net:/usr/src/sys-970510/compile/POND > >S i386 > > > >My news machine is now taking more than 3 days to expire the news. > >This is a 386dx-33 with ~1.5gig of IDE space... > > > >Version 2.1.7 would expire everything in a matter of hours, > >version 2.2-970510 on the same hardware takes days... > > How much main memory does it have? 8 Meg - but swapinfo indicates very little swap is being used (about 11K) so I don't think things are thrashing... [That hasn't changed from 2.1.7..] Do you suspect a VM algorithm difference? But - of course as soon as I noted I wasn't getting the panics, I got: panic: ufs_ihashget: recursive lock not expected -- pid %d which is consistent with the "stuff on the disk is bad" scenario I'm seeing. I also tried the 970510 kernel on my reliable reproduction of the problem; it still occurs there... it must just be that the machine was "busy." > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project >