Date: Fri, 18 Sep 1998 16:19:46 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: tlambert@primenet.com (Terry Lambert) Cc: ken@plutotech.com, obrien@NUXI.com, freebsd-current@FreeBSD.ORG Subject: Re: LINT not up to date Message-ID: <199809182219.QAA12794@panzer.plutotech.com> In-Reply-To: <199809182152.OAA29485@usr09.primenet.com> from Terry Lambert at "Sep 18, 98 09:52:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote... > > 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. The old code defaulted to 2 seconds (when SCSI_DELAY was not set), and that was the lowest value it allowed. CAM defaults to 2 seconds (when SCSI_DELAY is not set) and allows people to set it as low as 100ms. In both the old and new SCSI layers, the default bus settle delay in GENERIC is 15 seconds. > Given a choice between a sysctl and a compile option, I pick a sysctl > every time. It would be easy enough to make it a sysctl variable, although for most folks a compile-time option will work just fine. The bus settle delay is primarily used at boot, when we send a bus reset out to all the busses. Setting the sysctl variable would come too late to affect the boot process. The bus settle delay is also used when bus resets and BDRs happen during runtime. That's very rare, though, and I don't think most folks will want different values for runtime versus boot 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... I think it would be much cleaner to just catch everything the first time around, rather than trying to do another bus reset and reprobe. Doing another bus reset and probe from rc would add complexity in exchange for no gain that I can see. Another problem with doing it that way is what if the "slow device" is the person's boot disk? You'd never even get to rc if that's the case. The other thing to realize is that CAM probes all busses in parallel, so the bus settle delay is not (delay * number_of_busses) but rather (delay). Ken -- Kenneth Merry ken@plutotech.com 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?199809182219.QAA12794>