Date: Thu, 21 Oct 2010 07:09:40 -0700 From: Matthew Jacob <mj@feral.com> To: freebsd-scsi@freebsd.org Subject: Re: set kern.cam.scsi_delay to 2000ms on all platforms Message-ID: <4CC049A4.2090007@feral.com> In-Reply-To: <422A732A-355A-4C18-9E8F-8C7D2EE9D122@samsco.org> References: <20101019221131.GA75368@freebsd.org> <63EF6D51-1196-43F1-8521-27756E972263@samsco.org> <20101021062150.GA20489@freebsd.org> <8B967C79-CD84-435C-9007-E33467DC92A9@samsco.org> <20101021135447.GC72290@freebsd.org> <4CC046B8.8000505@feral.com> <422A732A-355A-4C18-9E8F-8C7D2EE9D122@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Absolutely, but let's not lose sight of the fact that timeouts after SCSI bus resets have never been an engineered solution, for any OS. Going back to 1986 the ANSI specifications have been vague or worse about delays after such an action. I can't speak for Alexander about this, but I suspect all of this is going to be "try it, and report failures". A conservative approach would be "let's not change this", but the reason for doing this is to shorten reboot time, which is enough of an important issue that it's worth the risk, IMO. > Sure, but what's the plan for validating it? Too often this stuff goes into HEAD with the best of intentions, and then it basically never touched again until someone stumbles over it in an release. I'm not against this change, I just want to know what engineering has gone into it. > > Scott >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC049A4.2090007>