>>> According to the sun hardware reference file, I have a "6U VME
>>> Sun-2 SCSI host adapter" in a 6U/9U frame for the 3/160. I assume,
>>> that's what is called the "sc" controller in NetBSD?
>> Should be.
> That only works with sunos, AFIK.

Right.  I wrote a start at a NetBSD driver for it, way back when, and a
couple of other people have made noises about turning it into something
usable (mine was never usable) and I've sent them what I had.  I
haven't heard of it actually working, though, yet.

The nomenclature is rather confusing.  There are Sun-2s and Sun-3s as
types of machines.  There are SCSI-2 and SCSI-3 as SCSI standards.  And
then just to keep things confusing, Sun picked confusing names for
their SCSI cards.  The sc they called a "SCSI-2" controller even though
I'm not sure it actually is (the card is dumb enough that it may be
SCSI-2 capable if the host software is smart enough - I don't know
enough to be sure) and the si they called a "SCSI-3" controller even
though it predates the SCSI-3 spec.  To muddy the waters even more, as
you found, they are also called the Sun-2 SCSI interface and the Sun-3
SCSI interface.  So we have a Sun-3 card, which is also called the
SCSI-3 card, which actually does SCSI-2, and we have the Sun-2 card,
which works in Sun-3 machines if the OS knows about it, which might do
SCSI-2 but also may not.  It's a mess.

SunOS calls them sc (the old one) and si (the new one) as well, so if
you can boot SunOS far enough to get boot messages you can tell which
one you have.  If you have the seven digit board number (the first
seven digits of the barcode tag, 501-xxxx), there are tables available
that you can look it up in, though offhand I forget where.

> Note that the sun2 controllers used scsi interposer boards to adapt
> esdi and mfm drives to the bus, and qic tape drives to the bus.

Those boards are not sc-specific; I've used them with si controllers,
and even on SPARC SCSI chains, to talk to disks.  (I don't recall
trying to use a tape drive behind one on NetBSD.)  To an extent, SCSI
is SCSI is SCSI. :-)

> The interposer boards had ids of 0 and 1, and the drives had ids of 0
> and 1 on each interposer board.

Yup.  And the SCSI adapter board responds on both LUNs (0 and 1) even
if it's got only one drive behind it. :-/

>>> Interestingly, I also can't seem to be able to set the first bit of
>>> the scsi ID on any drive connected to the bus, so I never get to
>>> have an sd3 (although the miniroot stuff etc. also seems to work
>>> automagically when the disk is sd4 or sd6 - doesn't matter when
>>> trying to boot, by the way).
> Drive numbering alternates by twos.

This is kernel-specific; many of the default kernels used to (and
apparently do to this day, from what you say) specifically hardwire the
first few sd unit numbers a la

sd0 at scsibus0 targ 0 lun 0
sd1 at scsibus0 targ 0 lun 1
sd2 at scsibus0 targ 1 lun 0
sd3 at scsibus0 targ 1 lun 1

so you cannot necessarily assume, for example, that just because you
see sd2 that the disk is at SCSI ID 2.  Look at the boot time message;
it'll say something like

sd2 at scsibus0 targ 1 lun 0: ....

which tells you what ID the drive is actually found at ("targ") for
that sd unit number.  (NetBSD fairly thoroughly decouples SCSI IDs from
drive unit numbers by default.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B