From owner-freebsd-current@FreeBSD.ORG Mon Aug 18 06:50:05 2003 Return-Path: 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 7FFE137B41D for ; Mon, 18 Aug 2003 06:50:05 -0700 (PDT) Received: from mta4.adelphia.net (mta4.mail.adelphia.net [64.8.50.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7EE84401E for ; Mon, 18 Aug 2003 05:46:36 -0700 (PDT) (envelope-from wmoran@potentialtech.com) Received: from potentialtech.com ([24.53.179.151]) by mta4.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030818124637.DRNW1347.mta4.adelphia.net@potentialtech.com>; Mon, 18 Aug 2003 08:46:37 -0400 Message-ID: <3F40CA70.3000101@potentialtech.com> Date: Mon, 18 Aug 2003 08:45:36 -0400 From: Bill Moran User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew D. Fuller" References: <20030817102318.69e094fc.aelfgar@aelfgar.com> <3F3FCFB2.3050900@potentialtech.com> <20030818031945.GB65803@over-yonder.net> In-Reply-To: <20030818031945.GB65803@over-yonder.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Mike Atamas cc: freebsd-current@freebsd.org Subject: Re: Slow Boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 18 Aug 2003 13:50:11 -0000 Matthew D. Fuller wrote: > On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of > Bill Moran, and lo! it spake thus: > >>My best guess is that the chipset responds slowly to probes, thus it >>takes a while to get the list of devices from it. However, I've never >>looked into it any more than that. > > I've always presumed it to be a question of timing out probes to the > drives; it only ever happens on IDE controllers with no devices attached > to 'em. I habitually just disable the controller channels that are empty > (or, in the case of my SCSI systems, just yank ATA support altogether). Could be. This machine is pretty bare-bones. Single ATA HDD and nothing on the secondary controller. I never really considered that, but it makes sense that probes on the secondary controller would take the full timeout value if there was nothing to respond. -- Bill Moran Potential Technologies http://www.potentialtech.com