From owner-freebsd-hackers Tue Feb 16 13:54: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1BF8B11057 for ; Tue, 16 Feb 1999 13:54:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA39295; Tue, 16 Feb 1999 13:53:57 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 13:53:57 -0800 (PST) From: Matthew Dillon Message-Id: <199902162153.NAA39295@apollo.backplane.com> To: Jonathan Lemon Cc: hackers@FreeBSD.ORG Subject: Re: system freeze while core dumping References: <19990216154205.64792@right.PCS> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 0 540 0 0 0.0 3533 124 8.1 0 0 0.0 0 0 0.0 1 0 0 0 99 : 0 81 0 0 0.0 3485 121 8.3 0 0 0.0 0 0 0.0 0 0 0 0100 : :top shows the coredumping process seems to be perpetually waiting :on "getblk". : :How can I prevent the dumping process from essentially freezing the :system until it finishes? The problem also exists on a 3.0-CURRENT :machine from November. :-- :Jonathan This *may* have been fixed in -current with the getpbuf() fixes. I'm not entirely sure, but I seem to recall that the core dumping caused VFS clustering to occur which ( because it is essentially asynchronous ) ate all available pbuf's. The fix in -4.x limits the number of pbuf's that the clustering code can eat. Even if it is fixed, it probably still isn't optimal. The getpbuf() stuff is going to be backported to -3.x in the next month or two probably ( just to standardize the interface for the device drivers that use it ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message