Date: Sat, 3 Oct 1998 23:04:34 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: tlambert@primenet.com (Terry Lambert) Cc: ken@plutotech.com, karl@denninger.net, tom@uniserve.com, dnelson@emsphone.com, bright@hotjobs.com, current@FreeBSD.ORG Subject: Re: Long IDE probes? Message-ID: <199810040504.XAA17116@panzer.plutotech.com> In-Reply-To: <199810040305.UAA21544@usr06.primenet.com> from Terry Lambert at "Oct 4, 98 03:05:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810040504.XAA17116>