From owner-cvs-all@FreeBSD.ORG Mon Oct 3 20:31:37 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 5EB3816A41F; Mon, 3 Oct 2005 20:31:37 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D5843D48; Mon, 3 Oct 2005 20:31:36 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j93KVeo5002105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Oct 2005 13:31:40 -0700 Message-ID: <4341951F.90006@root.org> Date: Mon, 03 Oct 2005 13:31:27 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <43416038.6020701@root.org> <93558.1128359003@critter.freebsd.dk> <20051003171854.GA18710@soaustin.net> <20051003183854.Q92333@fledge.watson.org> In-Reply-To: <20051003183854.Q92333@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Poul-Henning Kamp , Mark Linimon , Olivier Houchard 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: Mon, 03 Oct 2005 20:31:37 -0000 Robert Watson wrote: > > On Mon, 3 Oct 2005, Mark Linimon wrote: > >> On Mon, Oct 03, 2005 at 07:03:23PM +0200, Poul-Henning Kamp wrote: >> >>> There are pro etc con for both methods. Once a dump has been sitting >>> in a PR for a year, very few people tend to have compatible info >>> tools available. >> >> The counterpoint would be that after a dump has been sitting in a PR >> for a year, the source base will often have drifted so much that any >> prior investigative work needs to be re-run. >> >> I'm hardly arguing against either solution here -- anything that we >> can do to cut out one email round-trip on e.g. the i386/kern PRs can >> only help us. > > After the PR has been sitting there for a year or two, trying to decide > if it's the same bug can be quite difficult if the submitter didn't know > which of a dozen DDB commands to type, or know how to try to extract > kernel debug information using gdb. I'm not saying this is a substitute > for a full dump, but that in many situations, I would get more rather > than less information as a result of what we're talking about. You get the best of both worlds if you have sparse dumps and an addition to rc.d/savecore that does an info dump from the core to a text file. I agree that the text stuff is the most useful for (auto) PR submission. I'd just rather go the path of saving full info and then generating an extract than skipping the intermediate step and generating the abstract directly. That way you always have the option of going back and getting more info. Sparse dumps mean that it's quick when the panic happens and that you can keep more around. With multi-gigabyte RAM being common now but common drive speed being stuck at 7200 RPM, we're losing every day that we don't have sparse dumps. -- Nate