From owner-cvs-all@FreeBSD.ORG Tue Oct 4 01:32:02 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FFFA16A41F; Tue, 4 Oct 2005 01:32:02 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C9A43D76; Tue, 4 Oct 2005 01:31:56 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j941VpPZ024131; Tue, 4 Oct 2005 11:31:51 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j941VmXW022017; Tue, 4 Oct 2005 11:31:49 +1000 Date: Tue, 4 Oct 2005 11:31:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <20051003180251.J92333@fledge.watson.org> Message-ID: <20051004110535.E45947@delplex.bde.org> References: <200510022257.j92MvV4N007297@repoman.freebsd.org> <20051003094732.H71864@fledge.watson.org> <43416038.6020701@root.org> <20051003180251.J92333@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Olivier Houchard , cvs-all@FreeBSD.org, Nate Lawson Subject: Re: cvs commit: src/sys/ddb db_command.c db_output.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2005 01:32:02 -0000 On Mon, 3 Oct 2005, Robert Watson wrote: > On Mon, 3 Oct 2005, Nate Lawson wrote: > >>> Is there any chance I can interest you in an idea phk, I, and a few others >>> have been kicking around for a bit relating to smart small dumps? >>> Specifically, we were discussing the idea of allowing a dumping mode in >>> which rather than dumping all of kernel memory, we dump specifically the >>> common and useful output from ddb, such as ps, show locked vnods, show >>> alllocks, traceall, show allpcpu, and so on, basically in text format, to >>> the dump partition. ... >> >> That's fine as a hack-around, but I hope that doesn't distract effort from >> sparse kernel dumps. If you throw out non-anonymous pages, buffer cache, >> etc., you end up with a very small image to begin with. Add in gzip >> compression and it wouldn't be much larger than your uncompressed logs. >> Then you can run whatever info tools you want against the core since no >> actual data is lost. Except the buffer cache and all VMIO pages should be dumped so that fsck(8) can sync the buffer cache. It is common for most pages to be inactive ones with VMIO data in them, so you would often end up with a very large image. Dumping only dirty buffers would take less space, but determining dirty buffers at panic time might trip over locks just like sync on panic, and fsck might want to check the whole buffer cache for integrity. > Actually, there's an important feature difference here is that you get > something that is potentially much more useful/persistent in the long run. To > make use of a kernel core dump, you need a gdb version that understands the > target architecture, a compiled kernel that matches the core, source that > matches the kernel, etc. In absense of these things, the core is a pile of > bytes that, with a high level of effort, you can try to extract data from -- > especially if it was built months or years ago. The idea behind these mini > dumps is that because you're in the kernel run-time environment and the dump > generating code is compiled with the kernel that crashed, it can actually do > some of the interpretation and data extraction up front, providing many of > the details needed for a bug report without requiring use of gdb, kernel > compiles, source trees, and so on. Sure, you'll need those things if you > want to get back to line numbers, so it's not a substitute for a full dump, > but it would be quite handy. I debug very few problems using a full dump, in > part because they are so inconvenient to deal with -- it's hardly ever the > size, it's the complexity of trying to get architectures, source versions, > kernel configurations, etc, aligned. I first thought that I prefered dumping full data so that anything can be looked at later. You rarely know what to look for before a panic occurs. Then I remembered that I really hate (and mostly avoid using) loader(8) since it gives similar complications for initialization. Initialization and finalization belong in the kernel where they can be much simpler and more robust since they don't need to pass parameters across stages and maintain all versions of the parameter passing forever. I turned off kernel dumps a few years ago to avoid bugs from interface churn and haven't missed them. I prefer debugging live kernels anyway. Bruce