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?

# 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.

# 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.

The work is into doing a breadth-first search at the SHBA level.

# -matt

				--*greywolf;
--
BSD: The power to Connect