From owner-svn-src-head@FreeBSD.ORG Thu Sep 23 14:49:02 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B112E106566B; Thu, 23 Sep 2010 14:49:02 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3431B8FC0A; Thu, 23 Sep 2010 14:49:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA26161; Thu, 23 Sep 2010 17:48:59 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C9B68DB.9010401@freebsd.org> Date: Thu, 23 Sep 2010 17:48:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201009211507.o8LF7iVv097676@svn.freebsd.org> <4C9A6EE6.5050301@freebsd.org> <20100922222441.00002f27@unknown> <201009230953.56201.jhb@freebsd.org> In-Reply-To: <201009230953.56201.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gavin Atkinson , src-committers@freebsd.org Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 14:49:02 -0000 on 23/09/2010 16:53 John Baldwin said the following: > minidumps have made the time issue less of a concern on large-memory systems > (full dumps do indeed take a long time on modern systems). I think textdumps > are just as likely to fail as regular dumps though since they both use the > same code for writing out the dump, they just write different bits to the dump > area. Well, minidumps are not always very small. And there's still that issue of other CPUs still running during panic->dumping and thus (mini-)dump maps getting changed (larger) after dump size calculations which results in an aborted dump. -- Andriy Gapon