From owner-freebsd-current@FreeBSD.ORG Tue Nov 8 00:05:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07B1316A41F; Tue, 8 Nov 2005 00:05:38 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD56D43D45; Tue, 8 Nov 2005 00:05:37 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 6EEA82FD8; Mon, 7 Nov 2005 18:05:37 -0600 (CST) Date: Mon, 7 Nov 2005 18:05:37 -0600 To: Sean McNeil Message-ID: <20051108000537.GC16191@soaustin.net> References: <20051107182338.2D9CE16A420@hub.freebsd.org> <1131391243.1343.6.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131391243.1343.6.camel@server.mcneil.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 08 Nov 2005 04:18:21 +0000 Cc: Bill Paul , ume@freebsd.org, current@freebsd.org Subject: Re: recent MFC code to 6-STABLE kills ipv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2005 00:05:38 -0000 On Mon, Nov 07, 2005 at 11:20:43AM -0800, Sean McNeil wrote: > > The dc(4) driver supports a whole bunch of different chips. It really > > really really matters that you tell us exactly which one you have. > > How could this possibly matter? There were no changes to the dc0 driver > from Nov 1st to present. The essence of good bug reports is to report any fact that might _possibly_ be relevant. It helps to quickly eliminate possibilities. This isn't just true for FreeBSD; I have fought this battle for decades in this profession. Sometimes even as I'm composing a bug report I find myself walking through my list of unstated assumptions about what the problem "must" be. Half the time one of my assumptions is bogus. This is not a criticism of the OP, this is just how engineering works -- if we presuppose too much about the problem, rather than just reporting symptoms, we can wind up going around in circles. The PR database has many hundreds of such entries, unfortunately. mcl