From owner-freebsd-stable@FreeBSD.ORG Tue Sep 20 14:13:31 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD8FB1065672 for ; Tue, 20 Sep 2011 14:13:31 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 91CC58FC1B for ; Tue, 20 Sep 2011 14:13:31 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R614k-0008Do-Oq; Tue, 20 Sep 2011 10:13:30 -0400 Date: Tue, 20 Sep 2011 10:13:30 -0400 From: Gary Palmer To: Oliver Fromme Message-ID: <20110920141330.GE10165@in-addr.com> References: <201109201341.p8KDfwoT086881@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109201341.p8KDfwoT086881@lurza.secnetix.de> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 7-stable: Root mount problem (mpt, probing / timing related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 14:13:31 -0000 On Tue, Sep 20, 2011 at 03:41:58PM +0200, Oliver Fromme wrote: > Hi, > > I've updated a server with mpt controller to the latest > 7-stable (ok, it's 7-stable from last week). During the > boot sequence, the disk connected to the mpt controller (da0) > seems to be probed too late, i.e. just _after_ the kernel > tries to mount the root file system. It's just a fraction > of a second too late. > > This is a screen shot of the situation: > > http://www.secnetix.de/olli/tmp2/screenshot-boot.jpg > > Of course, I can enter "ufs:da0s1a" at the rootmount prompt, > and the machine continues to boot fine. But this is a > server that should be able to boot unattended, so I need > this to be fixed. > > What's the "official" way to fix this? I think someone else > had a similar problem some time ago, but a quick search of > the lists doesn't yield anything. > > (BTW: Interestingly, the same machine boots fine without > hickup when booting 8-stable which is installed on another > Slice of the same disk. This could be just coincidence, > maybe the timing of probing is slightly different between > 7-stable and 8-stable.) Does increasing the kern.cam.scsi_delay loader tunable help at all? Gary