From owner-svn-src-head@FreeBSD.ORG Fri Sep 24 13:28:52 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 2C144106566B; Fri, 24 Sep 2010 13:28: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 DC2758FC1C; Fri, 24 Sep 2010 13:28:51 +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 61DD946B64; Fri, 24 Sep 2010 09:28:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 570468A03C; Fri, 24 Sep 2010 09:28:50 -0400 (EDT) From: John Baldwin To: Ken Smith Date: Fri, 24 Sep 2010 09:23:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100922222441.00002f27@unknown> <20100923.203143.19192035494300157.imp@bsdimp.com> <1285297884.17619.17.camel@neo.cse.buffalo.edu> In-Reply-To: <1285297884.17619.17.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009240923.04406.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 24 Sep 2010 09:28: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, 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-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: Fri, 24 Sep 2010 13:28:52 -0000 On Thursday, September 23, 2010 11:11:24 pm Ken Smith wrote: > On Thu, 2010-09-23 at 20:31 -0600, M. Warner Losh wrote: > > In message: > > Gavin Atkinson writes: > > : On Thu, 23 Sep 2010, Ken Smith wrote: > > : > The issues talked about so far all contribute to the reason for that. > > : > But one of the more basic gut reactions to it all is that the users > > : > want to be interested in helping with the debugging (even if just > > : > providing the requested info) for any sort of crash information > > : > to be useful. And at the point we shift something from -current > > : > to -stable the percentage of people actively interested in participating > > : > in that sort of stuff flip. The bulk of people using -current > > : > know it's risky and they do it out of some interest in debugging > > : > stuff. The *bulk* of people using -stable are less interested or > > : > flat out not interested. And have no clue what crash dumps are, > > : > may be challenged to notice partition-getting-full issues, etc. > > : > > : I'm not sure I buy this argument, I'm afraid. Part of the advantage of > > : having all this done automatically on the as-shipped release media is that > > : end users don't have to be interested in debugging - crashinfo(8) does > > : most of the work for them. There's no easy way to actually determine > > : figures, but even if say only 10-15% of crashes can be diagnosed and > > : corrected just from the output of crashinfo(8) then that's a huge win for > > : the project as a whole. I'm guessing 10-15% is not unrealistic. > > : > > : I appreciate the issue about filling partitions is a valid one. Would a > > : possible compromise be that on release media, crashinfo(8) or similar will > > : default to only keeping the most recent coredump or similar? Given /var > > : now defaults to 4GB, Defaulting to keeping a single core is probably > > : acceptable. > > > > Furthermore, if we aren't interested in crash dumps by default, why do > > we install the huge .symbols files? > > > > Warner > > > > 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". > This is definitely one I don't have a strong enough opinion > on to fight over, I sympathize with both sides. If the > general consensus is mostly towards changing so be it. > I've got no way to tell what percentage of users would > have any clue what to do with the crash info versus users > who would be negatively impacted simply by the fact their > systems are generating stuff they're completely ignorant > of and will never touch. 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. -- John Baldwin