From owner-freebsd-current Mon Jul 13 04:18:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA18173 for freebsd-current-outgoing; Mon, 13 Jul 1998 04:18:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA18162 for ; Mon, 13 Jul 1998 04:18:31 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id HAA16504; Mon, 13 Jul 1998 07:17:55 -0400 (EDT) (envelope-from luoqi) Date: Mon, 13 Jul 1998 07:17:55 -0400 (EDT) From: Luoqi Chen Message-Id: <199807131117.HAA16504@lor.watermarkgroup.com> To: aw1@stade.co.uk, current@FreeBSD.ORG Subject: Re: soft updates, ccd, old drives Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jul 13, 1998 at 12:19:50AM -0400, Mikhail Teterin wrote: > > dataout" or similar. This would not respond to ctrl-alt-del, and, > > though the shells were working in other virtual consoles, they > > could not execute anything, including "reboot". So -- cold reset > > to the horrible fsck screenfulls. > > I've been getting something similar. > > The machine has a 2949AU adapter, with a very recent current. With > softupdates enabled everything initially seems fine, but doing anything > slightly heavy causes similar symptoms (forking anything takes an > inordinately long time), with much pounding on one of the discs but > little user program activity. It seems horribly repeatable. I did have > systat/vmstat running for one of these near freezes, and noticed that > freevnodes had a very low value (<10). I suspect this has something to do with the fact that ccd allocates component buffer headers from the main memory pool. Under low memory condition, this allocation would cause paging, if the swap is also on ccd, more component buffer headers are required and would cause more paging, this process multiplies and eventually depletes all memory available, the system slows down to near freeze. Very low freevnodes count is an indication of this memory depletion, so is the slow fork. Try creating a private pool for these component buffer headers, the size of the pool should depend on how many transfers the disks can handle at one time and should be quite small. Or alternatively, set an upper limit on how many buf headers a ccd device could allocate from the main memory pool. This is just a theory. I don't have ccd myself and therefore no way to test it. -lq > > I suspect I need to tune some sysctl variables, but don't have a clue as > to what. > > Possibly unconnected, but very worrying - part of my ppp log appeared in > /etc/motd. I've not noticed any other signs of filesystem corruption. > > -- > Adrian Wontroba, Stade Computers Limited. phone: (+44) 121 681 6677 > Mail info@accu.org for information about the Association of C and C++ Users > or see > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message