On Mon, 28 Aug 2000, Matthew Jacob wrote:

> > > In a properly designed system, no SCSI bus reset will be issued and there will
> > > be no need to wait N seconds settle time.
> > 
> > Ahem... how do you want to support devices that are old enough to not know
> > the reset command, or to do properly negotiate sync transfer rate?
> 
> You don't use a BDR! That's no different than yanking the SCSI bus in this
> case. In some senses, it's worse!

What do you do about reserve/release then?

> Perhaps the GENERIC kernel can do the bus reset in this case. Which is what we
> have, I guess. If I explicitly set SCSI_DELAY in my config file, we don't do
> settling (easy enough to do). But we also don't encourage HBAs to *not* issue
> bus resets with abandon. It's hard in such environments to believe that w/o a
> lot of work NetBSD can be in a multi-initiator environment.

Well, a 2 second reset delay is o.k. for disks, but some RAID boxes can
take upwards of 60 seconds to complete initialization after being reset.

The problem is not really the bus reset and the associated reset
delay.  The problem is that a reset and reset delay is issued to each and
every scsi bus that's being probed before the devices are probed, not when
the HBA driver is attached.

If issued resets when the HBAs were attached we would only require a
single reset delay.  (The next step would be multi-threaded probing....)

Eduardo Horvath