Subject: Re: dynamic configuration (was Re: PR#4094)
To: Ignatios Souvatzis <>
From: Matthew Jacob <>
List: tech-kern
Date: 08/28/2000 09:35:11
> > 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!

If they don't negotiate sync, then there's no problem, now is there? If they
can negotiate up to wide and sync mode (and some boot proms are moronic enough
to do so), they can negotiate back to async/narrow, no?

If you have configurations and platforms that somehow this is so hopelessly
broken (which usually means that nobody has time to fix the HBA driver in
question), then a SCSI bus reset is in order. If this is driven by the
lameness of the HBA, let the HBA issue the reset (*and* do the settle). If the
lameness is platform specific, let the platform call directly into the
scsi_ioctl midlayer to have a reset issued (prior to doing target probing-
which now is an asserted MI property of NetBSD) and do the waiting after that.

This said, it *is* a bit dicey in that you need to issue an INQUIRY to find
out if a device is WIDE_16 and SYNC and TAG capable, or even whether or 
not they are better than CCS compatibility. These would then be hints as
to whether or not a async/narrow negotiation would even work. There are a
whole close of very stupid CDROM drives just plain go beserk if you send them
wide negotiation messages.

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.

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.