From owner-svn-src-all@FreeBSD.ORG Tue Sep 28 19:07:52 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60939106564A; Tue, 28 Sep 2010 19:07:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2198FC19; Tue, 28 Sep 2010 19:07:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9DB1B46B90; Tue, 28 Sep 2010 15:07:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C5218A04E; Tue, 28 Sep 2010 15:07:50 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Tue, 28 Sep 2010 15:04:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100922222441.00002f27@unknown> <201009240923.04406.jhb@freebsd.org> <20100928183350.GB2224@garage.freebsd.pl> In-Reply-To: <20100928183350.GB2224@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009281504.12236.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 28 Sep 2010 15:07:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: bruce@cran.org.uk, src-committers@freebsd.org, Ken Smith , svn-src-all@freebsd.org, avg@freebsd.org, gavin@freebsd.org, svn-src-head@freebsd.org, "M. Warner Losh" Subject: Re: svn commit: r212964 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 19:07:52 -0000 On Tuesday, September 28, 2010 2:33:50 pm Pawel Jakub Dawidek wrote: > On Fri, Sep 24, 2010 at 09:23:04AM -0400, John Baldwin wrote: > > > Because disks are big and (again, just trying to explain my > > > understanding of what I inherited) we want all the support > > > to be in place, just not turned on. There is a difference > > > between "You can give us much better information by doing > > > > > .symbols goo> and then making a one-line change to rc.conf" > > > versus "You can give us much better information by making > > > a one-line change to rc.conf". > > > > The biggest argument against this (and the reason I always enable crashdumps > > on all machines I am involved with) is that many panics are not easily > > reproducible, esp. ones that trigger under load. If dumpdev is not on by > > default, then the info from a rare or hard-to-trigger bug may simply be lost. > > Also, "just send-pr or mail the 'foo' file" is even simpler than "enable this > > knob in rc.conf and reproduce your issue, then come back". > > I am bigger fan of textdumps than minidumps, because in my opinion > textdumps provide quite a lot of useful info. I'm working with FreeBSD > kernel for years now and almost entirely avoided gdb for kernel > debugging. DDB and printf(9) are in 99% enough for me (maybe I'm too > traditional, but that's the fact). I'm not saying that textdumps are > enough in 99%, though. Have you looked at a /var/crash/core.txt.X file yet? If not, you should, as it is very similar to a text dump. In fact, it will contain the contents of any ddb trace buffer in addition to a stack trace from kgdb, process listing from ps, etc. > > Well, if we turn it on we should document it clearly. Folks are already > > interested in asking for help once a machine panics, and if the reply to a > > query on questions@ can say "please go look for a file named 'foo' and e-mail > > it somewhere or send-pr it", that is far simpler than having to enable dumps > > and reproduce the panic. > > Another important thing in my opinion is privacy of user's data. Once > the data hit the disk it can stay there forever. This is why I use > encrypted swap everywhere. I'd never send kernel minidump from my > laptop or from any of my servers to anyone, but I'd be happy to send > textdump. > > I find textdumps a great solution that's in the middle between > protecting user's privacy and providing a lot of useful info and I'd > much prefer to turn on textdumps by default and eventually extend what > we dump, than to make minidumps the default. I'm suggesting they provide us the core.txt.X file, not the full minidump. A developer could then ask them to run specific commands from a subsequent kgdb session to obtain more details. > You can always ask user to add this one-line to rc.conf to turn > minidump on and provide you the info that was missing in textdump. This only works for easily reproducible bugs, and in that case they can turn on dumps later without a need for it to be automatic at all. -- John Baldwin