> On Mon, 28 Aug 2000, Matthew Jacob wrote:
> 
> # You don't use a BDR! That's no different than yanking the SCSI bus in this
> # case. In some senses, it's worse!
> 
> ...doesn't most hardware do a BDR when it's reset anyway?
> 
> What's the purpose of the BDR?  To find out which targets are really there?
> To find out what they can handle?
> 
> Does a BDR force all targets to respond as though INQd?

A BUS DEVICE RESET is a message that you can send a device that causes it to
reset itself (as if it had received a SCSI bus reset). However, the
communication to the device has to work well enough for it to accept a BDR.

It's worse, in the case we've been talking about, than a SCSI bus reset in
that if you assume devices will accept a BDR, they sure as heck are likely to
accept ASYNC/NARROW negotiation.

> 
> # But the point in all of this then becomes: "Is NetBSD supposed to, *by
> # default*, support all hardware? Even stuff which probably only the developer
> # of the TiddlyWink-404z port has?". I'd assert that if you care about booting
> # speed, then SCSI bus reset delay overwhelms most everything else. If you want
> # to get rid of it, considering that 95% of the devices out there are newer
> # devices, there's a way to do this.
> 
> If you have to do SCSI bus resets, why not just attach all the busses
> first and then send each one a reset without waiting (in rapid-fire mode)?
> Then you only have to wait 2s from the final reset, which would mean you
> have a total of 2s + ((n - 1) * 1)ms to wait for all busses to be ready,
> and then all you're waiting on is the probe of each bus.

Agreed.

-matt