Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Sep 1998 21:52:26 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        ken@plutotech.com (Kenneth D. Merry)
Cc:        obrien@NUXI.com, freebsd-current@FreeBSD.ORG
Subject:   Re: LINT not up to date
Message-ID:  <199809182152.OAA29485@usr09.primenet.com>
In-Reply-To: <199809172040.OAA05178@panzer.plutotech.com> from "Kenneth D. Merry" at Sep 17, 98 02:40:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> It isn't "gratuitous" at all.  The bus settle delay affects more than just
> booting, it also affects how long we freeze the SIM queue after a bus reset
> and how long we freeze a device queue after a BDR.  Some folks may have
> devices that don't need really long bus settle delay, and may not want
> their machines hung for a second after a BDR or bus reset.
> 
> We could have changed the option name, which would be an interface change.
> Kernel building "interfaces", if you can call them that, change all the
> time.  We've already changed a number of them in the CAM switchover.

I would suggest using 8000 by default and letting people sysctl it
lower, to a lower limit of 100, per your limits argument.

Given a choice between a sysctl and a compile option, I pick a sysctl
every time.



> I don't think it'll turn out to be a big problem, really.  If folks can't
> figure out how many milliseconds are in a second, I question what they're
> doing using a computer in the first place, much less FreeBSD. :)
> 
> If enough people are really upset about this, we can make it something like
> CAM_BUS_SETTLE_DELAY instead.

I wonder if this affects bootable devices at all... in other words,
can it be lower for boot, and then an intentional reset be done after
setting it higher to catch slow devices if slow devices exist?

It seems to me that getting the boot delay as low as possible to cover
all cases, but no lower, would be the way to go...

PS: in case it wasn't clear, I'm suggesting the sysctl and the possible
reset be placed in the rc file...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



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