I've just checked in several changes to the `sbc' SCSI driver that should
allow it to perform better with several and/or slow targets.  More
specifically, disconnect/reselect is now supported without having to
enable the not-quite-cooked `blind' mode transfers.  Note, however, that
there is an ambiguity in the SCSI specification regarding the behavior of
a target when it disconnects, so there is a chance of data corruption.  If
you are not familiar with and/or comfortable with dealing with broken file
systems, please read no further.

To enable this mode in the driver, simply add a `flags 0x5' to the sbc0
line in your kernel config file, like so:

	sbc0 at obio? flags 0x5

The actual performance of the driver will decrease slightly if you have a
single SCSI target, but if you do any measurements, the performance will
probably take an apparent jump for the better!  The reason for this
paradox, if you will permit me to call it that, is that the driver eats up
so much CPU doing PDMA without allowing the target to disconnect that it
misses clock ticks while it is waiting for the disk to fetch the requested
data.  This change allows clock ticks to be caught most of the time, to
the point where a `lost' tick due to SCSI access happens far less often
than those due to heavy Ethernet activity (I'm seeing my IIcx's clock
drift by <90 seconds per day).  It also allows slow devices, such as tape
drives, to relinquish the SCSI bus tell the CPU to go do something else
for a while.

Finally:  If your target is one of those that is affected by a looser
interpretation of the SCSI specification, it will require an SDEV_AUTOSAVE
quirk in the quirk table in sys/scsi/scsiconf.c.  I believe there is some
work going on to find a better overall solution to the problem, but a
local modification to your tree will certainly do the trick for now.  How
will you know if you're affected?  Usually, a corrupted file system
results very quickly; I trashed the superblock on some of my disks at
least a half dozen times while working on this driver and checking for the
need for the quirk on them.  (Good thing there's a backup copy!)

The driver should be no more and no less stable than previously.  It
should certainly be more `correct,' but there is at least one bug
remaining in the machine-independent part of the driver that causes
trouble when dumping a kernel core to disk after a panic.  I'm also aware
of trouble on at least one IIci, though I have personal experience with 2
such machines that are running well (and in fact, one of them _requires_
the sbc driver).

Please report any problems, or hopefully(!) success stories, to me.

--scott