From owner-svn-src-stable@FreeBSD.ORG Fri Sep 11 15:19:30 2009 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11CE61065670; Fri, 11 Sep 2009 15:19:30 +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 D10A48FC19; Fri, 11 Sep 2009 15:19:29 +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 7360946B2A; Fri, 11 Sep 2009 11:19:29 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8D4488A020; Fri, 11 Sep 2009 11:19:28 -0400 (EDT) From: John Baldwin To: "Jason J. Hellenthal" Date: Fri, 11 Sep 2009 11:11:51 -0400 User-Agent: KMail/1.9.7 References: <200909101404.n8AE41C6021588@svn.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909111111.52627.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Sep 2009 11:19:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Remko Lodder , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson , svn-src-stable-8@freebsd.org, Ken Smith , Ken Smith Subject: Re: svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:19:30 -0000 On Friday 11 September 2009 2:00:58 am Jason J. Hellenthal wrote: > On Thu, 10 Sep 2009 13:00 -0000, rwatson wrote: > > > > > On Thu, 10 Sep 2009, Remko Lodder wrote: > > > >> I agree with that; it would (!) help the bugbusting team in gathering > >> required information. If there is an way to automate crashdumps and proper > >> reporting and stick that in /var/crash/crash.$date or something and tell > >> people that they can report their problems on the bugs list where needed, > >> we have information upfront. I still remember the time where we had to > >> chase people to get this information, sometimes never being able to > >> properly get the information. If it is there by default, it will help. > >> > >> Please consider keeping it enabled.. > > > > Well, John's crashinfo(8) tool from Yahoo! does all this, the only "problem" > > is that it requires extracting the crashdump to a local file system. It > > seems like we have a lot of the right ingredients, maybe we can have a > > brain-storming session on distributed diagnostics and debugging at the > > Devsummit on how to find some better middle grounds here. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > > > > If I may, I would like to introduce a distributed targeting system to this > conversation in addition to crashinfo. Given with the above conversations I cant > help but think that in a case like this it would be helpful to setup a central > database for collection of information and write a little bit more code into > crashinfo for uuencoding a blob to send through email or maybe another way so > data can be collected, sorted & analyzed with statistics spilled out into a web > page for review. My previous job actually stored the output of a crashinfo-like script for each panic into a database along with metadata such as a one-line summary (it even had some limited ability to auto-tag known panics). However, it required a good chunk of time *every* day to check new panics received each day to see if any were not previously seen before, or new variants on an old panic, etc. The time was non-trivial and I do not think would scale well to the all-FreeBSD-users universe. -- John Baldwin