From owner-freebsd-scsi Mon Sep 23 14:39:31 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0CF737B404 for ; Mon, 23 Sep 2002 14:39:29 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49B2143E7B for ; Mon, 23 Sep 2002 14:39:29 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g8NLdR101621; Mon, 23 Sep 2002 14:39:27 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 23 Sep 2002 14:39:27 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Brooks Davis Cc: scsi@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_all.c In-Reply-To: <20020923141931.A20487@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > > But you did, in fact, change the default behaviour in that SCSI_DELAY=0 > > had been an accepted config option before. I've restored the ability to > > do this. And I am in no way shooting myself in the foot- that claim on > > your part is unnecessary and misplaced. In a system with 144 PCI slots, > > e.g,, should we ever install FreeBSD on an alpha 8400 and fill it full > > of either Fibre Channel cards, or with SCSI cards that are connected to > > anything more modern than 1992 and more pricey than a UMASS device, I'd > > like to have it finish booting this year. > > > > I don't think it's particularly important to be able use the tunable to > > set back down to zero as long as those of us who need to make the > > behaviour more acceptable for high end system can do so. > > When I looked at the code again, I realized there is one reason to want > to be able to set it to zero which is that the check is now applied to > boot time (in init_scsi_delay()) so is you set SCSI_DELAY=0 you get > SCSI_DELAY=SCSI_MIN_DELAY even if if you compile it in. Given you > example above, maybe we should just remove the checks entierly since in > the current configuration you would have 14.4sec of delay (not hugh, but > perhaps undesirably large). When you're doing a lot of rebooting, yes. If you're interested in keeping people from mistaking the units they need to specify a timeout in, then the check you started with is probably fine *except* for the case of zero. If you really *are* wanting to have a Bus Reset delay, then for SPI it really ought to be at least 250ms, which is the 'recommended' selection timeout. Personally, I believe that 'no delay' and 'no bus reset' should be the default. This will cover nearly all reasonable existing cases fine (modulo fixing HBAs which should, on init state, remember to negotiate down to narrow/async unless they believe the BIOS has actually done the right thing). The benefit of this is faster booting and a clean multi-initiator environment for free. And this is just for SPI. Other transport mechanisms may want to impose different defaults. For example, USB/SCSI might always want a powerup delay. But this is all predicated on switching eveyrone over to the NEW TRANSPORT code. Lacking that, the check is probably not too unreasonable as long as zero escapes any timeout. > > My comment about footshooting was refering to removing the attempt to > keep people from trying to set the value in seconds, not that you were > doing it to yourself. I'm fully aware you know more about scsi them > I'm, ever likely to. :) Life is long. Hopefully somebody around here *will* know more than me and I can go off and work on other things. It's not all that hard. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message