From owner-cvs-all@FreeBSD.ORG Mon Oct 3 17:31:38 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 047A916A41F; Mon, 3 Oct 2005 17:31:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9B243D45; Mon, 3 Oct 2005 17:31:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j93HVXdP015472; Mon, 3 Oct 2005 11:31:33 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43416AF6.7010908@samsco.org> Date: Mon, 03 Oct 2005 11:31:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <200510022257.j92MvV4N007297@repoman.freebsd.org> <20051003094732.H71864@fledge.watson.org> <43416038.6020701@root.org> In-Reply-To: <43416038.6020701@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson , Olivier Houchard , cvs-all@FreeBSD.org 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 17:31:38 -0000 Nate Lawson wrote: > Robert Watson wrote: > >> On Sun, 2 Oct 2005, Olivier Houchard wrote: >> >>> cognet 2005-10-02 22:57:31 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/ddb db_command.c db_output.c >>> Log: >>> - Call db_setup_paging() for traceall. >>> - Make it so one can't call db_setup_paging() if it has already been >>> called >>> before. traceall needs this, or else the db_setup_paging() call from >>> db_trace_thread() will reset the printed line number, and override its >>> argument. >>> This is not perfect for traceall, because even if one presses 'q' >>> while in >>> the middle of printing a backtrace it will finish printing the >>> backtrace >>> before exiting, as db_trace_thread() won't be notified it should >>> stop, but >>> it is hard to do better without reworking the pager interface a lot >>> more. >> >> >> >> Thanks! >> >> 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. Then the results can >> be pulled off easily in a format that is appropriate for e-mailing or >> submitting via a PR, even without a full debugging kernel, etc. Among >> other things, these dumps would be much, much smaller than a memory >> dump, meaning they could be kept around like log files >> (/var/log/crash.log.0, ...), be e-mailed to the sysadmin, etc. It >> would require some new magic in DDB and the dumping code, but almost >> all of the logic to generate the information from DDB could be reused, >> perhaps via an alternative pager or debug output device :-). > > > 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. > Well, what Robert is talking about isn't really a 'dump' in the sense of using kgdb, it's more 'run every debugger command available and capture the output to disk' =-) I can't recall if I've sent email on this before, but it would be neat if we had the following levels of dump: 0: all RAM 1: all KVM 2: all proc, thread, and pcb data Scott