1e30867d53
All cross reference labels start with name of the file that contains them. A label for the top section level is simply the name of the file (omitting the .sgml). Other references within the file append a colon and onother name. For example, the label on the mailing list section in the file eresources.sgml is eresources:mail. This gives each file its own cross reference namespace.
689 lines
34 KiB
Plaintext
689 lines
34 KiB
Plaintext
<!-- $Id: scsi.sgml,v 1.1.1.1 1995/04/28 16:19:59 jfieber Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<!--
|
|
<title>An introduction to SCSI and its use with FreeBSD</title>
|
|
<author>(c) 1995, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
|
|
<date>V0.2, Thu Apr 20 22:45:23 MET DST 1995</date>
|
|
Copyright 1995, W. C. Bulte, Arnhem, The Netherlands
|
|
|
|
<abstract>
|
|
This document attempts to describe the background of SCSI, its
|
|
(mis)use with FreeBSD and some common pitfalls.
|
|
</abstract>
|
|
|
|
-->
|
|
<sect><heading>SCSI<label id="scsi"></heading>
|
|
|
|
<p><em>© 1995, &a.wilko;.</em>
|
|
|
|
SCSI is an acronym for Small Computer Systems Interface. It is an
|
|
ANSI standard that has become one of the leading I/O buses in the
|
|
computer industry. The foundation of the SCSI standard was laid by
|
|
Shugart Associates (the same guys that gave the world the first
|
|
mini floppy disks) when they introduced the SASI bus (Shugart Associates
|
|
Standard Interface).
|
|
|
|
After some time an industry effort was started to come to a more strict
|
|
standard allowing devices from different vendors to work together.
|
|
This effort was recognised in the ANSI SCSI-1 standard. The SCSI-1
|
|
standard (approx 1985) is now more or less obsolete. The current
|
|
standard is SCSI-2 (see <ref id="scsi:further-reading" name="Further
|
|
reading">), with SCSI-3 on the drawing boards.
|
|
|
|
In addition to a physical interconnection standard, SCSI defines a
|
|
logical (command set) standard to which disk devices must adhere.
|
|
This standard is called the Common Command Set (CCS) and was
|
|
developed more or less in parallel with ANSI SCSI-1. SCSI-2
|
|
includes the (revised) CCS as part of the standard itself. The
|
|
commands are dependent on the type of device at hand. It does not
|
|
make much sense of course to define a Write command for a
|
|
scanner...
|
|
|
|
The SCSI bus is a parallel bus, which comes in a number of
|
|
variants. The oldest and most used is an 8 bit wide bus, with
|
|
single-ended signals, carried on 50 wires. (If you don't know what
|
|
single-ended means, don't worry, that is what this document is all
|
|
about.) Modern designs also use 16 bit wides buses, with
|
|
differential signals. This allows transfer speeds of
|
|
20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2
|
|
allows a maximum buswidth of 32 bits, using an additional cable.
|
|
|
|
Of course the SCSI bus not only has data lines, but also a number
|
|
of control signals. A very elaborate protocol is part of the
|
|
standard to allow multiple devices to share the bus in an efficient
|
|
manner. In SCSI-2, the data is always checked using a seperate
|
|
parity line. In pre-SCSI-2 designs parity was optional.
|
|
|
|
In SCSI-3 even faster bustypes are introduced, along with a serial
|
|
SCSI bus that reduces the cabling overhead and allows a higher
|
|
maximum buslength.
|
|
|
|
As you could have guessed from the description above, SCSI devices
|
|
are intelligent. They have to be to adhere to the SCSI standard
|
|
(which is over 2 inches thick BTW). So, for a hard disk drive for
|
|
instance you do not specify a head/cylinder/sector to address a
|
|
particular block, but simply the number of the block you want.
|
|
Elaborate caching schemes, automatic badblock replacement etc
|
|
are all made possible by this 'intelligent device' approach.
|
|
|
|
On a SCSI bus, each possible pair of devices can communicate. If
|
|
their function allows this is another matter, but the standard does
|
|
not restrict it. To avoid signal contention, the 2 devices have to
|
|
arbitrate for the bus before using it.
|
|
|
|
The philosophy of SCSI is to have a standard that allows
|
|
older-standard devices to work with newer-standard ones. So, an
|
|
old SCSI-1 device should normally work on a SCSI-2 bus. Normally,
|
|
because it is not absolutely sure that the implementation of an old
|
|
device follows the (old) standard closely enough to be acceptable
|
|
on a new bus. Modern devices are usually more well-behaved,
|
|
because the standardisation has become more strict and is better
|
|
adhered to by the device manufacturers. Generally speaking, the
|
|
chances of getting a working set of devices on a single bus is
|
|
better when all the devices are SCSI-2 or newer. This does not
|
|
imply that you have to dump all your old stuff when you get that
|
|
shiny 2Gb disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2
|
|
QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks
|
|
work together quite happily.
|
|
|
|
<sect1>Concepts of SCSI
|
|
<p>
|
|
<sect2>A <it>smart</it> interface
|
|
<p>
|
|
As said before, SCSI devices are smart. The idea is to put the
|
|
knowledge about intimate hardware details onto the SCSI device
|
|
itself. In this way, the host system does not have to worry
|
|
about things like how many heads are hard disks has, or how many
|
|
tracks there are on a specific tape device. If you are curious,
|
|
the standard specifies commands with which you can query your
|
|
devices on their hardware particulars.
|
|
|
|
The advantage of intelligent devices is obvious: the device
|
|
drivers on the host can be made in a much more generic fashion,
|
|
there is no longer a need to change (and qualify!) drivers for
|
|
every odd new device that is introduced.
|
|
|
|
<sect2>Do's and don't's on interconnections
|
|
<p>
|
|
For cabling and connectors there is a golden rule: get good
|
|
stuff. With bus speeds going up all the time you will save
|
|
yourself a lot of grief by using good material.
|
|
|
|
So, gold plated connectors, shielded cabling, sturdy connector
|
|
hoods with strain reliefs etc are the way to go. Second golden
|
|
rule: don't use cables longer than necessary. I once spent 3 days
|
|
hunting down a problem with a flaky machine only to discover that
|
|
shortening the SCSI bus with 1 meter solved the problem. And the
|
|
original bus length was well within the SCSI specification.
|
|
<sect2>SCSI bus types
|
|
<p>
|
|
From an electrical point of view, there are two Incompatible bus
|
|
types: single-ended and differential. This means that there are
|
|
two different main groups of SCSI devices and controllers, which
|
|
cannot be mixed on the same bus. It is possible however to use
|
|
special converter hardware to transform a single-ended bus into a
|
|
differential one (and vice versa). The differences between the
|
|
bus types are explained in the next sections.
|
|
|
|
In lots of SCSI related documentation there is a sort of jargon
|
|
in use to abbreviate the different bus types. A small list:
|
|
|
|
<itemize>
|
|
<item>FWD: Fast Wide Differential
|
|
<item>FND: Fast Narrow Differential
|
|
<item>SE: Single Ended
|
|
<item>FN: Fast Narrow
|
|
<item>etc.
|
|
</itemize>
|
|
|
|
With a minor amount of imagination one can usually imagine what
|
|
is meant.
|
|
|
|
Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As
|
|
far as I know, the 32 bit variant is not (yet) in use, so wide
|
|
normally means 16 bit.
|
|
|
|
Fast means that the timing on the bus is somewhat different, so
|
|
that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead
|
|
of 5 Mbytes/sec for 'slow' SCSI. More on this later.
|
|
|
|
It should be noted that the datalines > 8 are only used for
|
|
datatransfers and device addressing. The transfers of commands
|
|
and status messages etc are only performed on the lowest 8
|
|
datalines. The standard allows narrow devices to operate on
|
|
a wide bus. The usable buswidth is negotiated
|
|
between the devices. You have to watch your device addressing
|
|
closely when mixing wide and narrow.
|
|
|
|
<sect3>Single ended buses
|
|
<p>
|
|
A single-ended SCSI bus uses signals that are either 5 Volts or
|
|
0 Volts (indeed, TTL levels) and are relative to a COMMON
|
|
ground reference. A singled ended 8 bit SCSI bus has
|
|
approximately 25 ground lines, who are all tied to a single
|
|
'rail' on all devices. A standard single ended bus has a
|
|
maximum length of 6 meters. If the same bus is used with
|
|
fast-SCSI devices, the maximum length allowed drops to 3
|
|
meters. Fast-SCSI means that instead of 5Mbytes/sec the bus
|
|
allows 10Mbytes/sec transfers.
|
|
|
|
Please note that this means that
|
|
if some devices on your bus use 'fast' to communicate your
|
|
bus must adhere to the length restrictions for fast buses!
|
|
|
|
It is obvious that with the newer fast-SCSI devices the
|
|
buslength can become a real bottleneck. This is why the
|
|
differential SCSI bus was introduced in the SCSI-2 standard.
|
|
|
|
For connector pinning and connector types please refer to the
|
|
SCSI-2 standard (see <ref id="scsi:further-reading" name="Further
|
|
reading">) itself, connectors etc are listed there in
|
|
painstaking detail.
|
|
|
|
Beware of devices using non-standard cabling. For instance
|
|
Apple uses a 25pin D-type connecter (like the one on serial
|
|
ports and parallel printers). Considering
|
|
that the official SCSI bus needs 50 pins you can imagine
|
|
the use of this connector needs some 'creative cabling'.
|
|
The reduction of the number of ground wires they used
|
|
is a bad idea, you better stick to 50 pins cabling
|
|
in accordance with the SCSI standard.
|
|
|
|
<sect3>Differential buses
|
|
<p>
|
|
A differential SCSI bus has a maximum length of 25
|
|
meters. Quite a difference from the 3 meters for a single-ended
|
|
fast-SCSI bus. The idea behind differential signals is that
|
|
each bus signal has it's own return wire. So, each signal is
|
|
carried on a (preferably twisted) pair of wires. The voltage
|
|
difference between these two wires determines whether the
|
|
signal is asserted or de-asserted. To a certain extent the
|
|
voltage difference between ground and the signal wire pair is
|
|
not relevant (don't try 10 kVolts though..).
|
|
|
|
It is beyond the scope of this document to explain why this
|
|
differential idea is so much better. Just accept that
|
|
electrically seen the use of differential signals gives a much
|
|
better noise margin. You will normally find differential buses
|
|
in use for inter-cabinet connections. Because of the lower cost
|
|
single ended is mostly used for shorter buses like inside
|
|
cabinets.
|
|
|
|
There is nothing that stops you from using differential stuff
|
|
with FreeBSD, as long as you use a controller that has device
|
|
driver support in FreeBSD. As an example, Adaptec marketed the
|
|
AH1740 as a single ended board, whereas the AH1744 was differential.
|
|
The software interface to the host is identical for both.
|
|
|
|
<sect3>Terminators
|
|
<p>
|
|
Terminators in SCSI terminology are resistor networks that are
|
|
used to get a correct impedance matching. Impedance matching
|
|
is important to get clean signals on the bus, without
|
|
reflections or ringing. If you once made a long distance
|
|
telephone call on a bad line you probably know what reflections
|
|
are. With 20Mbytes/sec travelling over your SCSI bus, you
|
|
don't want signals echoing back.
|
|
|
|
Terminators come in various incarnations, with more or less
|
|
sophisticated designs. Of course, there are internal and
|
|
external variants. Almost every SCSI device comes with a
|
|
number of sockets in which a number of resistor networks can
|
|
(must be!) installed. If you remove terminators from a device,
|
|
carefully stock 'm. You will need them when you ever decide to
|
|
reconfigure your SCSI bus. There is enough variation in even
|
|
these simple tiny things to make finding the exact replacement
|
|
a frustrating business. There are also SCSI devices that have
|
|
a single jumper to enable or disable a builtin terminator.
|
|
There are special terminators you can stick onto a flatcable
|
|
bus. Others look like external connectors, so a connector hood
|
|
without a cable. So, lots of choice as you can see.
|
|
|
|
There is much debate going on if and when you should switch
|
|
from simple resistor (passive) terminators to active
|
|
terminators. Active terminators contain more or less elaborate
|
|
circuits to give more clean bus signals. The general consensus
|
|
seems to be that the usefullnes of active termination increases
|
|
when you have long buses and/or fast devices. If you ever have
|
|
problems with your SCSI buses you might consider trying an
|
|
active terminator. Try to borrow one first, they reputedly are
|
|
quite expensive.
|
|
|
|
Please keep in mind that terminators for differential and
|
|
single-ended buses are not identical. You should <bf>not
|
|
mix</bf> the two variants.
|
|
|
|
OK, and now where should you install your terminators? This is
|
|
by far the most misunderstood part of SCSI. And it is by far
|
|
the simplest.. The rule is: <bf>every SCSI bus has 2 (two)
|
|
terminators, one at each end of the bus.</bf> So, two and not
|
|
one or three or whatever. Do yourself a favour and stick to
|
|
this rule. It will save you endless grief, because wrong
|
|
termination has the potential to introduce highly mysterious
|
|
bugs.
|
|
|
|
A common pitfall is to have an internal (flat)cable in a
|
|
machine and also an external cable attached to the
|
|
controller. It seems almost everybody forgets to remove the
|
|
terminators from the controller. The terminator must now be on
|
|
the last external device, and not on the controller! In
|
|
general, every reconfiguration of a SCSI bus must pay attention
|
|
to this.
|
|
|
|
What I did myself is remove all terminators from my SCSI
|
|
devices and controllers. I own a couple of external
|
|
terminators, for both the Centronics-type external cabling and
|
|
for the internal flat cable connectors. This makes
|
|
reconfiguration much easier.
|
|
|
|
<sect3>Terminator power
|
|
<p>
|
|
The terminators discussed in the previous chapter need power to
|
|
operate properly. On the SCSI bus, a line is dedicated to this
|
|
purpose. So, simple huh?
|
|
|
|
Not so. Each device can provide it's own terminator power to
|
|
the terminator sockets it has on-device. But if you have
|
|
external terminators, or when the device supplying the
|
|
terminator power to the SCSI bus line is switched off you are
|
|
in trouble.
|
|
|
|
The idea is that initiators (these are devices that initiate
|
|
actions on the bus, a discussion follows) must supply
|
|
terminator power. All SCSI devices are allowed (but not
|
|
required) to supply terminator power.
|
|
|
|
To allow for switched-off devices on a bus, the terminator
|
|
power must be supplied to the bus via a diode. This prevents
|
|
the backflow of current to switched-off devices.
|
|
|
|
To prevent all kinds of nastiness, the terminator power is
|
|
usually fused. As you can imagine, fuses might blow. This can,
|
|
but does not have to, lead to a non functional bus. If multiple
|
|
devices supply terminator power, a single blown fuse will not
|
|
put you out of business. A single supplier with a blown fuse
|
|
certainly will. Clever external terminators sometimes have a
|
|
LED indication that shows whether terminator power is present.
|
|
|
|
In newer designs auto-restoring fuses are used who 'reset'
|
|
themselves after some time.
|
|
|
|
On modern devices, sometimes integrated terminators are
|
|
used. These things are special purpose integrated circuits that
|
|
can be dis/en-abled with a control pin. It is not necessary to
|
|
physically remove them from a device. You may find them on
|
|
newer host adapters, sometimes they even are software
|
|
configurable, using some sort of setup tool. Consult you
|
|
documentation!
|
|
|
|
<sect3>Device addressing
|
|
<p>
|
|
Because the SCSI bus is, ehh, a bus there must be a way to
|
|
distinguish or address the different devices connected to it.
|
|
|
|
This is done by means of the SCSI or target ID. Each device has
|
|
a unique target ID. You can select the ID to which a device
|
|
must respond using a set of jumpers, or a dipswitch, or
|
|
something similar. Consult the documentation of your device for
|
|
more information.
|
|
|
|
Beware of multiple devices configured to use the same ID. Chaos
|
|
normally reigns in this case.
|
|
|
|
For an 8 bit bus, a maximum of 8 targets is possible. The
|
|
maximum is 8 because the selection is done bitwise using the 8
|
|
datalines on the bus. For wide this increases to the number of
|
|
datalines.
|
|
|
|
The higher the SCSI target ID, the higher the priority the
|
|
devices has. When it comes to arbitration between devices that
|
|
want to use the bus at the same time, the device that has the
|
|
highest SCSI ID will win. This also means that the SCSI
|
|
hostadapter usually uses target ID 7 (for narrow buses).
|
|
|
|
For a further subdivision, the standard allows for Logical
|
|
Units or LUNs for short. A single target ID may have multiple
|
|
LUNs. For example, a tape device including a tape changer may
|
|
have LUN 0 for the tape device itself, and LUN 1 for the
|
|
tapechanger. In this way, the host system can address each of
|
|
the parts of the tape unit as desired.
|
|
|
|
<sect3>Bus layout
|
|
<p>
|
|
SCSI buses are linear. So, not shaped like Y-junctions, star
|
|
topologies, cobwebbs or whatever else people might want to
|
|
invent.
|
|
|
|
You might notice that the terminator issue discussed earlier
|
|
becomes rather hairy if your bus is not linear..
|
|
|
|
The electrical characteristics, it's noise margins and
|
|
ultimately the reliability of it all are tightly related to
|
|
linear bus rule.
|
|
|
|
<bf>Stick to the linear bus rule!</bf>
|
|
|
|
<sect1>Using SCSI with FreeBSD
|
|
<p>
|
|
<sect2>About translations, BIOSes and magic..
|
|
<p>
|
|
As stated before, you should first make sure that you have a
|
|
electrically sound bus.
|
|
|
|
When you want to use a SCSI disk on your PC as boot disk, you
|
|
must aware of some quirks related to PC BIOSes. The PC BIOS in
|
|
it's first incarnation used a low level physical interface to the
|
|
harddisk. So, you had to tell the BIOS (using a setup tool or a
|
|
BIOS builtin setup) how your disk physically looked like. This
|
|
involved stating number of heads, number of cylinders, number of
|
|
sectors per track, obscure things like precompensation and
|
|
reduced write current cylinder etc.
|
|
|
|
One might be inclined to think that since SCSI disks are smart
|
|
you can forget about this. Alas, the arcane setup issue is still
|
|
present today. The system BIOS needs to know how to access your
|
|
SCSI disk with the head/cyl/sector method.
|
|
|
|
The SCSI host adapter or SCSI controller you have put in your
|
|
AT/EISA/PCI/whatever bus to connect your disk therefore has it's
|
|
own onboard BIOS. During system startup, the SCSI BIOS takes over
|
|
the harddisk interface routines from the system BIOS. To fool the
|
|
system BIOS, the system setup is normally set to No harddisk
|
|
present. Obvious, isn't it?
|
|
|
|
The SCSI BIOS itself presents to the system a so called
|
|
<bf>translated</bf> drive. This means that a fake drive table is
|
|
constructed that allows the PC to boot the drive. This
|
|
translation is often (but not always) done using a pseudo drive
|
|
with 32 heads and 64 sectors per track. By varying the number of
|
|
cylinders, the SCSI BIOS adapts to the actual drive size. It is
|
|
useful to note that 32 * 64 / 2 = the size of your drive in
|
|
megabytes. The division by 2 is to get from disk blocks that are
|
|
normally 512 bytes in size to Kbytes.
|
|
|
|
Right.. All is well now?! No, it isn't. The system BIOS has
|
|
another quirk you might run into. The number of cylinders of a
|
|
bootable harddisk cannot be greater than 1024. Using the
|
|
translation above, this is a showstopper for disks greater than
|
|
1 Gb. With disk capacities going up all the time this is causing
|
|
problems.
|
|
|
|
Fortunately, the solution is simple: just use another
|
|
translation, e.g. with 128 heads instead of 32. In most cases new
|
|
SCSI BIOS versions are available to upgrade older SCSI host
|
|
adapters. Some newer adapters have an option, in the form of a
|
|
jumper or software setup selection, to switch the translation the
|
|
SCSI BIOS uses.
|
|
|
|
It is very important that <bf>all</bf> operating systems on the disk use
|
|
the <bf>same translation</bf> to get the right idea about where to find
|
|
the relevant partitions. So, when installing FreeBSD you must
|
|
answer any questions about heads/cylinders etc using the
|
|
translated values your host adapter uses.
|
|
|
|
Failing to observe the translation issue might be un-bootable systems or
|
|
operating systems overwriting eachothers partitions. Using fdisk
|
|
you should be able to see all partitions.
|
|
|
|
As promised earlier: what is this talk about 'lying' devices? As
|
|
you might already know, the FreeBSD kernel reports the geometry
|
|
of SCSI disks when booting. An example from one of my systems:
|
|
|
|
<verb>
|
|
Feb 9 19:33:46 yedi /386bsd: aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
|
|
Feb 9 19:33:46 yedi /386bsd: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head,
|
|
53 sec, bytes/sec 512
|
|
</verb>
|
|
|
|
This info is retrieved from the SCSI disk itself. Newer disks
|
|
often use a technique called zone bit recording. The idea is that
|
|
on the outer cylinders of the drive there is more space so more
|
|
sectors per track can be put on them. This results in disks that
|
|
have more tracks on outer cylinders than on the inner cylinders
|
|
and, last but not least, have more capacity. You can imagine that
|
|
the value reported by the drive when inquiring about the geometry
|
|
now becomes fake.
|
|
|
|
<sect2>SCSI subsystem design
|
|
<p>
|
|
FreeBSD uses a sort of layered SCSI subsystem. For each different
|
|
controller card a so called device driver is written. This driver
|
|
knows all the intimate details about the hardware it
|
|
controls. The driver has a interface to the upper layers of the
|
|
SCSI subsystem through which it receives it's commands and
|
|
reports back any status.
|
|
|
|
On top of the card drivers there are a number of more generic
|
|
drivers for a class of devices. More specific: a driver for
|
|
tape devices (abbreviation: st), magnetic disks (sd), cdroms (cd)
|
|
etc. In case you are wondering where you can find this stuff, it
|
|
all lives in <tt>/sys/scsi</tt>. See the man pages in section 4
|
|
for more details.
|
|
|
|
The multi level design allows a decoupling of low-level bit
|
|
banging and more high level stuff. Adding support for another
|
|
piece of hardware is a much more managable problem.
|
|
|
|
<sect2>Kernel configuration
|
|
<p>
|
|
Dependent on your hardware, the kernel configuration file must
|
|
contain a line which describes your hostadapter. This includes
|
|
I/O addresses, interrupts etc. Consult the man page for your
|
|
adapter driver to get more info.
|
|
|
|
Although it is probably an obvious remark: the kernel config
|
|
file should reflect your actual hardware setup. So, interrupts,
|
|
I/O addresses etc must match the kernel config file.
|
|
|
|
An example from the kernel config file (they live in
|
|
<tt>/sys/i386/conf</tt> BTW), with some added comments (between
|
|
[]):
|
|
|
|
<verb>
|
|
controller ahb0 at isa? bio irq 11 vector ahbintr [driver for Adaptec 174x]
|
|
controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Adaptec 154x]
|
|
controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr [for Seagate
|
|
ST01/02]
|
|
controller scbus0
|
|
|
|
device sd0 [support for 4 SCSI harddisks, sd0 up sd3]
|
|
device sd1
|
|
device sd2
|
|
device sd3
|
|
|
|
device st0 [support for 2 SCSI tapes]
|
|
device st1
|
|
|
|
device cd0 #Only need one of these, the code dynamically grows [for the cdrom]
|
|
</verb>
|
|
|
|
So, the ahb driver is used for the Adaptec 1740, the aha driver
|
|
for the Adaptec 154x etc. If you have more than one card of the
|
|
same type in your system you get an ahb1, ahb2 line etc.
|
|
|
|
The example above supports 4 SCSI disks. If during boot more
|
|
devices of a specific type (e.g. sd disks) are found than are
|
|
configured in the booting kernel, the system will complain. You
|
|
will have to build and boot a new kernel (after adapting the kernel
|
|
configuration file) before you can use all of the devices. It
|
|
does not hurt to have 'extra' devices in the kernel, the example
|
|
above will work fine when you have only 2 SCSI disks.
|
|
|
|
Use <tt>man 4 scsi</tt> to check for the latest info on the SCSI
|
|
subsystem. For more detailed info on hostadapter drivers use eg
|
|
<tt>man 4 aha</tt> for info on the Adaptec 154x driver.
|
|
|
|
<sect2>Tuning your SCSI kernel setup
|
|
<p>
|
|
Experience has shown that some devices are slow to respond to INQUIRY
|
|
commands after a SCSI bus reset. An INQUIRY command is sent by the kernel
|
|
on boot to see what kind of device (disk, tape, cdrom etc) is connected
|
|
to a specific target ID. This process is called device probing by the way.
|
|
|
|
To work around this problem, FreeBSD allows a tunable delay time before
|
|
the SCSI devices are probed following a SCSI bus reset. You can set this
|
|
delaytime in your kernel configuration file using a line like:
|
|
|
|
<verb>
|
|
options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device
|
|
</verb>
|
|
This line sets the delay time to 15 seconds. On my own system I had to
|
|
use 3 seconds minimum to get my trusty old CDROM drive to be recognised.
|
|
Start with a high value (say 30 seconds or so) when you have problems
|
|
with device recognition. If this helps, tune it back until it just stays
|
|
working.
|
|
|
|
<sect2>Rogue SCSI devices
|
|
<p>
|
|
Although the SCSI standard tries to be complete and concise, it is
|
|
a complex standard and implementing things correctly is no easy task.
|
|
Some vendors do a better job then others.
|
|
|
|
This is exactly where the 'rogue' devices come into view. Rogues are
|
|
devices that are recognised by the FreeBSD kernel as behaving slightly
|
|
(...) non-standard. Rogue devices are reported by the kernel when
|
|
booting. An example for two of my cartridge tape units:
|
|
|
|
<verb>
|
|
Feb 25 21:03:34 yedi /386bsd: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:>
|
|
Feb 25 21:03:34 yedi /386bsd: st0: Tandberg tdc3600 is a known rogue
|
|
|
|
Mar 29 21:16:37 yedi /386bsd: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005>
|
|
Mar 29 21:16:37 yedi /386bsd: st1: Archive Viper 150 is a known rogue
|
|
</verb>
|
|
|
|
For instance, there are devices that respond to
|
|
all LUNs on a certain target ID, even if they are actually only one
|
|
device. It is easy to see that the kernel might be fooled into
|
|
believing that there are 8 LUNs at that particular target ID. The
|
|
confusion this causes is left as an exercise to the user.
|
|
|
|
The SCSI subsystem of FreeBSD recognises devices with bad habits by
|
|
looking at the INQUIRY response they send when probed. Because the
|
|
INQUIRY response also includes the version number of the device
|
|
firmware, it is even possible that for different firmware versions
|
|
different workarounds are used.
|
|
|
|
This scheme works fine, but keep in mind that it of course only
|
|
works for devices that are KNOWN to be weird. If you are the first
|
|
to connect your bogus Mumbletech SCSI cdrom you might be the one
|
|
that has to define which workaround is needed.
|
|
|
|
<sect2>Busmaster host adapters
|
|
<p>
|
|
Most, but not all, SCSI host adapters are bus mastering controllers.
|
|
This means that they can do I/O on their own without putting load onto
|
|
the host CPU for data movement.
|
|
|
|
This is of course an advantage for a multitasking operating system like
|
|
FreeBSD. It must be noted however that there might be some rough edges.
|
|
|
|
For instance an Adaptec 1542 controller can be set to use different
|
|
transferspeeds on the host bus (ISA or AT in this case). The controller
|
|
is settable to different rates because not all motherboards can handle
|
|
the higher speeds. Problems like hangups, bad data etc might be the
|
|
result of using a higher data transfer rate then your motherboard
|
|
can stomach.
|
|
|
|
The solution is of course obvious: switch to a lower data transfer rate
|
|
and try if that works better.
|
|
|
|
In the case of a Adaptec 1542, there is an option that can be put
|
|
into the kernel config file to allow dynamic determination of the
|
|
right, read: fastest feasible, transfer rate. This option is
|
|
disabled by default:
|
|
|
|
<verb>
|
|
options "TUNE_1542" #dynamic tune of bus DMA speed
|
|
</verb>
|
|
|
|
Check the man pages for the host adapter that you use. Or better
|
|
still, use the ultimate documentation (read: driver source).
|
|
|
|
<sect1>Tracking down problems
|
|
<p>
|
|
The following list is an attempt to give a guideline for the most
|
|
common SCSI problems and their solutions. It is by no means
|
|
complete.
|
|
|
|
<itemize>
|
|
<item>
|
|
Check for loose connectors and cables.
|
|
<item>
|
|
Check and doublecheck the location and number of your terminators.
|
|
<item>
|
|
Check if your bus has at least one supplier of terminator power
|
|
(especially with external terminators.
|
|
<item>
|
|
Check if no double target IDs are used.
|
|
<item>
|
|
Check if at least one device provides terminator power to the bus.
|
|
<item>
|
|
Check if all devices to be used are powered up.
|
|
<item>
|
|
Make a minimal bus config with as little devices as possible.
|
|
<item>
|
|
If possible, configure your hostadapter to use slow bus speeds.
|
|
</itemize>
|
|
|
|
<sect1><heading>Further reading<label id="scsi:further-reading"></>
|
|
<p>
|
|
If you intend to do some serious SCSI hacking, you might want to
|
|
have the official standard at hand:
|
|
|
|
Approved American National Standards can be purchased from ANSI at
|
|
11 West 42nd Street, 13th Floor, New York, NY 10036, Sales Dept:
|
|
(212) 642-4900. You can also buy many ANSI standards and most
|
|
committee draft documents from Global Engineering Documents, 15
|
|
Inverness Way East, Englewood, CO 80112-5704, Phone: (800)
|
|
854-7179, Outside USA and Canada: (303) 792-2181, FAX: (303) 792-
|
|
2192.
|
|
|
|
Many X3T10 draft documents are available electronically on the SCSI
|
|
BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site.
|
|
|
|
Latest X3T10 committee documents are:
|
|
<verb>
|
|
AT Attachment (ATA or IDE) [X3.221-1994] Approved
|
|
ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
|
|
Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] Approved
|
|
Small Computer System Interface - 2 (SCSI-2) [X3.131-1994] Approved
|
|
SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM)
|
|
[X3T10/792D Rev 11]
|
|
</verb>
|
|
Other publications that might provide you with additional information are:
|
|
<verb>
|
|
"SCSI: Understanding the Small Computer System Interface", written by NCR
|
|
Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632
|
|
Phone: (201) 767-5937 ISBN 0-13-796855-8
|
|
|
|
"Basics of SCSI", a SCSI tutorial written by Ancot Corporation
|
|
Contact Ancot for availability information at:
|
|
Phone: (415) 322-5322 Fax: (415) 322-0455
|
|
|
|
"SCSI Interconnection Guide Book", an AMP publication (dated 4/93, Catalog
|
|
65237) that lists the various SCSI connectors and suggests cabling schemes.
|
|
Available from AMP at (800) 522-6752 or (717) 564-0100
|
|
|
|
"Fast Track to SCSI", A Product Guide written by Fujitsu.
|
|
Available from: Prentice Hall, Englewood Cliffs, NJ, 07632
|
|
Phone: (201) 767-5937 ISBN 0-13-307000-X
|
|
|
|
"The SCSI Bench Reference", "The SCSI Encyclopedia", and the "SCSI Tutor",
|
|
ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070
|
|
Phone: (408) 867-6642
|
|
|
|
"Zadian SCSI Navigator" (quick ref. book) and "Discover the Power of SCSI"
|
|
(First book along with a one-hour video and tutorial book), Zadian Software,
|
|
Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800
|
|
</verb>
|
|
|
|
On Usenet the newsgroups comp.periphs.scsi and comp.periphs are
|
|
noteworthy places to look for more info. You can also find the
|
|
SCSI-Faq there, which posted periodically.
|
|
|
|
Most major SCSI device and hostadapter suppliers operate ftp sites
|
|
and/or BBS systems. They may be valuable sources of information
|
|
about the devices you own.
|