diff options
Diffstat (limited to 'share/doc/handbook/scsi.sgml')
| -rw-r--r-- | share/doc/handbook/scsi.sgml | 688 |
1 files changed, 688 insertions, 0 deletions
diff --git a/share/doc/handbook/scsi.sgml b/share/doc/handbook/scsi.sgml new file mode 100644 index 0000000..7cad8b0 --- /dev/null +++ b/share/doc/handbook/scsi.sgml @@ -0,0 +1,688 @@ +<!-- $Id: m_scsi.sgml,v 1.1 1995/04/10 02:36:14 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</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="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="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="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. |
