diff --git a/handbook/hw.sgml b/handbook/hw.sgml
index a2dc179405..e67e8bdf68 100644
--- a/handbook/hw.sgml
+++ b/handbook/hw.sgml
@@ -1,1510 +1,1531 @@
-<!-- $Id: hw.sgml,v 1.72 1997-11-23 18:54:50 obrien Exp $ -->
+<!-- $Id: hw.sgml,v 1.73 1997-11-23 19:13:42 obrien Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
<!DOCTYPE chapt PUBLIC "-//FreeBSD//DTD linuxdoc//EN"> -->
<chapt><heading>PC Hardware compatibility<label id="hw"></heading>
<p>Issues of hardware compatibility are among the most
troublesome in the computer industry today and FreeBSD is by
no means immune to trouble. In this respect, FreeBSD's
advantage of being able to run on inexpensive commodity PC
hardware is also its liability when it comes to support for
the amazing variety of components on the market. While it
would be impossible to provide a exhaustive listing of
hardware that FreeBSD supports, this section serves as a
catalog of the device drivers included with FreeBSD and the
hardware each drivers supports. Where possible and
appropriate, notes about specific products are included.
As FreeBSD is a volunteer project without a funded testing
department, we depend on you, the user, for much of the
information contained in this catalog. If you have direct
experience of hardware that does or does not work with
FreeBSD, please let us know by sending e-mail to the &a.doc;.
Questions about supported hardware
should be directed to the &a.questions (see
<ref id="eresources:mail" name="Mailing Lists"> for more
information). When submitting information or asking a
question, please remember to specify exactly what version of
FreeBSD you are using and include as many details of your
hardware as possible.
<sect><heading>Resources on the Internet</heading>
<p>The following links have proven useful in selecting hardware.
Though some of what you see won't necessarily be specific (or even
applicable) to FreeBSD, most of the hardware information out there
is OS independent. Please check with the FreeBSD hardware guide
to make sure that your chosen configuration is supported before
making any purchases.</p>
<p>
<itemize>
<item><htmlurl url="http://www.tomshardware.com/"
name="The Pentium Systems Hardware Performance Guide"></item>
</itemize>
<sect><heading>Sample Configurations<label id="hw:configs"></heading>
<p>The following list of sample hardware configurations by no means
constitutes an endorsement of a given hardware vendor or product by
<em>The FreeBSD Project</em>. This information is provided only as a public
service and merely catalogs some of the experiences that various individuals
have had with different hardware combinations. Your mileage may vary.
Slippery when wet. Beware of dog.
- <sect1><heading>Jordan's Picks</heading>
+ <sect1><heading>Jordan's Picks<label id="hw:jordans-picks"></heading>
<p>I have had fairly good luck building workstation and server
configurations with the following components. I can't guarantee that
you will too, nor that any of the companies here will remain "best buys"
forever. I will try, when I can, to keep this list up-to-date but
cannot obviously guarantee that it will be at any given time.
<sect2><heading>Motherboards<label id="hw:mb"></heading>
<p>The <htmlurl url="http://asustek.asus.com.tw/" name="ASUS">
<htmlurl url="http://asustek.asus.com.tw/FTP/ASUS/Info/Spec/pi-p55tp4.txt"
name="P55T2P4">
motherboard appears to be a good choice for mid-to-high range Pentium
server and workstation systems. You might also wish to investigate ASUS's
<htmlurl url="http://asustek.asus.com.tw/FTP/ASUS/Info/Spec/pvi-486sp3.txt"
name="486SP3G"> offering if it's a 486-class motherboard you're looking
for (Note: These have become increasingly hard to get as ASUS apparently
no longer manufactures them).
Those wishing to build more fault-tolerant systems should also be sure to
use Parity memory or, for truly 24/7 applications, ECC memory. Note
that ECC memory does involve a slight performance trade-off (which may
or may not be noticable depending on your application) but buys you
significantly increased fault-tolerance to memory errors.
<p>At the higher end, the Intel/Venus Pro (<ref id="hw:mb:pci"
name="VS440FX">) motherboard appears to work very well with FreeBSD,
as does its accompanying 200Mhz P6 (Pentium Pro) CPU. Recent price
drops have dropped P6 systems into a very affordable price bracket,
at least in the United States, and for serious server applications you
may wish to look no further than the Pentium Pro. My personal
`make world' times dropped from 3 hours and 40 minutes with a P5/166
to 1 hour and 22 minutes when I upgraded to a P6/200 machine - not
a fair comparison, to be sure, but just to note that in terms of
increased productivity, the P6/200 has definitely been worth the upgrade
for me.
NOTE: The Intel motherboards are designed to a different form-factor
and hence require <em>an entirely different PC case</em>, the so-called
"ATX" case design. Consider this fact carefully if you're thinking of
upgrading an existing system - all the commonly available ATX cases
I've seen so far have been in the "midi-tower" class, with limited space
for drives or other internal peripherals available. On the plus side,
most ATX cases appear to be of much higher quality than their typical PC
counterparts.
The only known interoperability problem with the
<ref id="hw:mb:pci" name="VS440FX"> chipset (also known as ``Natoma'')
is that the Matrox Meteor frame-grabber board will lock up your system
if used in one of these motherboards. Matrox blames Intel, Intel
blames Matrox, all we know is that it definitely doesn't work. That is
the only card I've had any troubles with in my P6 system and the card
works just fine in my older Triton chipset based motherboard.
<sect2><heading>Disk Controllers</heading>
<p>This one is a bit trickier, and while I used to recommend the
<htmlurl url="http://www.buslogic.com" name="Buslogic"> controllers
unilaterally for everything from ISA to PCI, now I tend to lean
towards the <htmlurl url="http://www.adaptec.com" name="Adaptec">
1542CF for ISA, Buslogic Bt747c for EISA and Adaptec 2940 for PCI.
The NCR/Symbios cards for PCI have also worked well for me, though
you need to make sure that your motherboard supports the BIOS-less
model if you're using one of those (if your card has nothing which
looks even vaguely like a ROM chip on it, you've probably got one
which expects its BIOS to be on your motherboard).
<p>If you should find that you need more than one SCSI controller in a
PCI machine, you may wish to consider conserving your scarce PCI
bus resources by buying the Adaptec 3940 card, which puts two SCSI
controllers (and internal busses) in a single slot.
<sect2><heading>Disk drives<label id="hw:disks"></heading>
<p>In this particular game of Russian roulette, I'll make few specific
recommendations except to say "SCSI over IDE whenever you can afford it."
Even in small desktop configurations, SCSI often makes more sense since it
allows you to easily migrate drives from server to desktop as falling drive
prices make it economical to do so. If you have more than one machine
to administer then think of it not simply as storage, think of it as a
food chain!
<p>I do not currently see SCSI WIDE drives as a necessary expense unless
you're putting together an NFS or NEWS server that will be doing a lot
of multiuser disk I/O.
- <sect2><heading>CDROM drives<label id="hw:cdrom"></heading>
+ <sect2><heading>CDROM drives<label id="hw:jordans-picks:cdrom"></heading>
<p>My SCSI preferences extend to SCSI CDROM drives as well, and while
the <htmlurl url="http://www.toshiba.com" name="Toshiba"> XM-3501B (also
released in a caddy-less model called the XM-5401B) drive has always
performed well for me, I'm now a great fan of the <htmlurl
url="http://www.plextor.com" name="Plextor"> PX-12CS drive. It's
a 12 speed drive with excellent performance and reliability.
<p>Generally speaking, most SCSI CDROM drives I've seen have been of
pretty solid construction and you probably won't go wrong with an HP or
NEC SCSI CDROM drive either. SCSI CDROM prices also appear to have
dropped considerably in the last few months and are now quite competitive
with IDE CDROMs while remaining a technically superior solution. I now see
no reason whatsoever to settle for an IDE CDROM drive if given a choice
between the two.
<sect2><heading>CD Recordable (WORM) drives<label id="hw:worm"></heading>
<p>At the time of this writing, FreeBSD supports 3 types of CDR drives
(though I believe they all ultimately come from Phillips anyway):
The Phillips CDD 522 (Acts like a Plasmon), the PLASMON RF4100 and
the HP 4020i. I myself use the HP 4020i for burning CDROMs (with
2.2-current - it does not work with 2.1.5 or earlier releases of the
SCSI code) and it works very well. See <htmlurl
url="file:/usr/share/examples/worm" name="/usr/share/examples/worm">
on your 2.2 system for example scripts used to created ISO9660
filesystem images (with RockRidge extensions) and burn them onto an
HP4020i CDR.
<sect2><heading>Tape drives<label id="hw:tape"></heading>
<p>I've had pretty good luck with both
<htmlurl url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html"
name="8mm drives"> from <htmlurl url="http://www.exabyte.com"
name="Exabyte"> and
<htmlurl url="http://www-dmo.external.hp.com:80/tape/_cpb0001.htm"
name="4mm (DAT)"> drives from <htmlurl url="http://www.hp.com" name="HP">.
<p>For backup purposes, I'd have to give the higher recommendation to the
Exabyte due to the more robust nature (and higher storage capacity) of
8mm tape.
<sect2><heading>Video Cards<label id="hw:video"></heading>
<p>If you can also afford to buy a commercial X server for US$99
from <htmlurl url="http://www.xig.com/"
name="Xi Graphics, Inc. (formerly X Inside, Inc)"> then I can heartily
recommend the <htmlurl url="http://www.matrox.com/" name="Matrox">
<htmlurl url="http://www.matrox.com/mgaweb/brochure.htm"
name="Millenium"> card. Note that support for this card is also
getting better with the <htmlurl url="http://www.xfree86.org"
name="XFree86"> server, which is available free of charge, though it's
still a fair bit slower than the XiG product at this time. I'm told that
support is also a fair bit better in the 3.2A release of XFree86, but
it's not yet available for general release.
You also certainly can't go wrong with one of
<htmlurl url="http://www.nine.com/" name="Number 9's"> cards -
their S3 Vision 868 and 968 based cards (the 9FX series) also being
quite fast and very well supported by XFree86's S3 server.
<sect2><heading>Monitors<label id="hw:monitors"></heading>
<p>I have had very good luck with the <htmlurl url="http://cons3.sel.sony.com/SEL/ccpg/display/ms17se2.html"
name="Sony Multiscan 17SE monitors">, as have I with
the Viewsonic offering in the same (trinitron) tube. For larger than
17", all I can recommend at the time of this writing is to not spend
any less than U.S. $2,500 for a 21" monitor if that's what you really
need. There are good monitors available in the >=20" range and there
are also cheap monitors in the >=20" range. Unfortunately, very few are
both cheap and good!
<sect2><heading>Networking<label id="hw:networking"></heading>
<p>I can recommend the <htmlurl url="http://www.smc.com/" name="SMC">
Ultra 16 controller for any ISA application and the SMC EtherPower
or Compex ENET32 cards for any serious PCI based networking. Both of
the PCI cards are based around DEC's DC21041 Ethernet controller
chip and other cards using it, such as the Zynx ZX342 or DEC DE435,
will generally work as well. For 100Mbit networking, either the
SMC SMC9332DST 10/100MB or Intel EtherExpress Pro/100B cards will do
a fine job.
If what you're looking for is, on the other hand, the cheapest possible
solution which will still work reasonably well, then almost any NE2000
clone is a good choice.
<sect2><heading>Serial<label id="hw:serial"></heading>
<p>If you're looking for high-speed serial networking solutions, then
<htmlurl url="http://www.dgii.com/" name="Digi International">
makes the <htmlurl url="http://www.dgii.com/prodprofiles/profiles-prices/digiprofiles/digispecs/sync570.html" name="SYNC/570"> series, with drivers now in
FreeBSD-current. <htmlurl url="http://www.etinc.com"
name="Emerging Technologies"> also manufactures a board with T1/E1
capabilities, using software they provide. I have no direct experience
using either product, however.
<p>Multiport card options are somewhat more numerous, though it has to be
said that FreeBSD's support for <htmlurl url="http://www.cyclades.com/"
name="Cyclades">'s products is probably the tightest, primarily as a result
of that company's commitment to making sure that we are adequately supplied
with evaluation boards and technical specs. I've heard that the Cyclom-16Ye
offers the best price/performance, though I've not checked the prices lately.
Other multiport cards I've heard good things about are the BOCA and AST
cards, and <htmlurl url="http://www.stallion.com/" name="Stallion
Technologies"> apparently offers an unofficial driver for their
cards at <htmlurl url="ftp://ftp.stallion.com/drivers/unsupported/freebsd/stalbsd-0.0.4.tar.gz" name="this"> location.
<sect2><heading>Audio<label id="hw:audio"></heading>
<p>I currently use the <htmlurl url="http://www.gravis.com/" name="Gravis">
Ultrasound MAX due to its high sound quality and full-duplex audio
capabilities (dual DMA channels). Support for Windows NT and OS/2 is
fairly anemic, however, so I'm not sure that I can recommend it as an
all-around card for a machine that will be running both FreeBSD and NT
or OS/2. In such a scenario, I might recommend the <htmlurl url="http://www.creaf.com/" name="Creative Labs"> AWE32 instead.
<sect2><heading>Video<label id="hw:vgrabbers"></heading>
<p>For video capture, there's really only once choice - the
<htmlurl url="http://www.matrox.com/" name="Matrox">
<htmlurl url="http://www.matrox.com/imgweb/meteor.htm" name="Meteor">
card. FreeBSD also supports the older video spigot card from
Creative Labs, but those are getting somewhat difficult to find
and the Meteor is a more current generation frame-grabber with
a higher-speed PCI interface. Note that this card <em>will not work</em>
with motherboards based on the VS440FX chipset! See the
<ref id="hw:mb" name="motherboard reference"> section for details.
<sect><heading>Core/Processing<label id="hw:core"></heading>
<sect1><heading>Motherboards, busses, and chipsets</heading>
<sect2><heading>* ISA</heading>
<sect2><heading>* EISA</heading>
<sect2><heading>* VLB</heading>
<sect2><heading>PCI<label id="hw:mb:pci"></heading>
<p><em>Contributed by &a.rgrimes;.<newline>25 April 1995.</em></p>
<p><em>Continuing updates by &a.jkh;.</em><newline>Last update on
<em>26 August 1996.</em></p>
<p>Of the Intel PCI chip sets, the following list describes
various types of known-brokenness and the degree of
breakage, listed from worst to best.
</p>
<p><descrip>
<tag>Mercury:</tag> Cache coherency problems,
especially if there are ISA bus masters behind
the ISA to PCI bridge chip. Hardware flaw, only
known work around is to turn the cache
off.
<tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or 2)</em>:</tag>
Write back cache coherency
problems. Hardware flaw, only known work around
is to set the external cache to write-through
mode. Upgrade to Saturn-II.
<tag>Saturn-II <em>(ie, 82424ZX at rev 3 or 4)</em>:</tag>
Works fine, but many MB
manufactures leave out the external dirty bit
SRAM needed for write back operation. Work
arounds are either run it in write through mode,
or get the dirty bit SRAM installed. (I have
these for the ASUS PCI/I-486SP3G rev 1.6 and
later boards).
<tag>Neptune:</tag> Can not run more than 2 bus
master devices. Admitted Intel design flaw.
Workarounds include do not run more than 2 bus
masters, special hardware design to replace the
PCI bus arbiter (appears on Intel Altair board
and several other Intel server group MB's). And
of course Intel's official answer, move to the
Triton chip set, we ``fixed it there''.
<tag>Triton:</tag> No known cache coherency or bus
master problems, chip set does not implement
parity checking. Workaround for parity issue.
Use Triton-II based motherboards if you have the choice.
<tag>Triton-II:</tag> All reports on motherboards using
this chipset have been favorable so far. No known
problems.
<tag>Orion:</tag> Early versions of this chipset suffered from
a PCI write-posting bug which can cause noticeable performance
degradation in applications where large amounts of PCI bus
traffic is involved. B0 stepping or later revisions of the
chipset fixed this problem.
<tag><htmlurl
url="http://www-cs.intel.com/oem_developer/motherbd/vs_index.htm"
name="VS440FX">:</tag>This <htmlurl
url="http://www.intel.com/procs/ppro/intro/index.htm"
name="Pentium Pro"> support chipset seems to work well,
and does not suffer from any of the early Orion chipset
problems. It also supports a wider variety of memory,
including ECC and parity. The only known problem with it
is that the Matrox Meteor frame grabber card doesn't like it.
</descrip>
</p>
<sect1><heading>CPUs/FPUs</heading>
<sect2><heading>* Pentium Pro class</heading>
<sect2><heading>Pentium class</heading>
<sect3><heading>Clock speeds</heading>
<p><em>Contributed by &a.rgrimes;.<newline>1 October 1996.</em></p>
<p>Pentium class machines use different clock speeds for the various
parts of the system. These being the speed of the CPU, external
memory bus, and the PCI bus. It is not always true that a "faster"
processor will make a system faster than a "slower" one, due to
the various clock speeds used.
Below is a table showing the differences:
<p>
<tscreen><verb>
Rated External Clock External to PCI Bus
CPU and Memory Bus Internal Clock Clock
MHZ MHZ** Multiplier MHZ
60 60 1.0 30
66 66 1.0 33
75 50 1.5 25
90 60 1.5 30
100 50* 2 25
100 66 1.5 33
120 60 2 30
133 66 2 33
150 60 2.5 30
166 66 2.5 33
180 60 3 30
200 66 3 33
* The Pentium 100 can be run at either 50MHz external clock with
a multiplier of 2 or at 66MHz and a multiplier of 1.5.
** 66 Mhz may actually be 66.667 MHz, but don't assume so.
</verb></tscreen>
<p>As can be seen the best parts to be using are the 100, 133, 166
and 200, with the exception that at a mulitplier of 3 the CPU
starves for memory.
<sect2><heading>* 486 class</heading>
<sect2><heading>* 386 class</heading>
<sect2><heading>286 class</heading>
<p>Sorry, FreeBSD does not run on 80286 machines. It is nearly
impossible to run today's large full-featured UNIXes on such
hardware.
<sect1><heading>* Memory</heading>
<p>The mininum amount of memory you must have to install FreeBSD is 5 MB.
Once your system is up and running you can <ref id="kernelconfig:building"
name="build a custom kernel"> that will use less memory.
If you use the boot4.flp you can get away with having only 4 MB.
<sect1><heading>* BIOS</heading>
<sect><heading>Input/Output Devices<label id="hw:io"></heading>
<sect1><heading>* Video cards</heading>
<sect1><heading>* Sound cards</heading>
<sect1><heading>Serial ports and multiport cards</heading>
&uart;
&sio;
&cy;
<sect1><heading>* Parallel ports</heading>
<sect1><heading>* Modems</heading>
<sect1><heading>* Network cards</heading>
<sect1><heading>* Keyboards</heading>
<sect1><heading>* Mice</heading>
<sect1><heading>* Other</heading>
<sect><heading>Storage Devices<label id="hw:storage"></heading>
&esdi;
&scsi;
<sect1><heading>* Disk/tape controllers
<label id="hw:storage:controllers"></heading>
<sect2><heading>* SCSI</heading>
<sect2><heading>* IDE</heading>
<sect2><heading>* Floppy</heading>
<sect1><heading>* Hard drives</heading>
<sect1><heading> Tape drives</heading>
<p><em>Contributed by &a.jmb;.<newline>2 July 1996.</em></p>
<sect2><heading> General tape access commands</heading>
<p><tt>mt(1)</tt> provides generic access to the tape
drives. Some of the more common commands are <tt>rewind</tt>,
<tt>erase</tt>, and <tt>status</tt>. See the <tt>mt(1)</tt>
manual page for a detailed description.
<sect2><heading> Controller Interfaces</heading>
<p>There are several different interfaces that support
tape drives. The interfaces are SCSI, IDE, Floppy and Parallel
Port. A wide variety of tape drives are available for these
interfaces. Controllers are discussed in
<ref id="hw:storage:controllers" name="Disk/tape controllers">
<sect2><heading> SCSI drives</heading>
<p>The <tt>st(4)</tt> driver provides support for 8mm
(Exabyte), 4mm (DAT: Digital Audio Tape), QIC (Quarter-Inch
Cartridge), DLT (Digital Linear Tape), QIC Minicartridge
and 9-track (remember the big reels that you see spinning
in Hollywood computer rooms) tape drives. See the
<tt>st(4)</tt> manual page for a detailed description.
<p>The drives listed below are currently being used by
members of the FreeBSD community. They are not the only drives
that will work with FreeBSD. They just happen to be the ones
that we use.
<sect3><heading> 4mm (DAT: Digital Audio Tape)</heading>
<p><ref id="hw:storage:python" name="Archive Python"
<p><ref id="hw:storage:hp1533a" name="HP C1533A">
<p><ref id="hw:storage:hp1534a" name="HP C1534A">
<p><ref id="hw:storage:hp35450a" name="HP 35450A">
<p><ref id="hw:storage:hp35470a" name="HP 35470A">
<p><ref id="hw:storage:hp35480a" name="HP 35480A">
<p><ref id="hw:storage:sdt5000" name="SDT-5000">
<p><ref id="hw:storage:wangtek6200" name="Wangtek 6200"
<sect3><heading> 8mm (Exabyte)</heading>
<p><ref id="hw:storage:exb8200" name="EXB-8200">
<p><ref id="hw:storage:exb8500" name="EXB-8500">
<p><ref id="hw:storage:exb8505" name="EXB-8505">
<sect3><heading> QIC (Quarter-Inch Cartridge)</heading>
<p><ref id="hw:storage:anaconda" name="Archive Ananconda 2750"
<p><ref id="hw:storage:viper60" name="Archive Viper 60"
<p><ref id="hw:storage:viper150" name="Archive Viper 150"
<p><ref id="hw:storage:viper2525" name="Archive Viper 2525"
<p><ref id="hw:storage:tandberg3600" name="Tandberg TDC 3600"
<p><ref id="hw:storage:tandberg3620" name="Tandberg TDC 3620"
<p><ref id="hw:storage:tandberg4222" name="Tandberg TDC 4222"
<p><ref id="hw:storage:wangtek5525es" name="Wangtek 5525ES"
<sect3><heading> DLT (Digital Linear Tape)</heading>
<p><ref id="hw:storage:dectz87" name="Digital TZ87"
<sect3><heading> Mini-Cartridge</heading>
<p><ref id="hw:storage:ctms3200" name="Conner CTMS 3200"
<p><ref id="hw:storage:exb2501" name="Exabyte 2501"
<sect3><heading> Autoloaders/Changers</heading>
<p><ref id="hw:storage:hp1553a" name="Hewlett-Packard HP
C1553A Autoloading DDS2">
<sect2><heading>* IDE drives</heading>
<sect2><heading> Floppy drives</heading>
<p><ref id="hw:storage:conner420r" name="Conner 420R"
<sect2><heading>* Parallel port drives</heading>
<sect2><heading> Detailed Information </heading>
<sect3><heading><label id="hw:storage:anaconda">
Archive Ananconda 2750</heading>
<p>The boot message identifier for this drive is "ARCHIVE
ANCDA 2750 28077 -003 type 1 removable SCSI 2"
<p>This is a QIC tape drive.
<p>Native capacity is 1.35GB when using QIC-1350 tapes.
This drive will read and write QIC-150 (DC6150), QIC-250
(DC6250), and QIC-525 (DC6525) tapes as well.
<p>Data transfer rate is 350kB/s using <tt>dump(8)</tt>.
Rates of 530kB/s have been reported when using <ref
id="hw:storage:amanda" name="Amanda">
<p>Production of this drive has been discontinued.
<p>The SCSI bus connector on this tape drive is reversed
from that on most other SCSI devices. Make sure that you have
enough SCSI cable to twist the cable one-half turn before and
after the Archive Anaconda tape drive, or turn your other SCSI
devices upside-down.
<p>Two kernel code changes are required to use this
drive. This drive will not work as delivered.
<p>If you have a SCSI-2 controller, short jumper 6.
Otherwise, the drive behaves are a SCSI-1 device. When operating
as a SCSI-1 device, this drive, "locks" the SCSI bus during some
tape operations, including: fsf, rewind, and rewoffl.
<p>If you are using the NCR SCSI controllers, patch the
file /usr/src/sys/pci/ncr.c (as shown below). Build and install
a new kernel.
<tscreen><verb>
*** 4831,4835 ****
};
! if (np->latetime>4) {
/*
** Although we tried to wake it up,
--- 4831,4836 ----
};
! if (np->latetime>1200) {
/*
** Although we tried to wake it up,
</verb></tscreen>
<p>Reported by: &a.jmb;
<sect3><heading><label id="hw:storage:python">
Archive Python</heading>
<p>The boot message identifier for this drive is "ARCHIVE
Python 28454-XXX4ASB" "type 1 removable SCSI 2" "density code
0x8c, 512-byte blocks"
<p>This is a DDS-1 tape drive.
<p>Native capacity is 2.5GB on 90m tapes.
<p>Data transfer rate is XXX.
<p>This drive was repackaged by Sun Microsystems as model 411.
<p>Reported by: Bob Bishop rb@gid.co.uk
<sect3><heading><label id="hw:storage:viper60">
Archive Viper 60</heading>
<p>The boot message identifier for this drive is "ARCHIVE
VIPER 60 21116 -007" "type 1 removable SCSI 1"
<p>This is a QIC tape drive.
<p>Native capacity is 60MB.
<p>Data transfer rate is XXX.
<p>Production of this drive has been discontinued.
<p>Reported by: Philippe Regnauld regnauld@hsc.fr
<sect3><heading><label id="hw:storage:viper150">
Archive Viper 150</heading>
<p>The boot message identifier for this drive is "ARCHIVE
VIPER 150 21531 -004" "Archive Viper 150 is a known rogue" "type
1 removable SCSI 1". A multitude of firmware revisions exist
for this drive. Your drive may report different numbers (e.g
"21247 -005".
<p>This is a QIC tape drive.
<p>Native capacity is 150/250MB. Both 150MB (DC6150)
and 250MB (DC6250) tapes have the recording format. The 250MB
tapes are approximately 67% longer than the 150MB tapes. This
drive can read 120MB tapes as well. It can not write 120MB tapes.
<p>Data transfer rate is 100kB/s
<p>This drive reads and writes DC6150 (150MB) and DC6250
(250MB) tapes.
<p>This drives quirks are known and pre-compiled into the
scsi tape device driver (<tt>st(4)</tt>).
<p>Under FreeBSD 2.2-current, use <tt>mt blocksize
512</tt> to set the blocksize. (The particular drive had
firmware revision 21247 -005. Other firmware revisions may
behave differently) Previous versions of FreeBSD did not have
this problem.
<p>Production of this drive has been discontinued.
<p>Reported by: Pedro A M Vazquez vazquez@IQM.Unicamp.BR
<p> Mike Smith msmith@atrad.adelaide.edu.au
<sect3><heading><label id="hw:storage:viper2525">
Archive Viper 2525</heading>
<p>The boot message identifier for this drive is "ARCHIVE
VIPER 2525 25462 -011" "type 1 removable SCSI 1"
<p>This is a QIC tape drive.
<p>Native capacity is 525MB.
<p>Data transfer rate is 180kB/s at 90 inches/sec.
<p>The drive reads QIC-525, QIC-150, QIC-120 and QIC-24 tapes.
Writes QIC-525, QIC-150, and QIC-120.
<p>Firmware revisions prior to "25462 -011" are bug
ridden and will not function properly.
<p>Production of this drive has been discontinued.
<!-- <p>Reported by: &a.hm; -->
<sect3><heading><label id="hw:storage:conner420r">
Conner 420R</heading>
<p>The boot message identifier for this drive is "Conner tape".
<p>This is a floppy controller, minicartridge tape drive.
<p>Native capacity is XXXX
<p>Data transfer rate is XXX
<p>The drive uses QIC-80 tape cartridges.
<p>Reported by: Mark Hannon mark@seeware.DIALix.oz.au
<sect3><heading><label id="hw:storage:ctms3200">
Conner CTMS 3200</heading>
<p>The boot message identifier for this drive is "CONNER
CTMS 3200 7.00" "type 1 removable SCSI 2".
<p>This is a minicartridge tape drive.
<p>Native capacity is XXXX
<p>Data transfer rate is XXX
<p>The drive uses QIC-3080 tape cartridges.
<p>Reported by: Thomas S. Traylor tst@titan.cs.mci.com
<sect3><heading><label id="hw:storage:dectz87">
<htmlurl
url="http://www.digital.com/info/Customer-Update/931206004.txt.html"
name="DEC TZ87"></heading>
<p>The boot message identifier for this drive is "DEC
TZ87 (C) DEC 9206" "type 1 removable SCSI 2" "density code 0x19"
<p>This is a DLT tape drive.
<p>Native capacity is 10GB.
<p>This drive supports hardware data compression.
<p>Data transfer rate is 1.2MB/s.
<p>This drive is identical to the Quantum DLT2000. The
drive firmware can be set to emulate several well-known drives,
including an Exabyte 8mm drive.
<p>Reported by: &a.wilko;
<sect3><heading><label id="hw:storage:exb2501">
<htmlurl
url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html"
name="Exabyte EXB-2501"></heading>
<p>The boot message identifier for this drive is "EXABYTE
EXB-2501"
<p>This is a mini-cartridge tape drive.
<p>Native capacity is 1GB when using MC3000XL minicartridges.
<p>Data transfer rate is XXX
<p>This drive can read and write DC2300 (550MB), DC2750
(750MB), MC3000 (750MB), and MC3000XL (1GB) minicartridges.
<p>WARNING: This drive does not meet the SCSI-2
specifications. The drive locks up completely in response to a
SCSI MODE_SELECT command unless there is a formatted tape in the
drive. Before using this drive, set the tape blocksize with
<verb>mt -f /dev/st0ctl.0 blocksize 1024</verb>
Before using a minicartridge for the first time, the minicartridge
must be formated. FreeBSD 2.1.0-RELEASE and earlier:
<verb>/sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0"</verb>
(Alternatively, fetch a copy of the <tt>scsiformat</tt> shell script
from FreeBSD 2.1.5/2.2.) FreeBSD 2.1.5 and later:
<verb>/sbin/scsiformat -q -w /dev/rst0.ctl</verb>
<p>Right now, this drive cannot really be recommended for FreeBSD.
<p>Reported by: Bob Beaulieu ez@eztravel.com
<sect3><heading><label id="hw:storage:exb8200"> Exabyte
EXB-8200</heading>
<p>The boot message identifier for this drive is "EXABYTE
EXB-8200 252X" "type 1 removable SCSI 1"
<p>This is an 8mm tape drive.
<p>Native capacity is 2.3GB.
<p>Data transfer rate is 270kB/s.
<p>This drive is fairly slow in responding to the SCSI
bus during boot. A custom kernel may be required (set SCSI_DELAY
to 10 seconds).
<p>There are a large number of firmware configurations
for this drive, some have been customized to a particular
vendor's hardware. The firmware can be changed via EPROM
replacement.
<p>Production of this drive has been discontinued.
<p>Reported by: Mike Smith msmith@atrad.adelaide.edu.au
<sect3><heading><label id="hw:storage:exb8500">
Exabyte EXB-8500</heading>
<p>The boot message identifier for this drive is "EXABYTE
EXB-8500-85Qanx0 0415" "type 1 removable SCSI 2"
<p>This is an 8mm tape drive.
<p>Native capacity is 5GB.
<p>Data transfer rate is 300kB/s.
<p>Reported by: Greg Lehey grog@lemis.de
<sect3><heading><label id="hw:storage:exb8505">
<htmlurl
url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html"
name="Exabyte EXB-8505"></Heading>
<p>The boot message identifier for this drive is "EXABYTE
EXB-85058SQANXR1 05B0" "type 1 removable SCSI 2"
<p>This is an 8mm tape drive which supports compression, and is
upward compatible with the EXB-5200 and EXB-8500.
<p>Native capacity is 5GB.
<p>The drive supports hardware data compression.
<p>Data transfer rate is 300kB/s.
<p>Reported by: Glen Foster gfoster@gfoster.com
<sect3><heading><label id="hw:storage:hp1533a">
Hewlett-Packard HP C1533A</heading>
<p>The boot message identifier for this drive is "HP
C1533A 9503" "type 1 removable SCSI 2".
<p>This is a DDS-2 tape drive. DDS-2 means hardware data
compression and narrower tracks for increased data capacity.
<p>Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
<p>Data transfer rate is 510kB/s.
<p>This drive is used in Hewlett-Packard's SureStore
6000eU and 6000i tape drives and C1533A DDS-2 DAT drive.
<p>The drive has a block of 8 dip switches. The proper
settings for FreeBSD are: 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7
ON; 8 ON.
<tscreen><verb>
switch 1 2 Result
ON ON Compression enabled at power-on, with host control
ON OFF Compression enabled at power-on, no host
control
OFF ON Compression disabled at power-on; the
host is allowed to control compression
OFF OFF Compression disabled at power-on, no host
control
</verb></tscreen>
<p>Switch 3 controls MRS (Media Recognition System). MRS
tapes have stripes on the transparent leader. These identify the
tape as DDS (Digital Data Storage) grade media. Tapes
that do not have the stripes will be treated as write-protected.
Switch 3 OFF enables MRS. Switch 3 ON disables MRS.
<p>See <htmlurl url="http://www.hp.com/tape/c_intro.html"
name="HP SureStore Tape Products"> and
<htmlurl url="http://www.impediment.com/hp/hp_technical.html"
name="Hewlett-Packard Disk and Tape Technical Information">
for more information on configuring this drive.
<p><em>Warning:</em> Quality control on these drives
varies greatly. One FreeBSD core-team member has returned 2 of
these drives. Neither lasted more than 5 months.
<p>Reported by: &a.se;
<sect3><heading><label id="hw:storage:hp1534a">
Hewlett-Packard HP 1534A</heading>
<p>The boot message identifier for this drive is "HP
HP35470A T503" type 1 removable SCSI 2" "Sequential-Access
density code 0x13, variable blocks".
<p>This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
<p>Native capacity is 2GB when using 90m tapes.
<p>Data transfer rate is 183kB/s.
<p>The same mechanism is used in Hewlett-Packard's
SureStore <htmlurl url="http://www.dmo.hp.com/tape/sst2000.htm"
name="2000i"> tape drive, C35470A DDS format DAT drive, C1534A DDS
format DAT drive and HP C1536A DDS format DAT drive.
<p>The HP C1534A DDS format DAT drive has two indicator
lights, one green and one amber. The green one indicates tape
action: slow flash during load, steady when loaded, fast flash
during read/write operations. The amber one indicates warnings:
slow flash when cleaning is required or tape is nearing the end
of its useful life, steady indicates an hard fault. (factory
service required?)
<p>Reported by Gary Crutcher gcrutchr@nightflight.com
<sect3><heading><label id="hw:storage:hp1553a">
Hewlett-Packard HP C1553A Autoloading DDS2</heading>
<p>The boot message identifier for this drive is "".
<p>This is a DDS-2 tape drive. DDS-2 means hardware data
compression and narrower tracks for increased data capacity.
<p>Native capacity is 24GB when using 120m tapes. This
drive supports hardware data compression.
<p>Data transfer rate is 510kB/s (native).
<p>This drive is used in Hewlett-Packard's SureStore
<htmlurl url="http://www.dmo.hp.com/tape/sst12000.htm"
name="12000e"> tape drive.
<p>The drive has two selectors on the rear panel. The
selector closer to the fan is SCSI id. The other selector should
be set to 7.
<p>There are four internal switches. These should be
set: 1 ON; 2 ON; 3 ON; 4 OFF.
<p>At present the kernel drivers do not automatically
change tapes at the end of a volume. This shell script can be
used to change tapes:
<tscreen><verb>
#!/bin/sh
PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH
usage()
{
echo "Usage: dds_changer [123456ne] raw-device-name
echo "1..6 = Select cartridge"
echo "next cartridge"
echo "eject magazine"
exit 2
}
if [ $# -ne 2 ] ; then
usage
fi
cdb3=0
cdb4=0
cdb5=0
case $1 in
[123456])
cdb3=$1
cdb4=1
;;
n)
;;
e)
cdb5=0x80
;;
?)
usage
;;
esac
scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5"
</verb></tscreen>
<sect3><heading><label id="hw:storage:hp35450a">
Hewlett-Packard HP 35450A</heading>
<p>The boot message identifier for this drive is "HP
HP35450A -A C620" "type 1 removable SCSI 2" "Sequential-Access
density code 0x13"
<p>This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
<p>Native capacity is 1.2GB.
<p>Data transfer rate is 160kB/s.
<p>Reported by: mark thompson mark.a.thompson@pobox.com
<sect3><heading><label id="hw:storage:hp35470a">
Hewlett-Packard HP 35470A</heading>
<p>The boot message identifier for this drive is "HP
HP35470A 9 09" type 1 removable SCSI 2"
<p>This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
<p>Native capacity is 2GB when using 90m tapes.
<p>Data transfer rate is 183kB/s.
<p>The same mechanism is used in Hewlett-Packard's
SureStore <htmlurl url="http://www.dmo.hp.com/tape/sst2000.htm"
name="2000i"> tape drive, C35470A DDS format DAT drive, C1534A
DDS format DAT drive, and HP C1536A DDS format DAT drive.
<p><em>Warning:</em> Quality control on these drives
varies greatly. One FreeBSD core-team member has returned 5 of
these drives. None lasted more than 9 months.
<p>Reported by: David Dawes dawes@rf900.physics.usyd.edu.au (9 09)
<Sect3><heading><label id="hw:storage:hp35480a">
Hewlett-Packard HP 35480A</heading>
<p>The boot message identifier for this drive is "HP
HP35480A 1009" "type 1 removable SCSI 2" "Sequential-Access
density code 0x13".
<p>This is a DDS-DC tape drive. DDS-DC is DDS-1 with
hardware data compression. DDS-1 is the original DAT tape
format.
<p>Native capacity is 2GB when using 90m tapes. It cannot handle
120m tapes. This drive supports hardware data compression. Please refer
to the section on <ref id="hw:storage:hp1533a" name="HP C1533A"> for the
proper switch settings.
<p>Data transfer rate is 183kB/s.
<p>This drive is used in Hewlett-Packard's SureStore
<htmlurl url="http://www.dmo.hp.com/tape/sst5000.htm" name=
"5000eU"> and <htmlurl
url="http://www.dmo.hp.com/tape/sst5000.htm" name="5000i"> tape
drives and C35480A DDS format DAT drive..
<p>This drive will occasionally hang during a tape eject
operation (<tt>mt offline</tt>). Pressing the front panel button
will eject the tape and bring the tape drive back to life.
<p>WARNING: HP 35480-03110 only. On at least two
occasions this tape drive when used with FreeBSD 2.1.0, an IBM
Server 320 and an 2940W SCSI controller resulted in all SCSI disk
partitions being lost. The problem has not be analyzed or
resolved at this time.
<sect3><heading><label id="hw:storage:sdt5000">
<htmlurl
url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html"
name="Sony SDT-5000"</heading>
<p>There are at least two significantly different models: one is
a DDS-1 and the other DDS-2. The DDS-1 version is "SDT-5000 3.02". The
DDS-2 version is "SONY SDT-5000 327M". The DDS-2 version has a
1MB cache. This cache is able to keep the tape streaming in almost any
circumstances.
<p>The boot message identifier for this drive is "SONY
SDT-5000 3.02" "type 1 removable SCSI 2" "Sequential-Access
density code 0x13"
<p>Native capacity is 4GB when using 120m tapes. This
drive supports hardware data compression.
<p>Data transfer rate is depends upon the model or
the drive. The rate is 630kB/s for the "SONY SDT-5000 327M"
while compressing the data. For the "SONY SDT-5000 3.02", the
data transfer rate is 225kB/s.
<p>In order to get this drive to stream, set the
blocksize to 512 bytes (<tt>mt blocksize 512</tt>) reported by
Kenneth Merry ken@ulc199.residence.gatech.edu"
<p>"SONY SDT-5000 327M" information reported by Charles Henrich
henrich@msu.edu
<p>Reported by: &a.jmz;
<sect3><heading><label id="hw:storage:tandberg3600">
Tandberg TDC 3600</heading>
<p>The boot message identifier for this drive is
"TANDBERG TDC 3600 =08:" "type 1 removable SCSI 2"
<p>This is a QIC tape drive.
<p>Native capacity is 150/250MB.
<p>This drive has quirks which are known and work around
code is present in the scsi tape device driver (<tt>st(4)</tt>).
Upgrading the firmware to XXX version will fix the quirks and
provide SCSI 2 capabilities.
<p>Data transfer rate is 80kB/s.
<p>IBM and Emerald units will not work. Replacing the
firmware EPROM of these units will solve the problem.
<p>Reported by: Michael Smith msmith@atrad.adelaide.edu.au
<sect3><heading><label id="hw:storage:tandberg3620">
Tandberg TDC 3620</heading>
<p>This is very similar to the <ref
id="hw:storage:tandberg3600" name="Tandberg TDC 3600"> drive.
<p>Reported by: &a.joerg;
<sect3><heading><label id="hw:storage:tandberg4222">
Tandberg TDC 4222</heading>
<p>The boot message identifier for this drive is
"TANDBERG TDC 4222 =07" "type 1 removable SCSI 2"
<p>This is a QIC tape drive.
<p>Native capacity is 2.5GB. The drive will read all
cartridges from the 60 MB (DC600A) upwards, and write 150 MB
(DC6150) upwards. Hardware compression is optionally supported
for the 2.5 GB cartridges.
<p>This drives quirks are known and pre-compiled into the
scsi tape device driver (<tt>st(4)</tt>) beginning with FreeBSD
2.2-current. For previous versions of FreeBSD, use <tt>mt</tt>
to read one block from the tape, rewind the tape, and then
execute the backup program (<tt>mt fsr 1; mt rewind; dump ...</tt>)
<p>Data transfer rate is 600kB/s (vendor claim with compression),
350 KB/s can even be reached in start/stop mode. The rate
decreases for smaller cartridges.
<p>Reported by: &a.joerg;
<sect3><heading><label id="hw:storage:wangtek5525es">
Wangtek 5525ES</heading>
<p>The boot message identifier for this drive is "WANGTEK
5525ES SCSI REV7 3R1" "type 1 removable SCSI 1" "density code 0x11, 1024-byte
blocks"
<p>This is a QIC tape drive.
<p>Native capacity is 525MB.
<p>Data transfer rate is 180kB/s.
<p>The drive reads 60, 120, 150, and 525MB tapes. The
drive will not write 60MB (DC600 cartridge) tapes. In order to
overwrite 120 and 150 tapes reliably, first erase (<tt>mt
erase</tt>) the tape. 120 and 150 tapes used a wider track
(fewer tracks per tape) than 525MB tapes. The "extra" width of
the previous tracks is not overwritten, as a result the new data
lies in a band surrounded on both sides by the previous data
unless the tape have been erased.
<p>This drives quirks are known and pre-compiled into the
scsi tape device driver (<tt>st(4)</tt>).
<p>Other firmware revisions that are known to work are: M75D
<p>Reported by: Marc van Kempen marc@bowtie.nl "REV73R1"
Andrew Gordon Andrew.Gordon@net-tel.co.uk "M75D"
<sect3><heading><label id="hw:storage:wangtek6200">
Wangtek 6200</heading>
<p>The boot message identifier for this drive is "WANGTEK
6200-HS 4B18" "type 1 removable SCSI 2" "Sequential-Access density code 0x13"
<p>This is a DDS-1 tape drive.
<p>Native capacity is 2GB using 90m tapes.
<p>Data transfer rate is 150kB/s.
<p>Reported by: Tony Kimball alk@Think.COM
<sect2><heading>* Problem drives</heading>
<sect1><heading>* CD-ROM drives</heading>
+ <p><em>Contributed by &a.obrien;.<newline>23 November 1997.</em></p>
+ <p>As mentioned in
+ <ref id="hw:jordans-picks:cdrom" name="Jordan's Picks">
+ Generally speaking those in <em>The FreeBSD Project</em> prefer SCSI
+ CDROM drives over IDE CDROM drives. However not all SCSI CDROM drives
+ are equal. Some feel the quality of some SCSI CDROM drives have been
+ deteriorating to that of IDE CDROM drives. Toshiba used to be the
+ favored stand-by, but many on the SCSI mailing list have found
+ displeasure with the 12x speed XM-5701TA as its volume (when playing
+ audio CDROMs) is not controlable by the various audio player software.
+
+ Another area where SCSI CDROM manufactors are cutting corners is
+ adhearance to the
+ <ref id="scsi:further-reading" name="SCSI specification">. Many SCSI
+ CDROMs will repsond to
+ <ref id="scsi:rogue-devices" name="multiple LUNs"> for its target address.
+ Known violators include the 6x Teac CD-56S 1.0D.
+
+
+
+
<sect1><heading>* Other</heading>
<sect1><heading>* Adding and reconfiguring disks</heading>
<sect1><heading> Tapes and backups<label id="hw:storage:tapebackups"></heading>
<sect2><heading>* What about backups to floppies?</heading>
<sect2><heading> Tape Media</heading>
<sect3><heading><label id="hw:storage:tapebackups:4mm">
4mm (DDS: Digital Data Storage)</heading>
<!--gen-->
<p>4mm tapes are replacing QIC as the workstation backup
media of choice. This trend accelerated greatly when Conner
purchased Archive, a leading manufacturer of QIC drives, and then
stopped production of QIC drives. 4mm drives are small and quiet
but do not have the reputation for reliability that is enjoyed by 8mm drives.
The cartridges are less expensive and smaller (3 x 2 x 0.5
inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has
comparatively short head life for the same reason, both use
helical scan.
<!--spec-->
<p>Data thruput on these drives starts ~150kB/s, peaking
at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB.
Hardware compression, available with most of these drives,
approximately doubles the capacity. Multi-drive tape library
units can have 6 drives in a single cabinet with automatic tape
changing. Library capacities reach 240 GB.
<!--tech-->
<p>4mm drives, like 8mm drives, use helical-scan. All
the benefits and drawbacks of helical-scan apply to both 4mm and
8mm drives.
<p>Tapes should be retired from use after 2,000 passes or
100 full backups.
<sect3><heading><label id="hw:storage:tapebackups:8mm">
8mm (Exabyte)</heading>
<!--gen-->
<p>8mm tapes are the most common SCSI tape drives; they
are the best choice of exchanging tapes. Nearly every site has
an exabyte 2 GB 8mm tape drive. 8mm drives are reliable,
convenient and quiet. Cartridges are inexpensive and small (4.8 x
3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is
relatively short head and tape life due to the high rate of
relative motion of the tape across the heads.
<!--spec-->
<p>Data thruput ranges from ~250kB/s to ~500kB/s. Data
sizes start at 300 MB and go up to 7 GB. Hardware compression,
available with most of these drives, approximately doubles the
capacity. These drives are available as single units or
multi-drive tape libraries with 6 drives and 120 tapes in a
single cabinet. Tapes are changed automatically by the unit.
Library capacities reach 840+ GB.
<!--tech-->
<p>Data is recorded onto the tape using helical-scan, the
heads are positioned at an angle to the media (approximately 6
degrees). The tape wraps around 270 degrees of the spool that
holds the heads. The spool spins while the tape slides over the
spool. The result is a high density of data and closely packed
tracks that angle across the tape from one edge to the other.
<sect3><heading><label id="hw:storage:tapebackups:qic">
QIC</heading>
<!--gen-->
<p>QIC-150 tapes and drives are, perhaps, the most common
tape drive and media around. QIC tape drives are the least
expensive "serious" backup drives. The downside is the cost of
media. QIC tapes are expensive compared to 8mm or 4mm tapes, up
to 5 times the price per GB data storage. But, if your needs can
be satisfied with a half-dozen tapes, QIC may be the correct
choice. QIC is the <em>most</em> common tape drive. Every site
has a QIC drive of some density or another. Therein lies the
rub, QIC has a large number of densities on physically similar
(sometimes identical) tapes. QIC drives are not quiet. These
drives audibly seek before they begin to record data and are
clearly audible whenever reading, writing or seeking. QIC tapes
measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). <ref
id="hw:storage:tapebackups:mini" name="Mini-cartridges">, which also
use 1/4" wide tape are discussed separately. Tape libraries and
changers are not available.
<!--spec-->
<p>Data thruput ranges from ~150kB/s to ~500kB/s. Data
capacity ranges from 40 MB to 15 GB. Hardware compression is
available on many of the newer QIC drives. QIC drives are less
frequently installed; they are being supplanted by DAT drives.
<!--tech-->
<p>Data is recorded onto the tape in tracks. The tracks
run along the long axis of the tape media from one end to the
other. The number of tracks, and therefore the width of a track,
varies with the tape's capacity. Most if not all newer drives
provide backward-compatibility at least for reading (but often
also for writing). QIC has a good reputation regarding the
safety of the data (the mechanics are simpler and more robust
than for helical scan drives).
<p>Tapes should be retired from use after 5,000 backups.
<sect3><heading><label id="hw:storage:tapebackups:mini">
* Mini-Cartridge</heading>
<sect3><heading><label id="hw:storage:tapebackups:dlt">
DLT</heading>
<!--gen-->
<p>DLT has the fastest data transfer rate of all the drive
types listed here. The 1/2" (12.5mm) tape is contained in a
single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The
cartridge has a swinging gate along one entire side of the
cartridge. The drive mechanism opens this gate to extract the
tape leader. The tape leader has an oval hole in it which the
drive uses to "hook" the tape. The take-up spool is located
inside the tape drive. All the other tape cartridges listed here
(9 track tapes are the only exception) have both the supply and
take-up spools located inside the tape cartridge itself.
<!--spec-->
Data thruput is approximately 1.5MB/s, three times the
thruput of 4mm, 8mm, or QIC tape drives. Data capacities range
from 10GB to 20GB for a single drive. Drives are available in
both multi-tape changers and multi-tape, multi-drive tape
libraries containing from 5 to 900 tapes over 1 to 20 drives,
providing from 50GB to 9TB of storage.
<!--tech-->
Data is recorded onto the tape in tracks parallel to the
direction of travel (just like QIC tapes). Two tracks are written
at once. Read/write head lifetimes are relatively long; once the
tape stops moving, there is no relative motion between the heads
and the tape.
<sect2><heading> Using a new tape for the first time</heading>
<p>The first time that you try to read or write a new,
completely blank tape, the operation will fail. The console
messages should be similar to:
<tscreen><verb>
st0(ncr1:4:0): NOT READY asc:4,1
st0(ncr1:4:0): Logical unit is in process of becoming ready
</verb></tscreen>
The tape does not contain an Identifier Block (block number
0). All QIC tape drives since the adoption of QIC-525 standard
write an Identifier Block to the tape. There are two
solutions:
<p><tt>mt fsf 1</tt> causes the tape drive to write an
Identifier Block to the tape.
<p>Use the front panel button to eject the tape.
<p>Re-insert the tape and <tt>dump(8)</tt> data to the
tape.
<p><tt>dump(8)</tt> will report <tt>DUMP: End of tape
detected</tt> and the console will show: <tt>HARDWARE FAILURE
info:280 asc:80,96</tt>
<p>rewind the tape using: <tt>mt rewind</tt>
<p>Subsequent tape operations are successful.
<sect2><heading> Backup Programs</heading>
<p>The three major programs are <tt>dump(8)</tt>,
<tt>tar(1)</tt>, and <tt>cpio(1)</tt>.
<sect3><heading> Dump and Restore</heading>
<!--gen-->
<p><tt>dump(8)</tt> and <tt>restore(8)</tt> are the
traditional Unix backup programs. They operate on the drive as a
collection of disk blocks, below the abstractions of files, links
and directories that are created by the filesystems.
<tt>dump(8)</tt> backs up devices, entire filesystems, not parts
of a filesystem and not directory trees that span more than one
filesystem, using either soft links <tt>ln(1)</tt> or mounting
one filesystem onto another. <tt>dump(8)</tt> does not write
files and directories to tape, but rather writes the data blocks
that are the building blocks of files and directories.
<tt>dump(8)</tt> has quirks that remain from its early days in
Version 6 of ATT Unix (circa 1975). The default parameters are
suitable for 9-track tapes (6250 bpi), not the high-density media
available today (up to 62,182 ftpi). These defaults must be
overridden on the command line to utilize the capacity of current
tape drives.
<p><tt>rdump(8)</tt> and <tt>rrestore(8)</tt> backup data
across the network to a tape drive attached to another computer.
Both programs rely upon <tt>rcmd(3)</tt> and <tt>ruserok(3)</tt>
to access the remote tape drive. Therefore, the user performing
the backup must have <tt>rhosts</tt> access to the remote
computer. The arguments to <tt>rdump(8)</tt> and
<tt>rrestore(8)</tt> must suitable to use on the remote computer.
(e.g. When <tt>rdump</tt>'ing from a FreeBSD computer to an
Exabyte tape drive connected to a Sun called komodo, use: <tt>/sbin/rdump
0dsbfu 54000 13000 126 komodo:/dev/nrst8 /dev/rsd0a 2>&1</tt>)
Beware: there are security implications to allowing
<tt>rhosts</tt> commands. Evaluate your situation carefully.
<sect3><heading> Tar</heading>
<!--gen-->
<p><tt>tar(1)</tt> also dates back to Version 6 of ATT
Unix (circa 1975). <tt>tar(1)</tt> operates in cooperation with
the filesystem; <tt>tar(1)</tt> writes files and directories to
tape. <tt>tar(1)</tt> does not support the full range of options
that are available from <tt>cpio(1)</tt>, but <tt>tar(1)</tt>
does not require the unusual command pipeline that
<tt>cpio(1)</tt> uses.
<p>Most versions of <tt>tar(1)</tt> do not support backups across the
network. The GNU version of <tt>tar(1)</tt>, which FreeBSD utilizes, supports
remote devices using the same syntax as <tt>rdump</tt>. To <tt>tar(1)</tt>
to an Exabyte tape drive connected to a Sun called komodo, use:
<tt>/usr/bin/tar cf komodo:/dev/nrst8 . 2>&1</tt>.
For versions without remote device support, you can use a pipeline
and <tt>rsh(1)</tt> to send the
data to a remote tape drive. (XXX add an example command)
<sect3><heading> Cpio</heading>
<!--gen-->
<p><tt>cpio(1)</tt> is the original Unix file interchange
tape program for magnetic media. <tt>cpio(1)</tt> has options (among
many others) to perform byte-swapping, write a number of
different archives format, and pipe the data to other programs.
This last feature makes <tt>cpio(1)</tt> and excellent choice for
installation media. <tt>cpio(1)</tt> does not know how to walk
the directory tree and a list of files must be provided thru <tt>STDIN</tt>.
<p><tt>cpio(1)</tt> does not support backups across the
network. You can use a pipeline and <tt>rsh(1)</tt> to send the
data to a remote tape drive. (XXX add an example command)
<sect3><heading> Pax</heading>
<!--gen-->
<p><tt>pax(1)</tt> is IEEE/POSIX's answer to <tt>tar</tt> and
<tt>cpio</tt>. Over the years the various versions of <tt>tar</tt> and
<tt>cpio</tt> have gotten slightly incompatable. So rather than fight it
out to fully standardize them, POSIX created a new archive utilility.
<tt>pax</tt> attempts to read and write many of the various cpio and tar
formats, plus new formats of its own. Its command set more resembles
<tt>cpio</tt> than <tt>tar</tt>.
<sect3><heading><label id="hw:storage:amanda"><htmlurl
url="http://www.freebsd.org/ports/misc.html#amanda-2.2.6.5"
name="Amanda"></heading>
<p>Amanda (Advanced Maryland Network Disk Archiver) is a
client/server backup system, rather than a single program. An
Amanda server will backup to a single tape drive any number of
computers that have Amanda clients and network communications
with the Amanda server. A common problem at locations with a
number of large disks is the length of time required to backup to
data directly to tape exceeds the amount of time available for
the task. Amanda solves this problem. Amanda can use a "holding
disk" to backup several filesystems at the same time. Amanda
creates "archive sets": a group of tapes used over a period of
time to create full backups of all the filesystems listed in
Amanda's configuration file. The "archive set" also contains
nightly incremental (or differential) backups of all the
filesystems. Restoring a damaged filesystem requires the most
recent full backup and the incremental backups.
<p>The configuration file provides fine control backups
and the network traffic that Amanda generates. Amanda will use
any of the above backup programs to write the data to tape.
Amanda is available as either a port or a package, it is not
installed by default.
<sect3><heading> Do nothing</heading>
<p>"Do nothing" is not a computer program, but it is the
most widely used backup strategy. There are no initial costs.
There is no backup schedule to follow. Just say no. If
something happens to your data, grin and bear it!
<p>If your time and your data is worth little to nothing,
then "Do nothing" is the most suitable backup program for your
computer. But beware, Unix is a useful tool, you may find that
within six months you have a collection of files that are
valuable to you.
<p>"Do nothing" is the correct backup method for
<tt>/usr/obj</tt> and other directory trees that can be exactly
recreated by your computer. An example is the files that
comprise these handbook pages-they have been generated from
<tt>SGML</tt> input files. Creating backups of these
<tt>HTML</tt> files is not necessary. The <tt>SGML</tt> source
files are backed up regularly.
<sect3><heading> Which Backup Program is Best?</heading>
<p><tt>dump(8)</tt> <em>Period.</em> Elizabeth D. Zwicky
torture tested all the backup programs discussed here. The clear
choice for preserving all your data and all the peculiarities of
Unix filesystems is <tt>dump(8)</tt>. Elizabeth created
filesystems containing a large variety of unusual conditions (and
some not so unusual ones) and tested each program by do a backup
and restore of that filesystems. The peculiarities included:
files with holes, files with holes and a block of nulls, files
with funny characters in their names, unreadable and unwriteable
files, devices, files that change size during the backup, files
that are created/deleted during the backup and more. She
presented the results at LISA V in Oct. 1991.
<sect2><heading>Emergency Restore Procedure</heading>
<sect3><heading> Before the Disaster</heading>
<p>There are only four steps that you need to perform in
preparation for any disaster that may occur.
<p>First, print the disklabel from each of your disks
(<tt>e.g. disklabel sd0 | lpr</tt>), your filesystem table
(<tt>/etc/fstab</tt>) and all boot messages, two copies of each.
<p>Second, determine the boot and fixit floppies
(boot.flp and fixit.flp) have all your devices. The easiest way
to check is to reboot your machine with the boot floppy in the
floppy drive and check the boot messages. If all your devices
are listed and functional, skip on to step three.
<p>Otherwise, you have to create two custom bootable
floppies which has a kernel that can mount your all of your disks
and access your tape drive. These floppies must contain:
<tt>fdisk(8)</tt>, <tt>disklabel(8)</tt>, <tt>newfs(8)</tt>,
<tt>mount(8)</tt>, and whichever backup program you use. These
programs must be statically linked. If you use <tt>dump(8)</tt>,
the floppy must contain <tt>restore(8)</tt>.
<p>Third, create backup tapes regularly.
Any changes that you make after your last backup may be
irretrievably lost. Write-protect the backup tapes.
<p>Fourth, test the floppies (either boot.flp and
fixit.flp or the two custom bootable floppies you made in step
two.) and backup tapes. Make notes of the procedure. Store
these notes with the bootable floppy, the printouts and the
backup tapes. You will be so distraught when restoring that the
notes may prevent you from destroying your backup tapes (How? In
place of <tt>tar xvf /dev/rst0</tt>, you might accidently type
<tt> tar cvf /dev/rst0</tt> and over-write your backup tape).
<p>For an added measure of security, make bootable
floppies and two backup tapes each time. Store one of each at a
remote location. A remote location is NOT the basement of the
same office building. A number of firms in the World Trade Center
learned this lesson the hard way. A remote location should be
physically separated from your computers and disk drives by a
significant distance.
<p>An example script for creating a bootable floppy:
<tscreen><verb>
#!/bin/sh
#
# create a restore floppy
#
# format the floppy
#
PATH=/bin:/sbin:/usr/sbin:/usr/bin
fdformat -q fd0
if [ $? -ne 0 ]
then
echo "Bad floppy, please use a new one"
exit 1
fi
# place boot blocks on the floppy
#
disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/rfd0c fd1440
#
# newfs the one and only partition
#
newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a
#
# mount the new floppy
#
mount /dev/fd0a /mnt
#
# create required directories
#
mkdir /mnt/dev
mkdir /mnt/bin
mkdir /mnt/sbin
mkdir /mnt/etc
mkdir /mnt/root
mkdir /mnt/mnt # for the root partition
mkdir /mnt/tmp
mkdir /mnt/var
#
# populate the directories
#
if [ ! -x /sys/compile/MINI/kernel ]
then
cat << EOM
The MINI kernel does not exist, please create one.
Here is an example config file:
#
# MINI -- A kernel to get FreeBSD on onto a disk.
#
machine "i386"
cpu "I486_CPU"
ident MINI
maxusers 5
options INET # needed for _tcp _icmpstat _ipstat
# _udpstat _tcpstat _udb
options FFS #Berkeley Fast File System
options FAT_CURSOR #block cursor in syscons or pccons
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
options NCONS=2 #1 virtual consoles
options USERCONFIG #Allow user configuration with -c XXX
config kernel root on sd0 swap on sd0 and sd1 dumps on sd0
controller isa0
controller pci0
controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk fd0 at fdc0 drive 0
controller ncr0
controller scbus0
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
device sd0
device sd1
device sd2
device st0
pseudo-device loop # required by INET
pseudo-device gzip # Exec gzipped a.out's
EOM
exit 1
fi
cp -f /sys/compile/MINI/kernel /mnt
gzip -c -best /sbin/init > /mnt/sbin/init
gzip -c -best /sbin/fsck > /mnt/sbin/fsck
gzip -c -best /sbin/mount > /mnt/sbin/mount
gzip -c -best /sbin/halt > /mnt/sbin/halt
gzip -c -best /sbin/restore > /mnt/sbin/restore
gzip -c -best /bin/sh > /mnt/bin/sh
gzip -c -best /bin/sync > /mnt/bin/sync
cp /root/.profile /mnt/root
cp -f /dev/MAKEDEV /mnt/dev
chmod 755 /mnt/dev/MAKEDEV
chmod 500 /mnt/sbin/init
chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt
chmod 555 /mnt/bin/sh /mnt/bin/sync
chmod 6555 /mnt/sbin/restore
#
# create the devices nodes
#
cd /mnt/dev
./MAKEDEV std
./MAKEDEV sd0
./MAKEDEV sd1
./MAKEDEV sd2
./MAKEDEV st0
./MAKEDEV pty0
cd /
#
# create minimum filesystem table
#
cat > /mnt/etc/fstab <<EOM
/dev/fd0a / ufs rw 1 1
EOM
#
# create minimum passwd file
#
cat > /mnt/etc/passwd <<EOM
root:*:0:0:Charlie &:/root:/bin/sh
EOM
cat > /mnt/etc/master.passwd <<EOM
root::0:0::0:0:Charlie &:/root:/bin/sh
EOM
chmod 600 /mnt/etc/master.passwd
chmod 644 /mnt/etc/passwd
/usr/sbin/pwd_mkdb -d/mnt/etc /mnt/etc/master.passwd
#
# umount the floppy and inform the user
#
/sbin/umount /mnt
</verb></tscreen>
<sect3><heading>After the Disaster</heading>
<p>The key question is: did your hardware survive? You
have been doing regular backups so there is no need to worry
about the software.
<p>If the hardware has been damaged. First, replace
those parts that have been damaged.
<p>If your hardware is okay, check your floppies. If you
are using a custom boot floppy, boot single-user (type "-s" at
the "boot:" prompt). Skip the following paragraph.
<p>If you are using the boot.flp and fixit.flp floppies,
keep reading. Insert the boot.flp floppy in the first floppy drive
and boot the computer. The original install menu will be displayed
on the screen. Select the "Fixit--Repair mode with CDROM or floppy."
option. Insert the fixit.flp when prompted. <tt>restore</tt> and
the other programs that you need are located in <tt>/mnt2/stand</tt>.
<p>Recover each filesystem separately.
<p>Try to <tt>mount(8) (e.g. mount /dev/sd0a /mnt) </tt>
the root partition of your first disk. If the disklabel was
damaged, use <tt>disklabel(8)</tt> to re-partition and label the
disk to match the label that your printed and saved. Use
<tt>newfs(8)</tt> to re-create the filesystems. Re-mount the
root partition of the floppy read-write ("<tt>mount -u -o rw
/mnt</tt>"). Use your backup program and backup tapes to recover
the data for this filesystem (e.g. <tt>restore vrf
/dev/st0</tt>). Unmount the filesystem (e.g. <tt>umount
/mnt</tt>) Repeat for each filesystem that was damaged.
<p>Once your system is running, backup your data onto new
tapes. Whatever caused the crash or data loss may strike again.
An another hour spent now, may save you from further distress later.
<sect3><heading>* I did not prepare for the Disaster, What Now?</heading>
<sect1><heading>* Serial ports</heading>
<sect1><heading>* Sound cards</heading>
<sect1><heading>* PCMCIA</heading>
<sect1><heading>* Other<label id="hw:other"></heading>
diff --git a/handbook/scsi.sgml b/handbook/scsi.sgml
index d02b89a87a..59706eeb31 100644
--- a/handbook/scsi.sgml
+++ b/handbook/scsi.sgml
@@ -1,891 +1,892 @@
-<!-- $Id: scsi.sgml,v 1.22 1997-02-22 12:59:18 peter Exp $ -->
+<!-- $Id: scsi.sgml,v 1.23 1997-11-23 19:13:42 obrien Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
<title>An introduction to SCSI and its use with FreeBSD</title>
<author>(c) 1995-1996, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
<date>Sat Jul 6 20:57:39 MET DST 1996</date>
Copyright 1995-1996, Wilko 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>
-->
<sect1><heading>What is SCSI?<label id="scsi"></heading>
<p><em>Copyright © 1995, &a.wilko;.<newline>July 6, 1996.</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 recognized in the ANSI SCSI-1 standard. The SCSI-1
standard (approx 1985) is rapidly becoming 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 do not know what
single-ended means, do not worry, that is what this document is all
about.) Modern designs also use 16 bit wide buses, with
differential signals. This allows transfer speeds of
20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2
allows a maximum bus width of 32 bits, using an additional cable.
Quickly emerging are Ultra SCSI (also called Fast-20) and Ultra2
(also called Fast-40). Fast-20 is 20 mega-transfers per second
(20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 mega-transfers per
second (40 Mbytes/sec on a 8 bit bus).
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 separate
parity line. In pre-SCSI-2 designs parity was optional.
In SCSI-3 even faster bus types are introduced, along with a serial
SCSI busses that reduces the cabling overhead and allows a higher
maximum bus length. You might see names like SSA and Fiberchannel
in this context. None of the serial buses are currently in widespread
use (especially not in the typical FreeBSD environment). For
this reason the serial bus types are not discussed any further.
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 bad block replacement etc
are all made possible by this 'intelligent device' approach.
On a SCSI bus, each possible pair of devices can communicate. Whether
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. I say
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 standardization 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 implies that you do not 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. From
a performance standpoint you might want to separate your older
and newer (=faster) devices however.
<sect2><heading>Components of SCSI</heading>
<p>
<!-- <sect3><heading>A <it>smart</it> interface</heading>
<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. FreeBSD uses this
capability during boot to check out what devices are connected
and whether they need any special treatment.
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.
<!-- <sect3><heading>Do's and don't's on interconnections</heading>
<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: do no 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 by 1 meter solved the problem. And the
original bus length was well within the SCSI specification.
<sect2><heading>SCSI bus types</heading>
<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. As discussed before, bus
speeds of 20 and 40 megatransfers/second are also emerging
(Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI).
It should be noted that the data lines > 8 are only used for
data transfers and device addressing. The transfers of commands
and status messages etc are only performed on the lowest 8
data lines. The standard allows narrow devices to operate on
a wide bus. The usable bus width is negotiated
between the devices. You have to watch your device addressing
closely when mixing wide and narrow.
<sect3><heading>Single ended buses</heading>
<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.
Fast-20 (Ultra SCSI) and Fast-40 allow for 20 and 40
megatransfers/second respectively. So, F20 is 20 Mbytes/second
on a 8 bit bus, 40 Mbytes/second on a 16 bit bus etc.
For F20 the max bus length is 1.5 meters, for F40 it
becomes 0.75 meters. Be aware that F20 is pushing
the limits quite a bit, so you will quickly find out if your
SCSI bus is electrically sound.
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
bus length 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. For Fast-20 and 40
do not even think about buses like this.
<sect3><heading>Differential buses</heading>
<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 its 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 (do not 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
AHA1740 as a single ended board, whereas the AHA1744 was differential.
The software interface to the host is identical for both.
<sect3><heading>Terminators</heading>
<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 traveling over your SCSI bus, you
do not 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 store them. 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 built-in terminator.
There are special terminators you can stick onto a flat cable
bus. Others look like external connectors, or 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 slightly more elaborate
circuit to give cleaner bus signals. The general consensus
seems to be that the usefulness 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 favor 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.
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><heading>Terminator power</heading>
<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 its 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 un-powered devices on a bus, the terminator
power must be supplied to the bus via a diode. This prevents
the backflow of current to un-powered 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 that 'reset'
themselves after some time are sometimes used.
<sect3><heading>Device addressing</heading>
<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 dip switch, 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. A pitfall is that one of the
devices sharing the same ID sometimes even manages to answer
to I/O requests!
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
data lines on the bus. For wide buses this increases to the
number of data lines.
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
host adapter 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
tape changer. In this way, the host system can address each of
the functional units of the tape changer as desired.
<sect3><heading>Bus layout</heading>
<p>
SCSI buses are linear. So, not shaped like Y-junctions, star
topologies, cobwebs 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, its noise margins and
ultimately the reliability of it all are tightly related to
linear bus rule.
<bf>Stick to the linear bus rule!</bf>
<sect2><heading>Using SCSI with FreeBSD</heading>
<p>
<sect3><heading>About translations, BIOSes and magic...</heading>
<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
its first incarnation used a low level physical interface to the
hard disk. So, you had to tell the BIOS (using a setup tool or a
BIOS built-in 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 in order to load the
FreeBSD kernel during boot.
The SCSI host adapter or SCSI controller you have put in your
AT/EISA/PCI/whatever bus to connect your disk therefore has its
own on-board BIOS. During system startup, the SCSI BIOS takes over
the hard disk interface routines from the system BIOS. To fool the
system BIOS, the system setup is normally set to No hard disk
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 64 heads and 32 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 is not. The system BIOS has
another quirk you might run into. The number of cylinders of a
bootable hard disk cannot be greater than 1024. Using the
translation above, this is a show-stopper 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 lead to
un-bootable systems or operating systems overwriting each
others partitions. Using fdisk you should be able to see
all partitions.
You might have heard some talk of 'lying' devices?
Older FreeBSD kernels used to report the geometry
of SCSI disks when booting. An example from one of my systems:
<verb>
aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512
</verb>
Newer kernels usually do not report this information. e.g.
<verb>
(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)
</verb>
Why has this changed?
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 suspect at best, and nearly always misleading. When
asked for a geometry , it is nearly always better to supply the
geometry used by the BIOS, or <em>if the BIOS is never going to know
about this disk</em>, (e.g. it is not a booting disk) to supply a
fictitious geometry that is convenient.
<sect3><heading>SCSI subsystem design</heading>
<p>
FreeBSD uses a layered SCSI subsystem. For each different
controller card a 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 its 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 manageable problem.
<sect3><heading>Kernel configuration</heading>
<p>
Dependent on your hardware, the kernel configuration file must
contain one or more lines describing your host adapter(s).
This includes I/O addresses, interrupts etc.
Consult the man page for your
adapter driver to get more info. Apart from that, check out
/sys/i386/conf/LINT for an overview of a kernel config file.
LINT contains every possible option you can dream of. It
does <em>not</em> imply LINT will actually get you to a
working kernel at all.
Although it is probably stating the obvious: the kernel config
file should reflect your actual hardware setup. So, interrupts,
I/O addresses etc must match the kernel config file. During
system boot messages will be displayed to indicate whether
the configured hardware was actually found.
An example loosely based on the FreeBSD 2.0.5-Release kernel config
file LINT with some added comments (between []):
<verb>
# SCSI host adapters: `aha', `ahb', `aic', `bt', `nca'
#
# aha: Adaptec 154x
# ahb: Adaptec 174x
# ahc: Adaptec 274x/284x/294x
# aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!)
# bt: Most Buslogic controllers
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
# uha: UltraStore 14F and 34F
# sea: Seagate ST01/02 8 bit controller (slow!)
# wds: Western Digital WD7000 controller (no scatter/gather!).
#
[For an Adaptec AHA274x, 284x etc controller]
controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem?
[For an Adaptec AHA174x controller]
controller ahb0 at isa? bio irq ? vector ahbintr
[For an Ultrastor adapter]
controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr
# Map SCSI buses to specific SCSI adapters
controller scbus0 at ahc0
controller scbus2 at ahb0
controller scbus1 at uha0
# The actual SCSI devices
disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted]
disk sd2 at scbus1 target 3 [SCSI disk on the uha0]
disk sd3 at scbus2 target 4 [SCSI disk on the ahb0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CDROM found, no wiring]
</verb>
The example above tells the kernel to look for a ahc (Adaptec 274x)
controller, then for an Adaptec 174x board, and
so on. The lines following the controller specifications
tell the kernel to configure specific devices but
<em>only</em> attach them when they match the target ID and
LUN specified on the corresponding bus.
Wired down devices get 'first shot' at the unit numbers
so the first non 'wired down' device, is allocated the unit number
one greater than the highest 'wired down' unit number
for that kind of device.
So, if you had a SCSI tape at target ID 2 it would be
configured as st2, as the tape at target ID 6 is wired down
to unit number 1. Note that <em>wired down devices need not
be found</em>
to get their unit number. The unit number for a wired down device
is reserved for that device, even if it is turned off at boot
time. This allows the device to be turned on and brought
on-line at a later time, without rebooting. Notice that a device's
unit number has <em>no</em> relationship with its target ID on
the SCSI bus.
Below is another example of a kernel config file as used by
FreeBSD version < 2.0.5. The difference with the first example is
that devices are not 'wired down'. 'Wired down' means
that you specify which SCSI target belongs to which device.
A kernel built to the config file below will attach
the first SCSI disk it finds to sd0, the second disk to sd1
etc. If you ever removed or added a disk, all other devices
of the same type (disk in this case) would 'move around'.
This implies you have to change <tt>/etc/fstab</tt> each time.
Although the old style still works, you
are <em>strongly</em> recommended to use this new feature.
It will save you a lot of grief whenever you shift your
hardware around on the SCSI buses. So, when you re-use
your old trusty config file after upgrading from a
pre-FreeBSD2.0.5.R system check this out.
<verb>
[driver for Adaptec 174x]
controller ahb0 at isa? bio irq 11 vector ahbintr
[for Adaptec 154x]
controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr
[for Seagate ST01/02]
controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr
controller scbus0
device sd0 [support for 4 SCSI harddisks, sd0 up sd3]
device st0 [support for 2 SCSI tapes]
[for the cdrom]
device cd0 #Only need one of these, the code dynamically grows
</verb>
Both examples support 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 simply allocate
more devices, incrementing the unit number starting at the last
number 'wired down'. If there are no 'wired down' devices
then counting starts at unit 0.
Use <tt>man 4 scsi</tt> to check for the latest info on the SCSI
subsystem. For more detailed info on host adapter drivers use eg
<tt>man 4 aha</tt> for info on the Adaptec 154x driver.
<sect3><heading>Tuning your SCSI kernel setup</heading>
<p>
Experience has shown that some devices are slow to respond to INQUIRY
commands after a SCSI bus reset (which happens at boot time).
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 the 'slow response' problem, FreeBSD allows a
tunable delay time
before the SCSI devices are probed following a SCSI bus reset.
You can set this delay time 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 recognized.
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.
- <sect3><heading>Rogue SCSI devices</heading>
+ <sect3><heading>Rogue SCSI devices<label id="scsi:rogue-devices">
+ </heading>
<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 recognized 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 /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:>
Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue
Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005>
Mar 29 21:16:37 yedi /kernel: 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 reader.
The SCSI subsystem of FreeBSD recognizes 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. See e.g. /sys/scsi/st.c and
/sys/scsi/scsiconf.c for more info on how this is done.
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.
After you got your Mumbletech working, please send the required
workaround to the FreeBSD development team for inclusion in the
next release of FreeBSD. Other Mumbletech owners will be grateful
to you.
<sect3><heading>Multiple LUN devices</heading>
<p>
In some cases you come across devices that use multiple
logical units (LUNs) on a single SCSI ID. In most cases
FreeBSD only probes devices for LUN 0. An example are
so called bridge boards that connect 2 non-SCSI harddisks
to a SCSI bus (e.g. an Emulex MD21 found in old Sun systems).
This means that any devices with LUNs != 0 are not normally
found during device probe on system boot. To work around this
problem you must add an appropriate entry in /sys/scsi/scsiconf.c
and rebuild your kernel.
Look for a struct that is initialised like below:
<verb>
{
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
"mx1", SC_ONE_LU
}
</verb>
For you Mumbletech BRIDGE2000 that has more than one LUN,
acts as a SCSI disk
and has firmware revision 123 you would add something like:
<verb>
{
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
"sd", SC_MORE_LUS
}
</verb>
The kernel on boot scans the inquiry data it receives against
the table and acts accordingly. See the source for more info.
<sect3><heading>Tagged command queueing</heading>
<p>
Modern SCSI devices, particularly magnetic disks, support
what is called tagged command queuing (TCQ).
In a nutshell, TCQ allows the device to have multiple I/O
requests outstanding at the same time. Because the device
is intelligent, it can optimise its operations (like
head positioning) based on its own request queue. On
SCSI devices like RAID (Redundant Array of Independent
Disks) arrays the TCQ function is indispensable to take
advantage of the device's inherent parallelism.
Each I/O request is uniquely identified by a 'tag' (hence
the name tagged command queuing) and this tag is used by
FreeBSD to see which I/O in the device drivers queue is
reported as complete by the device.
It should be noted however that TCQ requires device driver
support and that some devices implemented it 'not quite
right' in their firmware. This problem bit me once, and
it leads to highly mysterious problems. In such cases,
try to disable TCQ.
<sect3><heading>Busmaster host adapters</heading>
<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
transfer speeds 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).
<sect2><heading>Tracking down problems</heading>
<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 double check 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 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 host adapter to use slow bus speeds.
<item>
Disable tagged command queuing to make things as simple as
possible (for a NCR hostadapter based system see man
ncrcontrol)
<item>
If you can compile a kernel, make one with the SCSIDEBUG option,
and try accessing the device with debugging turned on for
that device. If your device does not even probe at startup,
you may have to define the address of the device that
is failing, and the desired debug level in
<tt>/sys/scsi/scsidebug.h</tt>.
If it probes but just does not work, you can use the
<tt>scsi(8)</tt> command to dynamically set a debug level to
it in a running kernel (if SCSIDEBUG is defined).
This will give you COPIOUS debugging output with which to confuse
the gurus. see <tt>man 4 scsi</tt> for more exact information.
Also look at <tt>man 8 scsi</tt>.
</itemize>
<sect2><heading>Further reading<label id="scsi:further-reading"></heading>
<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:
<itemize>
<item>AT Attachment (ATA or IDE) [X3.221-1994] (<em>Approved</em>)
<item>ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
<item>Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (<em>Approved</em>)
<item>Small Computer System Interface - 2 (SCSI-2) [X3.131-1994] (<em>Approved</em>)
<item>SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM)
[X3T10/792D Rev 11]
</itemize>
Other publications that might provide you with additional information are:
<itemize>
<item>"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
<item>"Basics of SCSI", a SCSI tutorial written by Ancot Corporation
Contact Ancot for availability information at:
Phone: (415) 322-5322 Fax: (415) 322-0455
<item>"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
<item>"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
<item>"The SCSI Bench Reference", "The SCSI Encyclopedia", and the "SCSI Tutor",
ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070
Phone: (408) 867-6642
<item>"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
</itemize>
On Usenet the newsgroups <htmlurl
url="news:comp.periphs.scsi" name="comp.periphs.scsi">
and <htmlurl url="news:comp.periphs" name="comp.periphs">
are noteworthy places to look for more info. You can also
find the SCSI-Faq there, which is posted periodically.
Most major SCSI device and host adapter suppliers operate ftp sites
and/or BBS systems. They may be valuable sources of information
about the devices you own.