From owner-freebsd-current Sat Oct 3 22:05:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10116 for freebsd-current-outgoing; Sat, 3 Oct 1998 22:05:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10102 for ; Sat, 3 Oct 1998 22:05:14 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id XAA17116; Sat, 3 Oct 1998 23:04:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810040504.XAA17116@panzer.plutotech.com> Subject: Re: Long IDE probes? In-Reply-To: <199810040305.UAA21544@usr06.primenet.com> from Terry Lambert at "Oct 4, 98 03:05:58 am" To: tlambert@primenet.com (Terry Lambert) Date: Sat, 3 Oct 1998 23:04:34 -0600 (MDT) Cc: ken@plutotech.com, karl@denninger.net, tom@uniserve.com, dnelson@emsphone.com, bright@hotjobs.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote... > > That's not really the point of the delay. The point of the "bus settle" > > delay is to allow devices to recover from the bus reset that we send at > > boot. As Justin pointed out, modern devices take a relatively short period > > of time to do this (100ms or so), but older devices may take longer. > > Uh, so why are we sending a reset? Is it merely to allow us to wait? No, it's not merely to allow us to wait. It's so we can make sure all previously negotiated transfer settings are blown away. Here's a quote from the SCSI-2 specification: ====================================================================== 6.2.2.1 Hard reset alternative SCSI devices that implement the hard reset alternative, upon detection of the reset condition, shall: [ ... ] c) return any SCSI device operating modes to their appropriate initial conditions, similar to those conditions that would be found after a normal power-on reset. MODE SELECT conditions shall be restored to their last saved values if saved values have been established. MODE SELECT conditions for which no values have been saved shall be returned to their default values. [ ... ] ====================================================================== You can tell whether a device implements the hard or soft reset alternative by looking at a bit in the inquiry data. The soft reset stuff appears to be primarily for multiple-initiator setups. None of the devices in my system here support the soft reset alternative. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message