Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Sep 2011 19:08:25 +0200 (CEST)
From:      Oliver Fromme <olli@lurza.secnetix.de>
To:        gpalmer@freebsd.org (Gary Palmer)
Cc:        freebsd-stable@freebsd.org
Subject:   Re: 7-stable: Root mount problem (mpt, probing / timing related)
Message-ID:  <201109201708.p8KH8PKM094882@lurza.secnetix.de>
In-Reply-To: <20110920141330.GE10165@in-addr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Gary Palmer wrote:
 > 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?

It seems to help ...  I have now rebooted three times with
scsi_delay set to 10000, and it worked so far (the problem
did not always occur before, so I have to try several times).
A value of 5000 was not sufficient.

First I had tried kern.cam.boot_delay, which seems to be
specifically for this kind of situation (according to the
description), but it didn't help at all.  Even very large
values didn't help; I tried up to 30000.

I'm a little surprised that scsi_delay helps, but boot_delay
doesn't.  I would have expected it to be the other way round.

Anyway -- Thank you very much for the hint!

Best regards
   Oliver


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
        -- Doug Gwyn



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109201708.p8KH8PKM094882>