diff --git a/en/handbook/hw/chapter.sgml b/en/handbook/hw/chapter.sgml
index 0035977899..61c9047178 100644
--- a/en/handbook/hw/chapter.sgml
+++ b/en/handbook/hw/chapter.sgml
@@ -1,5684 +1,5685 @@
PC Hardware compatibility
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. You may also want to refer to the kernel configuration
file section in this handbook for
a list of supported devices.
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
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.
Resources on the Internet
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.
The Pentium
Systems Hardware Performance Guide
Sample Configurations
The following list of sample hardware configurations by no means
constitutes an endorsement of a given hardware vendor or product by
The FreeBSD Project. 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.
Jordan's Picks
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.
Motherboards
For Pentium Pro (P6) systems, I'm quite fond of the Tyan
S1668 dual-processor motherboard as well as the Intel PR440FX
motherboard with on-board SCSI WIDE and 100/10MB Intel
Etherexpress NIC. You can build a dandy little single or dual
processor system (which is supported in FreeBSD 3.0) for very
little cost now that the Pentium Pro 180/256K chips have fallen so
greatly in price, but no telling how much longer this will
last.
For the Pentium II, I'm rather partial to the ASUS P2l97-S motherboard with the on-board Adaptec SCSI WIDE controller.
For Pentium machines, the ASUS P55T2P4 motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems.
Those wishing to build more fault-tolerant systems should
also be sure to use Parity memory or, for truly 24/7
applications, ECC memory.
ECC memory does involve a slight performance trade-off
(which may or may not be noticeable depending on your
application) but buys you significantly increased
fault-tolerance to memory errors.
Disk Controllers
This one is a bit trickier, and while I used to recommend
the Buslogic
controllers unilaterally for everything from ISA to PCI, now I
tend to lean towards the Adaptec 1542CF for ISA,
Buslogic Bt747c for EISA and Adaptec 2940UW 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).
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.
There are two types of 3940 on the market—the older
model with AIC 7880 chips on it, and hte newer one with AIC 7895
chips. The newer model requires CAM support which is not yet part of FreeBSD—you have to add it, or install from one of the CAM binary snapshot release.
Disk drives
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! For a serious server configuration, there's not
even any argument—use SCSI equipment and good cables.
CDROM drives
My SCSI preferences extend to SCSI CDROM drives as well, and
while the Toshiba
drives have always been favourites of mine (in whatever speed is
hot that week), I'm still fond of my good old Plextor PX-12CS drive. It's
only a 12 speed, but it's offered excellent performance and
reliability.
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.
CD Recordable (WORM) drives
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 6020i. I myself use the HP 6020i for burning
CDROMs (in 2.2 and alter releases—it does not work with
earlier releases of the SCSI code) and it works very well. See
/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 HP6020i CDR.
Tape drives
I've had pretty good luck with both 8mm drives from Exabyte and 4mm (DAT) drives from HP.
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.
Video Cards
If you can also afford to buy a commercial X server for
US$99 from Xi Graphics,
Inc. (formerly X Inside, Inc) then I can heartily
recommend the Matrox
Millenium II card. Note that support for this card is also excellent with the XFree86 server, which is now at version 3.3.2.
You also certainly can't go wrong with one of 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. You can
also pick up their Revolution 3D cards very cheaply these days,
especially if you require a lot of video memory.
Monitors
I have had very good luck with the Sony Multiscan 17seII 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,000 for a 21" monitor or $1,700 for a 20" 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!
Networking
I can recommend the Intel EtherExpress Pro/100B card first
ande foremost, followed by the SMC Ultra 16 controller for
any ISA application and the SMC EtherPower or Compex ENET32
cards for slightly cheaper PCI based networking. In general, any
PCI NIC based around DEC's DC21041 Ethernet controller chip,
such as the Zynx ZX342 or DEC DE435, will generally work quite
well and can frequently be found in 2-port and 4-port version
(useful for firewalls and routers), though the Pro/100MB card has
the edge when it comes to providing the best performance with teh
lower overhead.
If what you're looking for is the
cheapest possible solution then almost any NE2000 clone will do
a fine job for very little cost.
Serial
If you're looking for high-speed serial networking
solutions, then Digi
International makes the SYNC/570 series, with drivers now in FreeBSD-current. Emerging Technologies also manufactures a board with T1/E1 capabilities, using software they provide. I have no direct experience using either product, however.
Multiport card options are somewhat more numerous, though it
has to be said that FreeBSD's support for 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 Stallion
Technologies apparently offers an unofficial driver
for their cards at this location.
Audio
I currently use a Creative Labs AWE32 though
just about anything from Creative Labs will generally work these
days. This is not to say that other types of sound cards don't
also work, simply that I have little experience with them (I was
a former GUS fan, but Gravis's soundcard situation has been dire
for some time).
Video
For video capture, there are two good choices — any card
based on the Brooktree BT848 chip, such as the Hauppage or WinTV
boards, will work very nicely with FreeBSD. Another board which
works for me is the Matrox Meteor
card. FreeBSD also supports the older video spigot card from
Creative Labs, but those are getting somewhat difficult to find.
Note that the Meteor frame grabber card will not
work with motherboards based on the 440FX chipset!
See the
motherboard reference section for
details. In such cases, it's better to go with a BT848 based
board.
Core/Processing
Motherboards, busses, and chipsets
* ISA
* EISA
* VLB
PCI
Contributed by &a.obrien; from postings by &a.rgrimes;.25 April
1995.
Continuing updates by &a.jkh;.Last update on 26 August 1996.
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.
Mercury:
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.
Saturn-I (ie, 82424ZX at rev 0,
1 or 2):
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.
Saturn-II (ie, 82424ZX at rev 3
or 4):
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).
Neptune:
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”.
Triton (ie,
430FX):
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.
Triton-II (ie,
430HX):
All reports on motherboards using this chipset have
been favorable so far. No known problems.
Orion:
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.
440FX:
This 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.
CPUs/FPUs
Contributed by &a.asami;.26 December
1997.
P6 class (Pentium Pro/Pentium II)
Both the Pentium Pro and Pentium II work fine with FreeBSD.
In fact, our main ftp site ftp.freebsd.org (also
known as "ftp.cdrom.com", world's largest
ftp site) runs FreeBSD on a Pentium Pro. Configurations details are available for interested parties.
Pentium class
The Intel Pentium (P54C), Pentium MMX (P55C), AMD K6 and
Cyrix/IBM 6x86MX processors are all reported to work with
FreeBSD. I will not go into details of which processor is
faster than what, there are zillions of web sites on the
Internet that tells you one way or another. :)
Various CPUs have different voltage/cooling requirements.
Make sure your motherboard can supply the exact voltage needed
by the CPU. For instance, many recent MMX chips require split
voltage (e.g., 2.9V core, 3.3V I/O). Also, some AMD and
Cyrix/IBM chips run hotter than Intel chips. In that case,
make sure you have good heatsink/fans (you can get the list of
certified parts from their web pages).
Clock speeds
Contributed by &a.rgrimes;.1
October 1996.
Updated by &a.asami;.27 December
1997.
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:
Rated CPU MHz
External Clock and Memory Bus MHz
External to Internal Clock Multiplier
PCI Bus Clock 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 (Intel, AMD)
150
75
2
37.5 (Cyrix/IBM 6x86MX)
166
66
2.5
33
180
60
3
30
200
66
3
33
233
66
3.5
33
66MHz may actually be 66.667MHz, but don't assume
so.
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.
As can be seen the best parts to be using are the 100,
133, 166, 200 and 233, with the exception that at a multiplier
of 3 or more the CPU starves for memory.
The AMD K6 Bug
In 1997, there have been reports of the AMD K6 seg
faulting during heavy compilation. That problem has been
fixed in 3Q '97. According to reports, K6 chips with date mark
“9733” or larger (i.e., manufactured in the 33rd week of '97
or later) do not have this bug.
* 486 class
* 386 class
286 class
Sorry, FreeBSD does not run on 80286 machines. It is nearly
impossible to run today's large full-featured UNIXes on such
hardware.
* Memory
The minimum amount of memory you must have to install FreeBSD
is 5 MB. Once your system is up and running you can build a custom kernel
that will use less memory. If you use the boot4.flp you can get
away with having only 4 MB.
* BIOS
Input/Output Devices
* Video cards
* Sound cards
Serial ports and multiport cards
The UART: What it is and how it works
Copyright © 1996 &a.uhclem;, All Rights
Reserved. 13 January 1996.
The Universal Asynchronous Receiver/Transmitter (UART)
controller is the key component of the serial communications
subsystem of a computer. The UART takes bytes of data and
transmits the individual bits in a sequential fashion. At the
destination, a second UART re-assembles the bits into complete
bytes.
Serial transmission is commonly used with modems and for
non-networked communication between computers, terminals and
other devices.
There are two primary forms of serial transmission:
Synchronous and Asynchronous. Depending on the modes that are
supported by the hardware, the name of the communication
sub-system will usually include a A if it supports
Asynchronous communications, and a S if it supports
Synchronous communications. Both forms are described
below.
Some common acronyms are:
UART Universal Asynchronous
Receiver/Transmitter
USART Universal Synchronous-Asynchronous
Receiver/Transmitter
Synchronous Serial Transmission
Synchronous serial transmission requires that the sender
and receiver share a clock with one another, or that the
sender provide a strobe or other timing signal so that the
receiver knows when to “read” the next bit of the data. In
most forms of serial Synchronous communication, if there is no
data available at a given instant to transmit, a fill
character must be sent instead so that data is always being
transmitted. Synchronous communication is usually more
efficient because only data bits are transmitted between
sender and receiver, and synchronous communication can be more
more costly if extra wiring and circuits are required to share
a clock signal between the sender and receiver.
A form of Synchronous transmission is used with printers
and fixed disk devices in that the data is sent on one set of
wires while a clock or strobe is sent on a different wire.
Printers and fixed disk devices are not normally serial
devices because most fixed disk interface standards send an
entire word of data for each clock or strobe signal by using a
separate wire for each bit of the word. In the PC industry,
these are known as Parallel devices.
The standard serial communications hardware in the PC does
not support Synchronous operations. This mode is described
here for comparison purposes only.
Asynchronous Serial Transmission
Asynchronous transmission allows data to be transmitted
without the sender having to send a clock signal to the
receiver. Instead, the sender and receiver must agree on
timing parameters in advance and special bits are added to
each word which are used to synchronize the sending and
receiving units.
When a word is given to the UART for Asynchronous
transmissions, a bit called the "Start Bit" is added to the
beginning of each word that is to be transmitted. The Start
Bit is used to alert the receiver that a word of data is about
to be sent, and to force the clock in the receiver into
synchronization with the clock in the transmitter. These two
clocks must be accurate enough to not have the frequency
drift by more than 10% during the transmission of the
remaining bits in the word. (This requirement was set in the
days of mechanical teleprinters and is easily met by modern
electronic equipment.)
After the Start Bit, the individual bits of the word of
data are sent, with the Least Significant Bit (LSB) being sent
first. Each bit in the transmission is transmitted for
exactly the same amount of time as all of the other bits, and
the receiver “looks” at the wire at approximately halfway
through the period assigned to each bit to determine if the
bit is a 1 or a 0. For example, if it takes two seconds
to send each bit, the receiver will examine the signal to
determine if it is a 1 or a 0 after one second has passed,
then it will wait two seconds and then examine the value of
the next bit, and so on.
The sender does not know when the receiver has “looked” at
the value of the bit. The sender only knows when the clock
says to begin transmitting the next bit of the word.
When the entire data word has been sent, the transmitter
may add a Parity Bit that the transmitter generates. The
Parity Bit may be used by the receiver to perform simple error
checking. Then at least one Stop Bit is sent by the
transmitter.
When the receiver has received all of the bits in the data
word, it may check for the Parity Bits (both sender and
receiver must agree on whether a Parity Bit is to be used),
and then the receiver looks for a Stop Bit. If the Stop Bit
does not appear when it is supposed to, the UART considers the
entire word to be garbled and will report a Framing Error to
the host processor when the data word is read. The usual
cause of a Framing Error is that the sender and receiver
clocks were not running at the same speed, or that the signal
was interrupted.
Regardless of whether the data was received correctly or
not, the UART automatically discards the Start, Parity and
Stop bits. If the sender and receiver are configured
identically, these bits are not passed to the host.
If another word is ready for transmission, the Start Bit
for the new word can be sent as soon as the Stop Bit for the
previous word has been sent.
Because asynchronous data is “self synchronizing”, if
there is no data to transmit, the transmission line can be
idle.
Other UART Functions
In addition to the basic job of converting data from
parallel to serial for transmission and from serial to
parallel on reception, a UART will usually provide additional
circuits for signals that can be used to indicate the state of
the transmission media, and to regulate the flow of data in
the event that the remote device is not prepared to accept
more data. For example, when the device connected to the
UART is a modem, the modem may report the presence of a
carrier on the phone line while the computer may be able to
instruct the modem to reset itself or to not take calls by
asserting or deasserting one more more of these extra signals.
The function of each of these additional signals is defined in
the EIA RS232-C standard.
The RS232-C and V.24 Standards
In most computer systems, the UART is connected to
circuitry that generates signals that comply with the EIA
RS232-C specification. There is also a CCITT standard named
V.24 that mirrors the specifications included in
RS232-C.
RS232-C Bit Assignments (Marks and Spaces)
In RS232-C, a value of 1 is called a Mark and a
value of 0 is called a Space. When a communication line
is idle, the line is said to be “Marking”, or transmitting
continuous 1 values.
The Start bit always has a value of 0 (a Space). The
Stop Bit always has a value of 1 (a Mark). This means
that there will always be a Mark (1) to Space (0) transition
on the line at the start of every word, even when multiple
word are transmitted back to back. This guarantees that
sender and receiver can resynchronize their clocks
regardless of the content of the data bits that are being
transmitted.
The idle time between Stop and Start bits does not have
to be an exact multiple (including zero) of the bit rate of
the communication link, but most UARTs are designed this way
for simplicity.
In RS232-C, the "Marking" signal (a 1) is represented
by a voltage between -2 VDC and -12 VDC, and a "Spacing"
signal (a 0) is represented by a voltage between 0 and +12
VDC. The transmitter is supposed to send +12 VDC or -12
VDC, and the receiver is supposed to allow for some voltage
loss in long cables. Some transmitters in low power devices
(like portable computers) sometimes use only +5 VDC and -5
VDC, but these values are still acceptable to a RS232-C
receiver, provided that the cable lengths are short.
RS232-C Break Signal
RS232-C also specifies a signal called a Break, which
is caused by sending continuous Spacing values (no Start or
Stop bits). When there is no electricity present on the
data circuit, the line is considered to be sending Break.
The Break signal must be of a duration longer than the
time it takes to send a complete byte plus Start, Stop and
Parity bits. Most UARTs can distinguish between a Framing
Error and a Break, but if the UART cannot do this, the
Framing Error detection can be used to identify
Breaks.
In the days of teleprinters, when numerous printers
around the country were wired in series (such as news
services), any unit could cause a Break by temporarily
opening the entire circuit so that no current flowed. This
was used to allow a location with urgent news to interrupt
some other location that was currently sending
information.
In modern systems there are two types of Break signals.
If the Break is longer than 1.6 seconds, it is considered a
"Modem Break", and some modems can be programmed to
terminate the conversation and go on-hook or enter the
modems' command mode when the modem detects this signal. If
the Break is smaller than 1.6 seconds, it signifies a Data
Break and it is up to the remote computer to respond to this
signal. Sometimes this form of Break is used as an
Attention or Interrupt signal and sometimes is accepted as a
substitute for the ASCII CONTROL-C character.
Marks and Spaces are also equivalent to “Holes” and “No
Holes” in paper tape systems.
Breaks cannot be generated from paper tape or from any
other byte value, since bytes are always sent with Start
and Stop bit. The UART is usually capable of generating
the continuous Spacing signal in response to a special
command from the host processor.
RS232-C DTE and DCE Devices
The RS232-C specification defines two types of
equipment: the Data Terminal Equipment (DTE) and the Data
Carrier Equipment (DCE). Usually, the DTE device is the
terminal (or computer), and the DCE is a modem. Across the
phone line at the other end of a conversation, the receiving
modem is also a DCE device and the computer that is
connected to that modem is a DTE device. The DCE device
receives signals on the pins that the DTE device transmits
on, and vice versa.
When two devices that are both DTE or both DCE must be
connected together without a modem or a similar media
translater between them, a NULL modem must be used. The
NULL modem electrically re-arranges the cabling so that the
transmitter output is connected to the receiver input on the
other device, and vice versa. Similar translations are
performed on all of the control signals so that each device
will see what it thinks are DCE (or DTE) signals from the
other device.
The number of signals generated by the DTE and DCE
devices are not symmetrical. The DTE device generates fewer
signals for the DCE device than the DTE device receives from
the DCE.
RS232-C Pin Assignments
The EIA RS232-C specification (and the ITU equivalent,
V.24) calls for a twenty-five pin connector (usually a DB25)
and defines the purpose of most of the pins in that
connector.
In the IBM Personal Computer and similar systems, a
subset of RS232-C signals are provided via nine pin
connectors (DB9). The signals that are not included on the
PC connector deal mainly with synchronous operation, and
this transmission mode is not supported by the UART that IBM
selected for use in the IBM PC.
Depending on the computer manufacturer, a DB25, a DB9,
or both types of connector may be used for RS232-C
communications. (The IBM PC also uses a DB25 connector for
the parallel printer interface which causes some
confusion.)
Below is a table of the RS232-C signal assignments in
the DB25 and DB9 connectors.
DB25 RS232-C Pin
DB9 IBM PC Pin
EIA Circuit Symbol
CCITT Circuit Symbol
Common Name
Signal Source
Description
1
-
AA
101
PG/FG
-
Frame/Protective Ground
2
3
BA
103
TD
DTE
Transmit Data
3
2
BB
104
RD
DCE
Receive Data
4
7
CA
105
RTS
DTE
Request to Send
5
8
CB
106
CTS
DCE
Clear to Send
6
6
CC
107
DSR
DCE
Data Set Ready
7
5
AV
102
SG/GND
-
Signal Ground
8
1
CF
109
DCD/CD
DCE
Data Carrier Detect
9
-
-
-
-
-
Reserved for Test
10
-
-
-
-
-
Reserved for Test
11
-
-
-
-
-
Reserved for Test
12
-
CI
122
SRLSD
DCE
Sec. Recv. Line Signal Detector
13
-
SCB
121
SCTS
DCE
Secondary Clear to Send
14
-
SBA
118
STD
DTE
Secondary Transmit Data
15
-
DB
114
TSET
DCE
Trans. Sig. Element Timing
16
-
SBB
119
SRD
DCE
Secondary Received Data
17
-
DD
115
RSET
DCE
Receiver Signal Element Timing
18
-
-
141
LOOP
DTE
Local Loopback
19
-
SCA
120
SRS
DTE
Secondary Request to Send
20
4
CD
108.2
DTR
DTE
Data Terminal Ready
21
-
-
-
RDL
DTE
Remote Digital Loopback
22
9
CE
125
RI
DCE
Ring Indicator
23
-
CH
111
DSRS
DTE
Data Signal Rate Selector
24
-
DA
113
TSET
DTE
Trans. Sig. Element Timing
25
-
-
142
-
DCE
Test Mode
Bits, Baud and Symbols
Baud is a measurement of transmission speed in
asynchronous communication. Because of advances in modem
communication technology, this term is frequently misused when
describing the data rates in newer devices.
Traditionally, a Baud Rate represents the number of bits
that are actually being sent over the media, not the amount of
data that is actually moved from one DTE device to the other.
The Baud count includes the overhead bits Start, Stop and
Parity that are generated by the sending UART and removed by
the receiving UART. This means that seven-bit words of data
actually take 10 bits to be completely transmitted. Therefore,
a modem capable of moving 300 bits per second from one place
to another can normally only move 30 7-bit words if Parity is
used and one Start and Stop bit are present.
If 8-bit data words are used and Parity bits are also
used, the data rate falls to 27.27 words per second, because
it now takes 11 bits to send the eight-bit words, and the
modem still only sends 300 bits per second.
The formula for converting bytes per second into a baud
rate and vice versa was simple until error-correcting modems
came along. These modems receive the serial stream of bits
from the UART in the host computer (even when internal modems
are used the data is still frequently serialized) and converts
the bits back into bytes. These bytes are then combined into
packets and sent over the phone line using a Synchronous
transmission method. This means that the Stop, Start, and
Parity bits added by the UART in the DTE (the computer) were
removed by the modem before transmission by the sending modem.
When these bytes are received by the remote modem, the remote
modem adds Start, Stop and Parity bits to the words, converts
them to a serial format and then sends them to the receiving
UART in the remote computer, who then strips the Start, Stop
and Parity bits.
The reason all these extra conversions are done is so that
the two modems can perform error correction, which means that
the receiving modem is able to ask the sending modem to resend
a block of data that was not received with the correct
checksum. This checking is handled by the modems, and the DTE
devices are usually unaware that the process is
occurring.
By striping the Start, Stop and Parity bits, the
additional bits of data that the two modems must share between
themselves to perform error-correction are mostly concealed
from the effective transmission rate seen by the sending and
receiving DTE equipment. For example, if a modem sends ten
7-bit words to another modem without including the Start, Stop
and Parity bits, the sending modem will be able to add 30 bits
of its own information that the receiving modem can use to do
error-correction without impacting the transmission speed of
the real data.
The use of the term Baud is further confused by modems
that perform compression. A single 8-bit word passed over the
telephone line might represent a dozen words that were
transmitted to the sending modem. The receiving modem will
expand the data back to its original content and pass that
data to the receiving DTE.
Modern modems also include buffers that allow the rate
that bits move across the phone line (DCE to DCE) to be a
different speed than the speed that the bits move between the
DTE and DCE on both ends of the conversation. Normally the
speed between the DTE and DCE is higher than the DCE to DCE
speed because of the use of compression by the modems.
Because the number of bits needed to describe a byte
varied during the trip between the two machines plus the
differing bits-per-seconds speeds that are used present on
the DTE-DCE and DCE-DCE links, the usage of the term Baud to
describe the overall communication speed causes problems and
can misrepresent the true transmission speed. So Bits Per
Second (bps) is the correct term to use to describe the
transmission rate seen at the DCE to DCE interface and Baud or
Bits Per Second are acceptable terms to use when a connection
is made between two systems with a wired connection, or if a
modem is in use that is not performing error-correction or
compression.
Modern high speed modems (2400, 9600, 14,400, and
19,200bps) in reality still operate at or below 2400 baud, or
more accurately, 2400 Symbols per second. High speed modem
are able to encode more bits of data into each Symbol using a
technique called Constellation Stuffing, which is why the
effective bits per second rate of the modem is higher, but the
modem continues to operate within the limited audio bandwidth
that the telephone system provides. Modems operating at 28,800
and higher speeds have variable Symbol rates, but the
technique is the same.
The IBM Personal Computer UART
Starting with the original IBM Personal Computer, IBM
selected the National Semiconductor INS8250 UART for use in
the IBM PC Parallel/Serial Adapter. Subsequent generations of
compatible computers from IBM and other vendors continued to
use the INS8250 or improved versions of the National
Semiconductor UART family.
National Semiconductor UART Family Tree
There have been several versions and subsequent
generations of the INS8250 UART. Each major version is
described below.
INS8250 -> INS8250B
\
\
\-> INS8250A -> INS82C50A
\
\
\-> NS16450 -> NS16C450
\
\
\-> NS16550 -> NS16550A -> PC16550D
INS8250
This part was used in the original IBM PC and
IBM PC/XT. The original name for this part was the
INS8250 ACE (Asynchronous Communications Element)
and it is made from NMOS technology.
The 8250 uses eight I/O ports and has a one-byte
send and a one-byte receive buffer. This original
UART has several race conditions and other flaws.
The original IBM BIOS includes code to work around
these flaws, but this made the BIOS dependent on the
flaws being present, so subsequent parts like the
8250A, 16450 or 16550 could not be used in the
original IBM PC or IBM PC/XT.
INS8250-B
This is the slower speed of the INS8250 made
from NMOS technology. It contains the same problems
as the original INS8250.
INS8250A
An improved version of the INS8250 using XMOS
technology with various functional flaws corrected.
The INS8250A was used initially in PC clone
computers by vendors who used “clean” BIOS designs.
Because of the corrections in the chip, this part
could not be used with a BIOS compatible with the
INS8250 or INS8250B.
INS82C50A
This is a CMOS version (low power consumption)
of the INS8250A and has similar functional
characteristics.
NS16450
Same as NS8250A with improvements so it can be
used with faster CPU bus designs. IBM used this
part in the IBM AT and updated the IBM BIOS to no
longer rely on the bugs in the INS8250.
NS16C450
This is a CMOS version (low power consumption)
of the NS16450.
NS16550
Same as NS16450 with a 16-byte send and receive
buffer but the buffer design was flawed and could
not be reliably be used.
NS16550A
Same as NS16550 with the buffer flaws corrected.
The 16550A and its successors have become the most
popular UART design in the PC industry, mainly due
it its ability to reliably handle higher data rates
on operating systems with sluggish interrupt
response times.
NS16C552
This component consists of two NS16C550A CMOS
UARTs in a single package.
PC16550D
Same as NS16550A with subtle flaws corrected.
This is revision D of the 16550 family and is the
latest design available from National Semiconductor.
The NS16550AF and the PC16550D are the same
thing
National reorganized their part numbering system a few
years ago, and the NS16550AFN no longer exists by that name.
(If you have a NS16550AFN, look at the date code on the
part, which is a four digit number that usually starts with
a nine. The first two digits of the number are the year,
and the last two digits are the week in that year when the
part was packaged. If you have a NS16550AFN, it is probably
a few years old.)
The new numbers are like PC16550DV, with minor
differences in the suffix letters depending on the package
material and its shape. (A description of the numbering
system can be found below.)
It is important to understand that in some stores, you
may pay $15(US) for a NS16550AFN made in 1990 and in the
next bin are the new PC16550DN parts with minor fixes that
National has made since the AFN part was in production, the
PC16550DN was probably made in the past six months and it
costs half (as low as $5(US) in volume) as much as the
NS16550AFN because they are readily available.
As the supply of NS16550AFN chips continues to shrink,
the price will probably continue to increase until more
people discover and accept that the PC16550DN really has the
same function as the old part number.
National Semiconductor Part Numbering System
The older NSnnnnnrqp part numbers
are now of the format
PCnnnnnrgp.
The r is the revision field. The
current revision of the 16550 from National Semiconductor is
D.
The p is the package-type field.
The types are:
"F"
QFP
(quad flat pack) L lead type
"N"
DIP
(dual inline package) through hole straight
lead type
"V"
LPCC
(lead plastic chip carrier) J lead type
The g is the product grade field.
If an I precedes the package-type letter, it indicates an
“industrial” grade part, which has higher specs than a
standard part but not as high as Military Specification
(Milspec) component. This is an optional field.
So what we used to call a NS16550AFN (DIP Package) is
now called a PC16550DN or PC16550DIN.
Other Vendors and Similar UARTs
Over the years, the 8250, 8250A, 16450 and 16550 have been
licensed or copied by other chip vendors. In the case of the
8250, 8250A and 16450, the exact circuit (the “megacell”) was
licensed to many vendors, including Western Digital and Intel.
Other vendors reverse-engineered the part or produced
emulations that had similar behavior.
In internal modems, the modem designer will frequently
emulate the 8250A/16450 with the modem microprocessor, and the
emulated UART will frequently have a hidden buffer consisting
of several hundred bytes. Because of the size of the buffer,
these emulations can be as reliable as a 16550A in their
ability to handle high speed data. However, most operating
systems will still report that the UART is only a 8250A or
16450, and may not make effective use of the extra buffering
present in the emulated UART unless special drivers are
used.
Some modem makers are driven by market forces to abandon a
design that has hundreds of bytes of buffer and instead use a
16550A UART so that the product will compare favorably in
market comparisons even though the effective performance may
be lowered by this action.
A common misconception is that all parts with “16550A”
written on them are identical in performance. There are
differences, and in some cases, outright flaws in most of
these 16550A clones.
When the NS16550 was developed, the National Semiconductor
obtained several patents on the design and they also limited
licensing, making it harder for other vendors to provide a
chip with similar features. Because of the patents,
reverse-engineered designs and emulations had to avoid
infringing the claims covered by the patents. Subsequently,
these copies almost never perform exactly the same as the
NS16550A or PC16550D, which are the parts most computer and
modem makers want to buy but are sometimes unwilling to pay
the price required to get the genuine part.
Some of the differences in the clone 16550A parts are
unimportant, while others can prevent the device from being
used at all with a given operating system or driver. These
differences may show up when using other drivers, or when
particular combinations of events occur that were not well
tested or considered in the Windows driver. This is because
most modem vendors and 16550-clone makers use the Microsoft
drivers from Windows for Workgroups 3.11 and the Microsoft MSD
utility as the primary tests for compatibility with the
NS16550A. This over-simplistic criteria means that if a
different operating system is used, problems could appear due
to subtle differences between the clones and genuine
components.
National Semiconductor has made available a program named
COMTEST that performs compatibility tests independent of any
OS drivers. It should be remembered that the purpose of this
type of program is to demonstrate the flaws in the products of
the competition, so the program will report major as well as
extremely subtle differences in behavior in the part being
tested.
In a series of tests performed by the author of this
document in 1994, components made by National Semiconductor,
TI, StarTech, and CMD as well as megacells and emulations
embedded in internal modems were tested with COMTEST. A
difference count for some of these components is listed below.
Because these tests were performed in 1994, they may not
reflect the current performance of the given product from a
vendor.
It should be noted that COMTEST normally aborts when an
excessive number or certain types of problems have been
detected. As part of this testing, COMTEST was modified so
that it would not abort no matter how many differences were
encountered.
Vendor
Part Number
Errors (aka "differences" reported)
National
(PC16550DV)
- 0
- To date, the author of this document has not
- found any non-National parts that report zero
- differences using the COMTEST program. It should
- also be noted that National has had five versions
- of the 16550 over the years and the newest parts
- behave a bit differently than the classic
- NS16550AFN that is considered the benchmark for
- functionality. COMTEST appears to turn a blind eye
- to the differences within the National product
- line and reports no errors on the National parts
- (except for the original 16550) even when there
- are official erratas that describe bugs in the A,
- B and C revisions of the parts, so this bias in
- COMTEST must be taken into account.
-
-
+ 0
National
(NS16550AFN)
0
National
(NS16C552V)
0
TI
(TL16550AFN)
3
CMD
(16C550PE)
19
StarTech
(ST16C550J)
23
Rockwell
Reference modem with internal 16550 or an
emulation (RC144DPi/C3000-25)
117
Sierra
Modem with an internal 16550
(SC11951/SC11351)
91
+
+
+ To date, the author of this document has not
+ found any non-National parts that report zero
+ differences using the COMTEST program. It should
+ also be noted that National has had five versions
+ of the 16550 over the years and the newest parts
+ behave a bit differently than the classic
+ NS16550AFN that is considered the benchmark for
+ functionality. COMTEST appears to turn a blind eye
+ to the differences within the National product
+ line and reports no errors on the National parts
+ (except for the original 16550) even when there
+ are official erratas that describe bugs in the A,
+ B and C revisions of the parts, so this bias in
+ COMTEST must be taken into account.
+
It is important to understand that a simple count of
differences from COMTEST does not reveal a lot about what
differences are important and which are not. For example,
about half of the differences reported in the two modems
listed above that have internal UARTs were caused by the clone
UARTs not supporting five- and six-bit character modes. The
real 16550, 16450, and 8250 UARTs all support these modes and
COMTEST checks the functionality of these modes so over fifty
differences are reported. However, almost no modern modem
supports five- or six-bit characters, particularly those with
error-correction and compression capabilities. This means
that the differences related to five- and six-bit character
modes can be discounted.
Many of the differences COMTEST reports have to do with
timing. In many of the clone designs, when the host reads
from one port, the status bits in some other port may not
update in the same amount of time (some faster, some slower)
as a real NS16550AFN and COMTEST looks
for these differences. This means that the number of
differences can be misleading in that one device may only have
one or two differences but they are extremely serious, and
some other device that updates the status registers faster or
slower than the reference part (that would probably never
affect the operation of a properly written driver) could have
dozens of differences reported.
COMTEST can be used as a screening tool to alert the
administrator to the presence of potentially incompatible
components that might cause problems or have to be handled as
a special case.
If you run COMTEST on a 16550 that is in a modem or a
modem is attached to the serial port, you need to first issue
a ATE0&W command to the modem so that the modem will not
echo any of the test characters. If you forget to do this,
COMTEST will report at least this one difference:
Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61
8250/16450/16550 Registers
The 8250/16450/16550 UART occupies eight contiguous I/O
port addresses. In the IBM PC, there are two defined
locations for these eight ports and they are known
collectively as COM1 and COM2. The makers of PC-clones and
add-on cards have created two additional areas known as COM3
and COM4, but these extra COM ports conflict with other
hardware on some systems. The most common conflict is with
video adapters that provide IBM 8514 emulation.
COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ
4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3
COM3 is located from 0x3e8 to 0x3ef and has no standardized
IRQ COM4 is located from 0x2e8 to 0x2ef and has no
standardized IRQ.
A description of the I/O ports of the 8250/16450/16550
UART is provided below.
I/O Port
Access Allowed
Description
+0x00
write (DLAB==0)
Transmit Holding Register (THR).Information written to this port are treated as
data words and will be transmitted by the
UART.
+0x00
read (DLAB==0)
Receive Buffer Register (RBR).Any data words received by the UART form the
serial link are accessed by the host by reading this
port.
+0x00
write/read (DLAB==1)
Divisor Latch LSB (DLL)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 0 thru 7 of the
divisor.
+0x01
write/read (DLAB==1)
Divisor Latch MSB (DLH)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 8 thru 15 of the
divisor.
+0x01
write/read (DLAB==0)
Interrupt Enable
Register (IER)The 8250/16450/16550 UART classifies
events into one of four categories. Each
category can be configured to generate an
interrupt when any of the events occurs. The
8250/16450/16550 UART generates a single
external interrupt signal regardless of how
many events in the enabled categories have
occurred. It is up to the host processor to
respond to the interrupt and then poll the
enabled interrupt categories (usually all
categories have interrupts enabled) to
determine the true cause(s) of the
interrupt.
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Enable Modem Status Interrupt (EDSSI).
Setting this bit to "1" allows the UART to
generate an interrupt when a change occurs
on one or more of the status lines.
Bit 2
Enable Receiver Line Status Interrupt (ELSI)
Setting this bit to "1" causes the UART to
generate an interrupt when the an error
(or a BREAK signal) has been detected in
the incoming data.
Bit 1
Enable Transmitter Holding Register Empty
Interrupt (ETBEI) Setting this bit to "1"
causes the UART to generate an interrupt
when the UART has room for one or more
additional characters that are to be
transmitted.
Bit 0
Enable Received Data Available Interrupt
(ERBFI) Setting this bit to "1" causes the
UART to generate an interrupt when the
UART has received enough characters to
exceed the trigger level of the FIFO, or
the FIFO timer has expired (stale data),
or a single character has been received
when the FIFO is disabled.
+0x02
write
FIFO Control Register (FCR)
(This port does not exist on the 8250 and 16450
UART.)
Bit 7
Receiver Trigger Bit
#1
Bit 6
Receiver Trigger Bit
#0These two bits control at what
point the receiver is to generate an interrupt
when the FIFO is active.
7
6
How many words are received
before an interrupt is generated
0
0
1
0
1
4
1
0
8
1
1
14
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
DMA Mode Select. If Bit 0
is set to "1" (FIFOs enabled), setting this bit
changes the operation of the -RXRDY and -TXRDY
signals from Mode 0 to Mode 1.
Bit 2
Transmit FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
transmitted will be sent intact. This function
is useful in aborting transfers.
Bit 1
Receiver FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
assembled in the shift register will be received
intact.
Bit 0
16550 FIFO Enable. When
set, both the transmit and receive FIFOs are
enabled. Any contents in the holding register,
shift registers or FIFOs are lost when FIFOs are
enabled or disabled.
+0x02
read
Interrupt Identification
Register
Bit 7
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 6
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Interrupt ID Bit #2. On the
8250/16450 UART, this bit is zero.
Bit 2
Interrupt ID Bit #1
Bit 1
Interrupt ID Bit #0.These
three bits combine to report the category of
event that caused the interrupt that is in
progress. These categories have priorities, so
if multiple categories of events occur at the
same time, the UART will report the more
important events first and the host must resolve
the events in the order they are reported. All
events that caused the current interrupt must be
resolved before any new interrupts will be
generated. (This is a limitation of the PC
architecture.)
2
1
0
Priority
Description
0
1
1
First
Received Error (OE, PE, BI,
or FE)
0
1
0
Second
Received Data
Available
1
1
0
Second
Trigger level identification
(Stale data in receive buffer)
0
0
1
Third
Transmitter has room for
more words (THRE)
0
0
0
Fourth
Modem Status Change (-CTS,
-DSR, -RI, or -DCD)
Bit 0
Interrupt Pending Bit. If
this bit is set to "0", then at least one
interrupt is pending.
+0x03
write/read
Line Control
Register (LCR)
Bit 7
Divisor Latch Access Bit
(DLAB). When set, access to the data
transmit/receive register (THR/RBR) and the
Interrupt Enable Register (IER) is disabled. Any
access to these ports is now redirected to the
Divisor Latch Registers. Setting this bit,
loading the Divisor Registers, and clearing DLAB
should be done with interrupts disabled.
Bit 6
Set Break. When set to "1",
the transmitter begins to transmit continuous
Spacing until this bit is set to "0". This
overrides any bits of characters that are being
transmitted.
Bit 5
Stick Parity. When parity
is enabled, setting this bit causes parity to
always be "1" or "0", based on the value of Bit
4.
Bit 4
Even Parity Select (EPS).
When parity is enabled and Bit 5 is "0", setting
this bit causes even parity to be transmitted
and expected. Otherwise, odd parity is
used.
Bit 3
Parity Enable (PEN). When
set to "1", a parity bit is inserted between the
last bit of the data and the Stop Bit. The UART
will also expect parity to be present in the
received data.
Bit 2
Number of Stop Bits (STB).
If set to "1" and using 5-bit data words, 1.5
Stop Bits are transmitted and expected in each
data word. For 6, 7 and 8-bit data words, 2
Stop Bits are transmitted and expected. When
this bit is set to "0", one Stop Bit is used on
each data word.
Bit 1
Word Length Select Bit #1
(WLSB1)
Bit 0
Word Length Select Bit #0
(WLSB0)
Together
these bits specify the number of bits in each
data word.
1
0
Word
Length
0
0
5 Data
Bits
0
1
6 Data
Bits
1
0
7 Data
Bits
1
1
8 Data
Bits
+0x04
write/read
Modem Control Register
(MCR)
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Loop-Back Enable. When set to "1", the UART
transmitter and receiver are internally
connected together to allow diagnostic
operations. In addition, the UART modem control
outputs are connected to the UART modem control
inputs. CTS is connected to RTS, DTR is
connected to DSR, OUT1 is connected to RI, and
OUT 2 is connected to DCD.
Bit 3
OUT 2. An auxiliary output that the host
processor may set high or low. In the IBM PC
serial adapter (and most clones), OUT 2 is used
to tri-state (disable) the interrupt signal from
the 8250/16450/16550 UART.
Bit 2
OUT 1. An auxiliary output that the host
processor may set high or low. This output is
not used on the IBM PC serial adapter.
Bit 1
Request to Send (RTS). When set to "1", the
output of the UART -RTS line is Low
(Active).
Bit 0
Data Terminal Ready (DTR). When set to "1",
the output of the UART -DTR line is Low
(Active).
+0x05
write/read
Line Status Register
(LSR)
Bit 7
Error in Receiver FIFO. On the 8250/16450
UART, this bit is zero. This bit is set to "1"
when any of the bytes in the FIFO have one or
more of the following error conditions: PE, FE,
or BI.
Bit 6
Transmitter Empty (TEMT). When set to "1",
there are no words remaining in the transmit
FIFO or the transmit shift register. The
transmitter is completely idle.
Bit 5
Transmitter Holding Register Empty
(THRE). When set to "1", the FIFO (or holding
register) now has room for at least one
additional word to transmit. The transmitter may
still be transmitting when this bit is set to
"1".
Bit 4
Break Interrupt (BI). The receiver has
detected a Break signal.
Bit 3
Framing Error (FE). A Start Bit was
detected but the Stop Bit did not appear at the
expected time. The received word is probably
garbled.
Bit 2
Parity Error (PE). The parity bit was
incorrect for the word received.
Bit 1
Overrun Error (OE). A new word was received
and therewas no room in the receive buffer. The
newly-arrived word in the shift register is
discarded. On 8250/16450 UARTs, the word in the
holding register is discarded and the newly-
arrived word is put in the holding
register.
Bit 0
Data Ready (DR) One or more words are in
the receive FIFO that the host may read. A word
must be completely received and moved from the
shift register into the FIFO (or holding
register for 8250/16450 designs) before this bit
is set.
+0x06
write/read
Modem Status Register
(MSR)
Bit 7
Data Carrier Detect (DCD). Reflects the
state of the DCD line on the UART.
Bit 6
Ring Indicator (RI). Reflects the state of
the RI line on the UART.
Bit 5
Data Set Ready (DSR). Reflects the state of
the DSR line on the UART.
Bit 4
Clear To Send (CTS). Reflects the state of
the CTS line on the UART.
Bit 3
Delta Data Carrier Detect (DDCD). Set to
"1" if the -DCD line has changed state one more
more times since the last time the MSR was read
by the host.
Bit 2
Trailing Edge Ring Indicator (TERI). Set to
"1" if the -RI line has had a low to high
transition since the last time the MSR was read
by the host.
Bit 1
Delta Data Set Ready (DDSR). Set to "1" if
the -DSR line has changed state one more more
times since the last time the MSR was read by
the host.
Bit 0
Delta Clear To Send (DCTS). Set to "1" if
the -CTS line has changed state one more more
times since the last time the MSR was read by
the host.
+0x07
write/read
Scratch Register (SCR). This register performs no
function in the UART. Any value can be written by the
host to this location and read by the host later
on.
Beyond the 16550A UART
Although National Semiconductor has not offered any
components compatible with the 16550 that provide additional
features, various other vendors have. Some of these
components are described below. It should be understood that
to effectively utilize these improvements, drivers may have to
be provided by the chip vendor since most of the popular
operating systems do not support features beyond those
provided by the 16550.
ST16650
By default this part is similar to the NS16550A,
but an extended 32-byte send and receive buffer can be
optionally enabled. Made by Startech.
TIL16660
By default this part behaves similar to the
NS16550A, but an extended 64-byte send and receive
buffer can be optionally enabled. Made by Texas
Instruments.
Hayes ESP
This proprietary plug-in card contains a 2048-byte
send and receive buffer, and supports data rates to
230.4Kbit/sec. Made by Hayes.
In addition to these “dumb” UARTs, many vendors produce
intelligent serial communication boards. This type of design
usually provides a microprocessor that interfaces with several
UARTs, processes and buffers the data, and then alerts the
main PC processor when necessary. Because the UARTs are not
directly accessed by the PC processor in this type of
communication system, it is not necessary for the vendor to
use UARTs that are compatible with the 8250, 16450, or the
16550 UART. This leaves the designer free to components that
may have better performance characteristics.
Configuring the <devicename>sio</devicename>
driver
The sio driver provides
support for NS8250-, NS16450-, NS16550 and NS16550A-based EIA
RS-232C (CCITT V.24) communications interfaces. Several
multiport cards are supported as well. See the sio4 manual page for detailed technical
documentation.
Digi International (DigiBoard) PC/8
Contributed by &a.awebster;.26
August 1995.
Here is a config snippet from a machine with a Digi
International PC/8 with 16550. It has 8 modems connected to
these 8 lines, and they work just great. Do not forget to add
options COM_MULTIPORT or it will
not work very well!
device sio4 at isa? port 0x100 tty flags 0xb05
device sio5 at isa? port 0x108 tty flags 0xb05
device sio6 at isa? port 0x110 tty flags 0xb05
device sio7 at isa? port 0x118 tty flags 0xb05
device sio8 at isa? port 0x120 tty flags 0xb05
device sio9 at isa? port 0x128 tty flags 0xb05
device sio10 at isa? port 0x130 tty flags 0xb05
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
The trick in setting this up is that the MSB of the flags
represent the last SIO port, in this case 11 so flags are
0xb05.
Boca 16
Contributed by &a.whiteside;.26
August 1995.
The procedures to make a Boca 16 pord board with FreeBSD
are pretty straightforward, but you will need a couple things
to make it work:
You either need the kernel sources installed so you
can recompile the necessary options or you will need
someone else to compile it for you. The 2.0.5 default
kernel does not come with
multiport support enabled and you will need to add a
device entry for each port anyways.
Two, you will need to know the interrupt and IO
setting for your Boca Board so you can set these options
properly in the kernel.
One important note — the actual UART chips for the Boca 16
are in the connector box, not on the internal board itself. So
if you have it unplugged, probes of those ports will fail. I
have never tested booting with the box unplugged and plugging
it back in, and I suggest you do not either.
If you do not already have a custom kernel configuration
file set up, refer to Kernel Configuration for
general procedures. The following are the specifics for the
Boca 16 board and assume you are using the kernel name
MYKERNEL and editing with vi.
Add the line
options COM_MULTIPORT
to the config file.
Where the current device
sion lines are,
you will need to add 16 more devices. Only
the last device includes the interrupt vector for the
board. (See the sio4 manual page for detail as
to why.) The following example is for a Boca Board with
an interrupt of 3, and a base IO address 100h. The IO
address for Each port is +8 hexadecimal from the
previous port, thus the 100h, 108h, 110h... addresses.
device sio1 at isa? port 0x100 tty flags 0x1005
device sio2 at isa? port 0x108 tty flags 0x1005
device sio3 at isa? port 0x110 tty flags 0x1005
device sio4 at isa? port 0x118 tty flags 0x1005
…
device sio15 at isa? port 0x170 tty flags 0x1005
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
The flags entry
must be changed from this example
unless you are using the exact same sio assignments.
Flags are set according to 0xMYY
where M indicates the minor number
of the master port (the last port on a Boca 16) and
YY indicates if FIFO is enabled or
disabled(enabled), IRQ sharing is used(yes) and if there
is an AST/4 compatible IRQ control register(no). In this
example,
flags 0x1005 indicates that the master port is
sio16. If I added another board and assigned sio17
through sio28, the flags for all 16 ports on
that board would be 0x1C05, where
1C indicates the minor number of the master port. Do not
change the 05 setting.
Save and complete the kernel configuration,
recompile, install and reboot. Presuming you have
successfully installed the recompiled kernel and have it
set to the correct address and IRQ, your boot message
should indicate the successful probe of the Boca ports
as follows: (obviously the sio numbers, IO and IRQ could
be different)
sio1 at 0x100-0x107 flags 0x1005 on isa
sio1: type 16550A (multiport)
sio2 at 0x108-0x10f flags 0x1005 on isa
sio2: type 16550A (multiport)
sio3 at 0x110-0x117 flags 0x1005 on isa
sio3: type 16550A (multiport)
sio4 at 0x118-0x11f flags 0x1005 on isa
sio4: type 16550A (multiport)
sio5 at 0x120-0x127 flags 0x1005 on isa
sio5: type 16550A (multiport)
sio6 at 0x128-0x12f flags 0x1005 on isa
sio6: type 16550A (multiport)
sio7 at 0x130-0x137 flags 0x1005 on isa
sio7: type 16550A (multiport)
sio8 at 0x138-0x13f flags 0x1005 on isa
sio8: type 16550A (multiport)
sio9 at 0x140-0x147 flags 0x1005 on isa
sio9: type 16550A (multiport)
sio10 at 0x148-0x14f flags 0x1005 on isa
sio10: type 16550A (multiport)
sio11 at 0x150-0x157 flags 0x1005 on isa
sio11: type 16550A (multiport)
sio12 at 0x158-0x15f flags 0x1005 on isa
sio12: type 16550A (multiport)
sio13 at 0x160-0x167 flags 0x1005 on isa
sio13: type 16550A (multiport)
sio14 at 0x168-0x16f flags 0x1005 on isa
sio14: type 16550A (multiport)
sio15 at 0x170-0x177 flags 0x1005 on isa
sio15: type 16550A (multiport)
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
sio16: type 16550A (multiport master)
If the messages go by too fast to
see,
&prompt.root; dmesg | more
will
show you the boot messages.
Next, appropriate entries in
/dev for the devices must be made
using the /dev/MAKEDEV script.
After becoming root:
&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tty1
&prompt.root; ./MAKEDEV cua1
(everything in between)
&prompt.root; ./MAKEDEV ttyg
&prompt.root; ./MAKEDEV cuag
If you do not want or need callout
devices for some reason, you can dispense with making
the cua* devices.
If you want a quick and sloppy way to make sure the
devices are working, you can simply plug a modem into
each port and (as root)
&prompt.root; echo at > ttyd*
for each device you have made. You
should see the RX lights flash for
each working port.
Configuring the <devicename>cy</devicename>
driver
Contributed by &a.alex;.6 June
1996.
The Cyclades multiport cards are based on the
cy driver instead of the usual
sio driver used by other multiport
cards. Configuration is a simple matter of:
Add the cy device to
your kernel
configuration (note that your irq and
iomem settings may differ).
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
Rebuild
and install the new kernel.
Make the device
nodes by typing (the following example
assumes an 8-port board):
&prompt.root; cd /dev
&prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
If appropriate, add dialup
entries to /etc/ttys
by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example:
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
…
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
Reboot with the new kernel.
* Parallel ports
* Modems
* Network cards
* Keyboards
* Mice
* Other
Storage Devices
Using ESDI hard disks
Copyright © 1995, &a.wilko;.24
September 1995.
ESDI is an acronym that means Enhanced Small Device Interface.
It is loosely based on the good old ST506/412 interface originally
devised by Seagate Technology, the makers of the first affordable
5.25" winchester disk.
The acronym says Enhanced, and rightly so. In the first place
the speed of the interface is higher, 10 or 15 Mbits/second
instead of the 5 Mbits/second of ST412 interfaced drives. Secondly
some higher level commands are added, making the ESDI interface
somewhat 'smarter' to the operating system driver writers. It is
by no means as smart as SCSI by the way. ESDI is standardized by
ANSI.
Capacities of the drives are boosted by putting more sectors
on each track. Typical is 35 sectors per track, high capacity
drives I have seen were up to 54 sectors/track.
Although ESDI has been largely obsoleted by IDE and SCSI
interfaces, the availability of free or cheap surplus drives makes
them ideal for low (or now) budget systems.
Concepts of ESDI
Physical connections
The ESDI interface uses two cables connected to each
drive. One cable is a 34 pin flat cable edge connector that
carries the command and status signals from the controller to
the drive and vice-versa. The command cable is daisy chained
between all the drives. So, it forms a bus onto which all
drives are connected.
The second cable is a 20 pin flat cable edge connector
that carries the data to and from the drive. This cable is
radially connected, so each drive has its own direct
connection to the controller.
To the best of my knowledge PC ESDI controllers are
limited to using a maximum of 2 drives per controller. This is
compatibility feature(?) left over from the WD1003 standard
that reserves only a single bit for device addressing.
Device addressing
On each command cable a maximum of 7 devices and 1
controller can be present. To enable the controller to
uniquely identify which drive it addresses, each ESDI device
is equipped with jumpers or switches to select the devices
address.
On PC type controllers the first drive is set to address
0, the second disk to address 1. Always
make sure you set each disk to an unique address!
So, on a PC with its two drives/controller maximum the first
drive is drive 0, the second is drive 1.
Termination
The daisy chained command cable (the 34 pin cable
remember?) needs to be terminated at the last drive on the
chain. For this purpose ESDI drives come with a termination
resistor network that can be removed or disabled by a jumper
when it is not used.
So, one and only one drive,
the one at the farthest end of the command cable has its
terminator installed/enabled. The controller automatically
terminates the other end of the cable. Please note that this
implies that the controller must be at one end of the cable
and not in the middle.
Using ESDI disks with FreeBSD
Why is ESDI such a pain to get working in the first
place?
People who tried ESDI disks with FreeBSD are known to have
developed a profound sense of frustration. A combination of
factors works against you to produce effects that are hard to
understand when you have never seen them before.
This has also led to the popular legend ESDI and FreeBSD is
a plain NO-GO. The following sections try to list all the
pitfalls and solutions.
ESDI speed variants
As briefly mentioned before, ESDI comes in two speed
flavors. The older drives and controllers use a 10
Mbits/second data transfer rate. Newer stuff uses 15
Mbits/second.
It is not hard to imagine that 15 Mbits/second drive cause
problems on controllers laid out for 10 Mbits/second. As
always, consult your controller and drive documentation to see if
things match.
Stay on track
Mainstream ESDI drives use 34 to 36 sectors per track.
Most (older) controllers cannot handle more than this number
of sectors. Newer, higher capacity, drives use higher numbers
of sectors per track. For instance, I own a 670 Mb drive that
has 54 sectors per track.
In my case, the controller could not handle this number of
sectors. It proved to work well except that it only used 35
sectors on each track. This meant losing a lot of disk
space.
Once again, check the documentation of your hardware for
more info. Going out-of-spec like in the example might or
might not work. Give it a try or get another more capable
controller.
Hard or soft sectoring
Most ESDI drives allow hard or soft sectoring to be
selected using a jumper. Hard sectoring means that the drive
will produce a sector pulse on the start of each new sector.
The controller uses this pulse to tell when it should start to
write or read.
Hard sectoring allows a selection of sector size (normally
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
512 byte sectors. The number of sectors per track also varies
while still using the same number of bytes per formatted
sector. The number of unformatted bytes
per sector varies, dependent on your controller it needs more
or less overhead bytes to work correctly. Pushing more
sectors on a track of course gives you more usable space, but
might give problems if your controller needs more bytes than
the drive offers.
In case of soft sectoring, the controller itself
determines where to start/stop reading or writing. For ESDI
hard sectoring is the default (at least on everything I came
across). I never felt the urge to try soft sectoring.
In general, experiment with sector settings before you
install FreeBSD because you need to re-run the low-level
format after each change.
Low level formatting
ESDI drives need to be low level formatted before they are
usable. A reformat is needed whenever you figgle with the
number of sectors/track jumpers or the physical orientation of
the drive (horizontal, vertical). So, first think, then
format. The format time must not be underestimated, for big
disks it can take hours.
After a low level format, a surface scan is done to find
and flag bad sectors. Most disks have a manufacturer bad block
list listed on a piece of paper or adhesive sticker. In
addition, on most disks the list is also written onto the
disk. Please use the manufacturer's list. It is much easier to
remap a defect now than after FreeBSD is installed.
Stay away from low-level formatters that mark all sectors
of a track as bad as soon as they find one bad sector. Not
only does this waste space, it also and more importantly
causes you grief with bad144 (see the section on
bad144).
Translations
Translations, although not exclusively a ESDI-only
problem, might give you real trouble. Translations come in
multiple flavors. Most of them have in common that they
attempt to work around the limitations posed upon disk
geometries by the original IBM PC/AT design (thanks
IBM!).
First of all there is the (in)famous 1024 cylinder limit.
For a system to be able to boot, the stuff (whatever
operating system) must be in the first 1024 cylinders of a
disk. Only 10 bits are available to encode the cylinder
number. For the number of sectors the limit is 64 (0-63). When
you combine the 1024 cylinder limit with the 16 head limit
(also a design feature) you max out at fairly limited disk
sizes.
To work around this problem, the manufacturers of ESDI PC
controllers added a BIOS prom extension on their boards. This
BIOS extension handles disk I/O for booting (and for some
operating systems all disk I/O)
by using translation. For instance, a big drive might be
presented to the system as having 32 heads and 64
sectors/track. The result is that the number of cylinders is
reduced to something below 1024 and is therefore usable by the
system without problems. It is noteworthy to know that FreeBSD
does not use the BIOS after its kernel has started. More on
this later.
A second reason for translations is the fact that most
older system BIOSes could only handle drives with 17 sectors
per track (the old ST412 standard). Newer system BIOSes
usually have a user-defined drive type (in most cases this is
drive type 47).
Whatever you do to translations after reading
this document, keep in mind that if you have multiple
operating systems on the same disk, all must use the same
translation
While on the subject of translations, I have seen one
controller type (but there are probably more like this) offer
the option to logically split a drive in multiple partitions
as a BIOS option. I had select 1 drive == 1 partition because
this controller wrote this info onto the disk. On power-up it
read the info and presented itself to the system based on the
info from the disk.
Spare sectoring
Most ESDI controllers offer the possibility to remap bad
sectors. During/after the low-level format of the disk bad
sectors are marked as such, and a replacement sector is put in
place (logically of course) of the bad one.
In most cases the remapping is done by using N-1 sectors
on each track for actual data storage, and sector N itself is
the spare sector. N is the total number of sectors physically
available on the track. The idea behind this is that the
operating system sees a 'perfect' disk without bad sectors. In
the case of FreeBSD this concept is not usable.
The problem is that the translation from bad to good is performed by the BIOS of the
ESDI controller. FreeBSD, being a true 32 bit operating
system, does not use the BIOS after it has been booted.
Instead, it has device drivers that talk directly to the
hardware.
So: don't use spare sectoring, bad block
remapping or whatever it may be called by the controller
manufacturer when you want to use the disk for
FreeBSD.
Bad block handling
The preceding section leaves us with a problem. The
controller's bad block handling is not usable and still
FreeBSD's filesystems assume perfect media without any flaws.
To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a
Digital Equipment standard for bad block handling) scans a
FreeBSD slice for bad blocks. Having found these bad blocks,
it writes a table with the offending block numbers to the end
of the FreeBSD slice.
When the disk is in operation, the disk accesses are
checked against the table read from the disk. Whenever a
block number is requested that is in the bad144 list, a
replacement block (also from the end of the FreeBSD slice) is
used. In this way, the bad144 replacement scheme presents
'perfect' media to the FreeBSD filesystems.
There are a number of potential pitfalls associated with
the use of bad144. First of all, the slice cannot have more
than 126 bad sectors. If your drive has a high number of bad
sectors, you might need to divide it into multiple FreeBSD
slices each containing less than 126 bad sectors. Stay away
from low-level format programs that mark
every sector of a track as bad when they
find a flaw on the track. As you can imagine, the 126 limit
is quickly reached when the low-level format is done this
way.
Second, if the slice contains the root filesystem, the
slice should be within the 1024 cylinder BIOS limit. During
the boot process the bad144 list is read using the BIOS and
this only succeeds when the list is within the 1024 cylinder
limit.
The restriction is not that only the root
filesystem must be within the 1024
cylinder limit, but rather the entire
slice that contains the root
filesystem.
Kernel configuration
ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The
wd driver should work for all
WD1003 compatible interfaces.
Most hardware is jumperable for one of two different I/O
address ranges and IRQ lines. This allows you to have two wd
type controllers in one system.
When your hardware allows non-standard strappings, you can
use these with FreeBSD as long as you enter the correct info
into the kernel config file. An example from the kernel config
file (they live in /sys/i386/conf
BTW).
# First WD compatible controller
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
disk wd0 at wdc0 drive 0
disk wd1 at wdc0 drive 1
# Second WD compatible controller
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
disk wd2 at wdc1 drive 0
disk wd3 at wdc1 drive 1
Particulars on ESDI hardware
Adaptec 2320 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a ACB-2320. No other operating system was
present on the disk.
To do so I low level formatted the disk using NEFMT.EXE
(ftpable from
www.adaptec.com) and answered NO to the
question whether the disk should be formatted with a spare
sector on each track. The BIOS on the ACD-2320 was disabled. I
used the free configurable option in the system BIOS to
allow the BIOS to boot it.
Before using NEFMT.EXE I tried to format the disk using
the ACB-2320 BIOS builtin formatter. This proved to be a show
stopper, because it did not give me an option to disable spare
sectoring. With spare sectoring enabled the FreeBSD
installation process broke down on the bad144 run.
Please check carefully which ACB-232xy variant you have.
The x is either 0 or 2, indicating a controller without or
with a floppy controller on board.
The y is more interesting. It can either be a blank, a
A-8 or a D. A blank indicates a plain 10 Mbits/second
controller. An A-8 indicates a 15 Mbits/second controller
capable of handling 52 sectors/track. A D means a 15
Mbits/second controller that can also handle drives with >
36 sectors/track (also 52 ?).
All variations should be capable of using 1:1
interleaving. Use 1:1, FreeBSD is fast enough to handle
it.
Western Digital WD1007 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a WD1007 controller. To be precise, it was a
WD1007-WA2. Other variations of the WD1007 do exist.
To get it to work, I had to disable the sector translation
and the WD1007's onboard BIOS. This implied I could not use
the low-level formatter built into this BIOS. Instead, I
grabbed WDFMT.EXE from www.wdc.com Running this formatted my
drive just fine.
Ultrastor U14F controllers
According to multiple reports from the net, Ultrastor ESDI
boards work OK with FreeBSD. I lack any further info on
particular settings.
Further reading
If you intend to do some serious ESDI hacking, you might
want to have the official standard at hand:
The latest ANSI X3T10 committee document is:
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11]
On Usenet the newsgroup comp.periphs is a noteworthy
place to look for more info.
The World Wide Web (WWW) also proves to be a very handy info
source: For info on Adaptec ESDI controllers see http://www.adaptec.com/.
For info on Western Digital controllers see http://www.wdc.com/.
Thanks to...
Andrew Gordon for sending me an Adaptec 2320 controller and
ESDI disk for testing.
What is SCSI?
Copyright © 1995, &a.wilko;.July
6, 1996.
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 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 million transfers per second
(20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers
per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold
today are single-ended Ultra SCSI (8 or 16 bits).
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.
Components of SCSI
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.
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.
SCSI bus types
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:
FWD: Fast Wide Differential
FND: Fast Narrow Differential
SE: Single Ended
FN: Fast Narrow
etc.
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 million transfers/second are also
emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI).
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.
Single ended buses
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
million transfers/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.
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 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.
Differential buses
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.
Terminators
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. Many SCSI devices come 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 not mix 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: every
single line on the SCSI bus has 2 (two) terminators, one at
each end of the bus. 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. (Note the
“potential” here; the nastiest part is that it may or may not
work.)
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.
Termination is to be done on a per-line basis. This
means if you have both narrow and wide buses connected to
the same host adapter, you need to enable termination on the
higher 8 bits of the bus on the adapter (as well as the last
devices on each bus, of course).
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 are software
configurable, using some sort of setup tool. Some will even
auto-detect the cables attached to the connectors and
automatically set up the termination as necessary. At any
rate, consult your documentation!
Terminator power
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.
Device addressing
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. Some SCSI host adapters let you change
the target ID from the boot menu. (Yet some others will not
let you change the ID from 7.) 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 (usually 16).
A narrow SCSI device can not communicate with a SCSI
device with a target ID larger than 7. This means it is
generally not a good idea to move your SCSI host adapter's
target ID to something higher than 7 (or your CD-ROM will
stop working).
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. Note however that the
lower 8 IDs have higher priorities than the higher 8 IDs on a
wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI
system. (If you you are wondering why the lower 8 have higher
priority, read the previous paragraph for a hint.)
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.
Bus layout
SCSI buses are linear. So, not shaped like Y-junctions,
star topologies, rings, cobwebs or whatever else people might
want to invent. One of the most common mistakes is for people
with wide-SCSI host adapters to connect devices on all three
connecters (external connector, internal wide connector,
internal narrow connector). Don't do that. It may appear to
work if you are really lucky, but I can almost guarantee that
your system will stop functioning at the most unfortunate
moment (this is also known as “Murphy's law”).
You might notice that the terminator issue discussed
earlier becomes rather hairy if your bus is not linear. Also,
if you have more connectors than devices on your internal SCSI
cable, make sure you attach devices on connectors on both ends
instead of using the connectors in the middle and let one or
both ends dangle. This will screw up the termination of the
bus.
The electrical characteristics, its noise margins and
ultimately the reliability of it all are tightly related to
linear bus rule.
Stick to the linear bus
rule!
Using SCSI with FreeBSD
About translations, BIOSes and magic...
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
translated 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 all operating systems on the disk use
the same translation 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:
aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512
Newer kernels usually do not report this information. e.g.
(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)
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 if the BIOS is never going to know about
this disk, (e.g. it is not a booting disk) to
supply a fictitious geometry that is convenient.
SCSI subsystem design
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), CD-ROMs (cd) etc. In case you are wondering where you
can find this stuff, it all lives in
/sys/scsi. 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.
Kernel configuration
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
not 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.
Note that most of the EISA/PCI drivers (namely
ahb, ahc,
ncr and
amd will automatically obtain the
correct parameters from the host adapters themselves at boot
time; thus, you just need to write, for instance,
controller ahc0.
An example loosely based on the FreeBSD 2.2.5-Release
kernel config file LINT with some added comments (between
[]):
# 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!)
# amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T)
# bt: Most Buslogic controllers
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
# ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards
# 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/294x/394x etc controller]
controller ahc0
[For an NCR/Symbios 53c875 based controller]
controller ncr0
[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 ncr0
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 ncr0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CD-ROM found, no wiring]
The example above tells the kernel to look for a ahc
(Adaptec 274x) controller, then for an NCR/Symbios board, and
so on. The lines following the controller specifications tell
the kernel to configure specific devices but
only 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.
Wired down devices need not be found 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 no 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 /etc/fstab
each time.
Although the old style still works, you are
strongly 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.
[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 CD-ROM]
device cd0 #Only need one of these, the code dynamically grows
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 man 4 scsi to check for
the latest info on the SCSI subsystem. For more detailed info
on host adapter drivers use eg man 4
ahc for info on the Adaptec 294x driver.
Tuning your SCSI kernel setup
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, CD-ROM 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:
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
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
CD-ROM 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.
Rogue SCSI devices
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:
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
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 CD-ROM 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.
Multiple LUN devices
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 initialized like below:
{
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
"mx1", SC_ONE_LU
}
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:
{
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
"sd", SC_MORE_LUS
}
The kernel on boot scans the inquiry data it receives
against the table and acts accordingly. See the source for
more info.
Tagged command queueing
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.
Busmaster host adapters
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:
options "TUNE_1542" #dynamic tune of bus DMA speed
Check the man pages for the host adapter that you use. Or
better still, use the ultimate documentation (read: driver
source).
Tracking down problems
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.
Check for loose connectors and cables.
Check and double check the location and number of your
terminators.
Check if your bus has at least one supplier of
terminator power (especially with external
terminators.
Check if no double target IDs are used.
Check if all devices to be used are powered up.
Make a minimal bus config with as little devices as
possible.
If possible, configure your host adapter to use slow
bus speeds.
Disable tagged command queuing to make things as
simple as possible (for a NCR hostadapter based system see
man ncrcontrol)
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 /sys/scsi/scsidebug.h.
If it probes but just does not work, you can use the
scsi8 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 man 4
scsi for more exact information. Also look at
man 8 scsi.
Further reading
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
13th Floor
11 West 42nd Street
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:
AT Attachment (ATA or IDE) [X3.221-1994]
(Approved)
ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991]
(Approved)
Small Computer System Interface — 2 (SCSI-2)
[X3.131-1994] (Approved)
SCSI-2 Common Access Method Transport and SCSI
Interface Module (CAM) [X3T10/792D Rev 11]
Other publications that might provide you with
additional information are:
“SCSI: Understanding the Small Computer System
Interface”, written by NCR Corporation. Available from:
Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201)
767-5937 ISBN 0-13-796855-8
“Basics of SCSI”, a SCSI tutorial written by Ancot
Corporation Contact Ancot for availability information at:
Phone: (415) 322-5322 Fax: (415) 322-0455
“SCSI Interconnection Guide Book”, an AMP publication
(dated 4/93, Catalog 65237) that lists the various SCSI
connectors and suggests cabling schemes. Available from
AMP at (800) 522-6752 or (717) 564-0100
“Fast Track to SCSI”, A Product Guide written by
Fujitsu. Available from: Prentice Hall, Englewood Cliffs,
NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X
“The SCSI Bench Reference”, “The SCSI Encyclopedia”,
and the “SCSI Tutor”, ENDL Publications, 14426 Black
Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642
“Zadian SCSI Navigator” (quick ref. book) and
“Discover the Power of SCSI” (First book along with a
one-hour video and tutorial book), Zadian Software, Suite
214, 1210 S. Bascom Ave., San Jose, CA 92128, (408)
293-0800
On Usenet the newsgroups comp.periphs.scsi and
comp.periphs are
noteworthy places to look for more info. You can also find the
SCSI-Faq there, which 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.
* Disk/tape controllers
* SCSI
* IDE
* Floppy
Hard drives
SCSI hard drives
Contributed by &a.asami;.17 February
1998.
As mentioned in the SCSI
section, virtually all SCSI hard drives sold today are SCSI-2
compliant and thus will work fine as long as you connect them to
a supported SCSI host adapter. Most problems people encounter
are either due to badly designed cabling (cable too long, star
topology, etc.), insufficient termination, or defective parts.
Please refer to the SCSI
section first if your SCSI hard drive is not working. However,
there are a couple of things you may want to take into account
before you purchase SCSI hard drives for your system.
Rotational speed
Rotational speeds of SCSI drives sold today range from
around 4,500RPM to 10,000RPM. Most of them are either 5,400RPM
or 7,200RPM. Even though the 7,200RPM drives can generally
transfer data faster, they run considerably hotter than their
5,400RPM counterparts. A large fraction of today's disk drive
malfunctions are heat-related. If you do not have very good
cooling in your PC case, you may want to stick with 5,400RPM
or slower drives.
Note that newer drives, with higher areal recording
densities, can deliver much more bits per rotation than older
ones. Today's top-of-line 5,400RPM drives can sustain a
throughput comparable to 7,200RPM drives of one or two model
generations ago. The number to find on the spec sheet for
bandwidth is “internal data (or transfer) rate”. It is
usually in megabits/sec so divide it by 8 and you'll get the
rough approximation of how much megabytes/sec you can get out
of the drive.
(If you are a speed maniac and want a 10,000RPM drive for
your cute little peecee, be my guest; however, those drives
become extremely hot. Don't even think about it if you don't
have a fan blowing air directly at the
drive or a properly ventilated disk enclosure.)
Obviously, the latest 10,000RPM drives and 7,200RPM drives
can deliver more data than the latest 5,400RPM drives, so if
absolute bandwidth is the necessity for your applications, you
have little choice but to get the faster drives. Also, if you
need low latency, faster drives are better; not only do they
usually have lower average seek times, but also the rotational
delay is one place where slow-spinning drives can never beat a
faster one. (The average rotational latency is half the time
it takes to rotate the drive once; thus, it's 3 milliseconds
for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for
5,400RPM drives.) Latency is seek time plus rotational delay.
Make sure you understand whether you need low latency or more
accesses per second, though; in the latter case (e.g., news
servers), it may not be optimal to purchase one big fast
drive. You can achieve similar or even better results by
using the ccd (concatenated disk) driver to create a striped
disk array out of multiple slower drives for comparable
overall cost.
Make sure you have adequate air flow around the drive,
especially if you are going to use a fast-spinning drive. You
generally need at least 1/2" (1.25cm) of spacing above and
below a drive. Understand how the air flows through your PC
case. Most cases have the power supply suck the air out of
the back. See where the air flows in, and put the drive where
it will have the largest volume of cool air flowing around it.
You may need to seal some unwanted holes or add a new fan for
effective cooling.
Another consideration is noise. Many 7,200 or faster
drives generate a high-pitched whine which is quite unpleasant
to most people. That, plus the extra fans often required for
cooling, may make 7,200 or faster drives unsuitable for some
office and home environments.
Form factor
Most SCSI drives sold today are of 3.5" form factor. They
come in two different heights; 1.6" (“half-height”) or 1"
(“low-profile”). The half-height drive is the same height as a
CD-ROM drive. However, don't forget the spacing rule
mentioned in the previous section. If you have three standard
3.5" drive bays, you will not be able to put three half-height
drives in there (without frying them, that is).
Interface
The majority of SCSI hard drives sold today are Ultra or
Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is
20MB/sec, and Ultra-wide SCSI is 40MB/sec. There is no
difference in max cable length between Ultra and Ultra-wide;
however, the more devices you have on the same bus, the sooner
you will start having bus integrity problems. Unless you have
a well-designed disk enclosure, it is not easy to make more
than 5 or 6 Ultra SCSI drives work on a single bus.
On the other hand, if you need to connect many drives,
going for Fast-wide SCSI may not be a bad idea. That will
have the same max bandwidth as Ultra (narrow) SCSI, while
electronically it's much easier to get it “right”. My advice
would be: if you want to connect many disks, get wide SCSI
drives; they usually cost a little more but it may save you
down the road. (Besides, if you can't afford the cost
difference, you shouldn't be building a disk array.)
There are two variant of wide SCSI drives; 68-pin and
80-pin SCA (Single Connector Attach). The SCA drives don't
have a separate 4-pin power connector, and also read the SCSI
ID settings through the 80-pin connector. If you are really
serious about building a large storage system, get SCA drives
and a good SCA enclosure (dual power supply with at least one
extra fan). They are more electronically sound than 68-pin
counterparts because there is no “stub” of the SCSI bus inside
the disk canister as in arrays built from 68-pin drives. They
are easier to install too (you just need to screw the drive in
the canister, instead of trying to squeeze in your fingers in
a tight place to hook up all the little cables (like the SCSI
ID and disk activity LED lines).
* IDE hard drives
Tape drives
Contributed by &a.jmb;.2 July
1996.
General tape access commands
mt1 provides generic access to the tape
drives. Some of the more common commands are
rewind, erase, and
status. See the mt1
manual page for a detailed description.
Controller Interfaces
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
Disk/tape
controllers.
SCSI drives
The st4 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
st4 manual page for a detailed
description.
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.
4mm (DAT: Digital Audio Tape)
Archive
Python
HP
C1533A
HP
C1534A
HP
35450A
HP
35470A
HP
35480A
SDT-5000
Wangtek
6200
8mm (Exabyte)
EXB-8200
EXB-8500
EXB-8505
QIC (Quarter-Inch Cartridge)
Archive
Ananconda 2750
Archive Viper
60
Archive Viper
150
Archive Viper
2525
Tandberg
TDC 3600
Tandberg
TDC 3620
Tandberg
TDC 4222
Wangtek
5525ES
DLT (Digital Linear Tape)
Digital
TZ87
Mini-Cartridge
Conner CTMS
3200
Exabyte
2501
Autoloaders/Changers
Hewlett-Packard
HP C1553A Autoloading DDS2
* IDE drives
Floppy drives
Conner
420R
* Parallel port drives
Detailed Information
Archive Anaconda 2750
The boot message identifier for this drive is
ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI
2
This is a QIC tape drive.
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.
Data transfer rate is 350kB/s using
dump8. Rates of 530kB/s have been
reported when using Amanda
Production of this drive has been discontinued.
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.
Two kernel code changes are required to use this drive.
This drive will not work as delivered.
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.
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.
*** 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,
Reported by: &a.jmb;
Archive Python
The boot message identifier for this drive is
ARCHIVE Python 28454-XXX4ASB type
1 removable SCSI 2 density code 0x8c,
512-byte blocks
This is a DDS-1 tape drive.
Native capacity is 2.5GB on 90m tapes.
Data transfer rate is XXX.
This drive was repackaged by Sun Microsystems as model
411.
Reported by: Bob Bishop rb@gid.co.uk
Archive Viper 60
The boot message identifier for this drive is
ARCHIVE VIPER 60 21116 -007 type 1
removable SCSI 1
This is a QIC tape drive.
Native capacity is 60MB.
Data transfer rate is XXX.
Production of this drive has been discontinued.
Reported by: Philippe Regnauld regnauld@hsc.fr
Archive Viper 150
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.
This is a QIC tape drive.
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.
Data transfer rate is 100kB/s
This drive reads and writes DC6150 (150MB) and DC6250
(250MB) tapes.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Under FreeBSD 2.2-current, use mt
blocksize 512 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.
Production of this drive has been discontinued.
Reported by: Pedro A M Vazquez
vazquez@IQM.Unicamp.BR
Mike Smith
msmith@atrad.adelaide.edu.au
Archive Viper 2525
The boot message identifier for this drive is ARCHIVE
VIPER 2525 25462 -011 type 1 removable SCSI 1
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s at 90 inches/sec.
The drive reads QIC-525, QIC-150, QIC-120 and QIC-24
tapes. Writes QIC-525, QIC-150, and QIC-120.
Firmware revisions prior to 25462 -011 are bug ridden
and will not function properly.
Production of this drive has been discontinued.
Conner 420R
The boot message identifier for this drive is Conner
tape.
This is a floppy controller, minicartridge tape
drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-80 tape cartridges.
Reported by: Mark Hannon mark@seeware.DIALix.oz.au
Conner CTMS 3200
The boot message identifier for this drive is CONNER CTMS
3200 7.00 type 1 removable SCSI 2.
This is a minicartridge tape drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-3080 tape cartridges.
Reported by: Thomas S. Traylor tst@titan.cs.mci.com
<ulink
URL="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink>
The boot message identifier for this drive is DEC TZ87
(C) DEC 9206 type 1 removable SCSI 2 density code
0x19
This is a DLT tape drive.
Native capacity is 10GB.
This drive supports hardware data compression.
Data transfer rate is 1.2MB/s.
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.
Reported by: &a.wilko;
<ulink
URL="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink>
The boot message identifier for this drive is EXABYTE
EXB-2501
This is a mini-cartridge tape drive.
Native capacity is 1GB when using MC3000XL
minicartridges.
Data transfer rate is XXX
This drive can read and write DC2300 (550MB), DC2750
(750MB), MC3000 (750MB), and MC3000XL (1GB)
minicartridges.
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
&prompt.root; mt -f /dev/st0ctl.0 blocksize 1024
Before using a minicartridge for the first time, the
minicartridge must be formated. FreeBSD 2.1.0-RELEASE and
earlier:
&prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0"
(Alternatively, fetch a copy of the scsiformat shell script from FreeBSD
2.1.5/2.2.) FreeBSD 2.1.5 and later:
&prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl
Right now, this drive cannot really be recommended for
FreeBSD.
Reported by: Bob Beaulieu ez@eztravel.com
Exabyte EXB-8200
The boot message identifier for this drive is EXABYTE
EXB-8200 252X type 1 removable SCSI 1
This is an 8mm tape drive.
Native capacity is 2.3GB.
Data transfer rate is 270kB/s.
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).
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.
Production of this drive has been discontinued.
Reported by: Mike Smith
msmith@atrad.adelaide.edu.au
Exabyte EXB-8500
The boot message identifier for this drive is EXABYTE
EXB-8500-85Qanx0 0415 type 1 removable SCSI 2
This is an 8mm tape drive.
Native capacity is 5GB.
Data transfer rate is 300kB/s.
Reported by: Greg Lehey grog@lemis.de
<ulink
URL="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink>
The boot message identifier for this drive is EXABYTE
EXB-85058SQANXR1 05B0 type 1 removable SCSI 2
This is an 8mm tape drive which supports compression, and
is upward compatible with the EXB-5200 and EXB-8500.
Native capacity is 5GB.
The drive supports hardware data compression.
Data transfer rate is 300kB/s.
Reported by: Glen Foster gfoster@gfoster.com
Hewlett-Packard HP C1533A
The boot message identifier for this drive is HP C1533A
9503 type 1 removable SCSI 2.
This is a DDS-2 tape drive. DDS-2 means hardware data
compression and narrower tracks for increased data
capacity.
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s.
This drive is used in Hewlett-Packard's SureStore 6000eU
and 6000i tape drives and C1533A DDS-2 DAT drive.
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.
switch 1
switch 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, with host
control
Off
Off
Compression disabled at power-on, no host
control
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.
See HP
SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 2 of these drives. Neither lasted more than 5
months.
Reported by: &a.se;
Hewlett-Packard HP 1534A
The boot message identifier for this drive is HP HP35470A
T503 type 1 removable SCSI 2 Sequential-Access density code
0x13, variable blocks.
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive and HP C1536A DDS format DAT drive.
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?)
Reported by Gary Crutcher gcrutchr@nightflight.com
Hewlett-Packard HP C1553A Autoloading DDS2
The boot message identifier for this drive is "".
This is a DDS-2 tape drive with a tape changer. DDS-2
means hardware data compression and narrower tracks for
increased data capacity.
Native capacity is 24GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s (native).
This drive is used in Hewlett-Packard's SureStore 12000e
tape drive.
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.
There are four internal switches. These should be set: 1
ON; 2 ON; 3 ON; 4 OFF.
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:
#!/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"
Hewlett-Packard HP 35450A
The boot message identifier for this drive is HP HP35450A
-A C620 type 1 removable SCSI 2 Sequential-Access density
code 0x13
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 1.2GB.
Data transfer rate is 160kB/s.
Reported by: mark thompson
mark.a.thompson@pobox.com
Hewlett-Packard HP 35470A
The boot message identifier for this drive is HP HP35470A
9 09 type 1 removable SCSI 2
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive, and HP C1536A DDS format DAT drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 5 of these drives. None lasted more than 9
months.
Reported by: David Dawes dawes@rf900.physics.usyd.edu.au
(9 09)
Hewlett-Packard HP 35480A
The boot message identifier for this drive is HP HP35480A
1009 type 1 removable SCSI 2 Sequential-Access density
code 0x13.
This is a DDS-DC tape drive. DDS-DC is DDS-1 with
hardware data compression. DDS-1 is the original DAT tape
format.
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 HP
C1533A for the proper switch settings.
Data transfer rate is 183kB/s.
This drive is used in Hewlett-Packard's SureStore 5000eU
and 5000i
tape drives and C35480A DDS format DAT drive..
This drive will occasionally hang during a tape eject
operation (mt offline).
Pressing the front panel button will eject the tape and bring
the tape drive back to life.
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.
<ulink
URL="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink>
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.
The boot message identifier for this drive is SONY
SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access
density code 0x13
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
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.
In order to get this drive to stream, set the blocksize to
512 bytes (mt blocksize 512)
reported by Kenneth Merry
ken@ulc199.residence.gatech.edu
SONY SDT-5000 327M information reported by Charles
Henrich henrich@msu.edu
Reported by: &a.jmz;
Tandberg TDC 3600
The boot message identifier for this drive is TANDBERG
TDC 3600 =08: type 1 removable SCSI 2
This is a QIC tape drive.
Native capacity is 150/250MB.
This drive has quirks which are known and work around code
is present in the scsi tape device driver (st4). Upgrading the firmware to XXX
version will fix the quirks and provide SCSI 2
capabilities.
Data transfer rate is 80kB/s.
IBM and Emerald units will not work. Replacing the
firmware EPROM of these units will solve the problem.
Reported by: Michael Smith
msmith@atrad.adelaide.edu.au
Tandberg TDC 3620
This is very similar to the Tandberg TDC 3600
drive.
Reported by: &a.joerg;
Tandberg TDC 4222
The boot message identifier for this drive is TANDBERG
TDC 4222 =07 type 1 removable SCSI 2
This is a QIC tape drive.
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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4)
beginning with FreeBSD 2.2-current. For previous versions of
FreeBSD, use mt to read one
block from the tape, rewind the tape, and then execute the
backup program (mt fsr 1; mt rewind; dump
...)
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.
Reported by: &a.joerg;
Wangtek 5525ES
The boot message identifier for this drive is WANGTEK
5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code
0x11, 1024-byte blocks
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s.
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 (mt erase) 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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Other firmware revisions that are known to work are:
M75D
Reported by: Marc van Kempen marc@bowtie.nl REV73R1
Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D
Wangtek 6200
The boot message identifier for this drive is WANGTEK
6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access
density code 0x13
This is a DDS-1 tape drive.
Native capacity is 2GB using 90m tapes.
Data transfer rate is 150kB/s.
Reported by: Tony Kimball alk@Think.COM
* Problem drives
CD-ROM drives
Contributed by &a.obrien;.23 November
1997.
As mentioned in
Jordan's Picks
Generally speaking those in The FreeBSD
Project 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 controllable by the various audio player
software.
Another area where SCSI CDROM manufacturers are cutting
corners is adhearance to the
SCSI specification.
Many SCSI CDROMs will respond to
multiple LUNs for its
target address. Known violators include the 6x Teac CD-56S
1.0D.
* Other
* Other
* PCMCIA
diff --git a/en_US.ISO8859-1/books/handbook/hw/chapter.sgml b/en_US.ISO8859-1/books/handbook/hw/chapter.sgml
index 0035977899..61c9047178 100644
--- a/en_US.ISO8859-1/books/handbook/hw/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/hw/chapter.sgml
@@ -1,5684 +1,5685 @@
PC Hardware compatibility
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. You may also want to refer to the kernel configuration
file section in this handbook for
a list of supported devices.
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
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.
Resources on the Internet
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.
The Pentium
Systems Hardware Performance Guide
Sample Configurations
The following list of sample hardware configurations by no means
constitutes an endorsement of a given hardware vendor or product by
The FreeBSD Project. 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.
Jordan's Picks
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.
Motherboards
For Pentium Pro (P6) systems, I'm quite fond of the Tyan
S1668 dual-processor motherboard as well as the Intel PR440FX
motherboard with on-board SCSI WIDE and 100/10MB Intel
Etherexpress NIC. You can build a dandy little single or dual
processor system (which is supported in FreeBSD 3.0) for very
little cost now that the Pentium Pro 180/256K chips have fallen so
greatly in price, but no telling how much longer this will
last.
For the Pentium II, I'm rather partial to the ASUS P2l97-S motherboard with the on-board Adaptec SCSI WIDE controller.
For Pentium machines, the ASUS P55T2P4 motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems.
Those wishing to build more fault-tolerant systems should
also be sure to use Parity memory or, for truly 24/7
applications, ECC memory.
ECC memory does involve a slight performance trade-off
(which may or may not be noticeable depending on your
application) but buys you significantly increased
fault-tolerance to memory errors.
Disk Controllers
This one is a bit trickier, and while I used to recommend
the Buslogic
controllers unilaterally for everything from ISA to PCI, now I
tend to lean towards the Adaptec 1542CF for ISA,
Buslogic Bt747c for EISA and Adaptec 2940UW 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).
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.
There are two types of 3940 on the market—the older
model with AIC 7880 chips on it, and hte newer one with AIC 7895
chips. The newer model requires CAM support which is not yet part of FreeBSD—you have to add it, or install from one of the CAM binary snapshot release.
Disk drives
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! For a serious server configuration, there's not
even any argument—use SCSI equipment and good cables.
CDROM drives
My SCSI preferences extend to SCSI CDROM drives as well, and
while the Toshiba
drives have always been favourites of mine (in whatever speed is
hot that week), I'm still fond of my good old Plextor PX-12CS drive. It's
only a 12 speed, but it's offered excellent performance and
reliability.
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.
CD Recordable (WORM) drives
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 6020i. I myself use the HP 6020i for burning
CDROMs (in 2.2 and alter releases—it does not work with
earlier releases of the SCSI code) and it works very well. See
/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 HP6020i CDR.
Tape drives
I've had pretty good luck with both 8mm drives from Exabyte and 4mm (DAT) drives from HP.
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.
Video Cards
If you can also afford to buy a commercial X server for
US$99 from Xi Graphics,
Inc. (formerly X Inside, Inc) then I can heartily
recommend the Matrox
Millenium II card. Note that support for this card is also excellent with the XFree86 server, which is now at version 3.3.2.
You also certainly can't go wrong with one of 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. You can
also pick up their Revolution 3D cards very cheaply these days,
especially if you require a lot of video memory.
Monitors
I have had very good luck with the Sony Multiscan 17seII 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,000 for a 21" monitor or $1,700 for a 20" 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!
Networking
I can recommend the Intel EtherExpress Pro/100B card first
ande foremost, followed by the SMC Ultra 16 controller for
any ISA application and the SMC EtherPower or Compex ENET32
cards for slightly cheaper PCI based networking. In general, any
PCI NIC based around DEC's DC21041 Ethernet controller chip,
such as the Zynx ZX342 or DEC DE435, will generally work quite
well and can frequently be found in 2-port and 4-port version
(useful for firewalls and routers), though the Pro/100MB card has
the edge when it comes to providing the best performance with teh
lower overhead.
If what you're looking for is the
cheapest possible solution then almost any NE2000 clone will do
a fine job for very little cost.
Serial
If you're looking for high-speed serial networking
solutions, then Digi
International makes the SYNC/570 series, with drivers now in FreeBSD-current. Emerging Technologies also manufactures a board with T1/E1 capabilities, using software they provide. I have no direct experience using either product, however.
Multiport card options are somewhat more numerous, though it
has to be said that FreeBSD's support for 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 Stallion
Technologies apparently offers an unofficial driver
for their cards at this location.
Audio
I currently use a Creative Labs AWE32 though
just about anything from Creative Labs will generally work these
days. This is not to say that other types of sound cards don't
also work, simply that I have little experience with them (I was
a former GUS fan, but Gravis's soundcard situation has been dire
for some time).
Video
For video capture, there are two good choices — any card
based on the Brooktree BT848 chip, such as the Hauppage or WinTV
boards, will work very nicely with FreeBSD. Another board which
works for me is the Matrox Meteor
card. FreeBSD also supports the older video spigot card from
Creative Labs, but those are getting somewhat difficult to find.
Note that the Meteor frame grabber card will not
work with motherboards based on the 440FX chipset!
See the
motherboard reference section for
details. In such cases, it's better to go with a BT848 based
board.
Core/Processing
Motherboards, busses, and chipsets
* ISA
* EISA
* VLB
PCI
Contributed by &a.obrien; from postings by &a.rgrimes;.25 April
1995.
Continuing updates by &a.jkh;.Last update on 26 August 1996.
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.
Mercury:
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.
Saturn-I (ie, 82424ZX at rev 0,
1 or 2):
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.
Saturn-II (ie, 82424ZX at rev 3
or 4):
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).
Neptune:
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”.
Triton (ie,
430FX):
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.
Triton-II (ie,
430HX):
All reports on motherboards using this chipset have
been favorable so far. No known problems.
Orion:
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.
440FX:
This 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.
CPUs/FPUs
Contributed by &a.asami;.26 December
1997.
P6 class (Pentium Pro/Pentium II)
Both the Pentium Pro and Pentium II work fine with FreeBSD.
In fact, our main ftp site ftp.freebsd.org (also
known as "ftp.cdrom.com", world's largest
ftp site) runs FreeBSD on a Pentium Pro. Configurations details are available for interested parties.
Pentium class
The Intel Pentium (P54C), Pentium MMX (P55C), AMD K6 and
Cyrix/IBM 6x86MX processors are all reported to work with
FreeBSD. I will not go into details of which processor is
faster than what, there are zillions of web sites on the
Internet that tells you one way or another. :)
Various CPUs have different voltage/cooling requirements.
Make sure your motherboard can supply the exact voltage needed
by the CPU. For instance, many recent MMX chips require split
voltage (e.g., 2.9V core, 3.3V I/O). Also, some AMD and
Cyrix/IBM chips run hotter than Intel chips. In that case,
make sure you have good heatsink/fans (you can get the list of
certified parts from their web pages).
Clock speeds
Contributed by &a.rgrimes;.1
October 1996.
Updated by &a.asami;.27 December
1997.
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:
Rated CPU MHz
External Clock and Memory Bus MHz
External to Internal Clock Multiplier
PCI Bus Clock 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 (Intel, AMD)
150
75
2
37.5 (Cyrix/IBM 6x86MX)
166
66
2.5
33
180
60
3
30
200
66
3
33
233
66
3.5
33
66MHz may actually be 66.667MHz, but don't assume
so.
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.
As can be seen the best parts to be using are the 100,
133, 166, 200 and 233, with the exception that at a multiplier
of 3 or more the CPU starves for memory.
The AMD K6 Bug
In 1997, there have been reports of the AMD K6 seg
faulting during heavy compilation. That problem has been
fixed in 3Q '97. According to reports, K6 chips with date mark
“9733” or larger (i.e., manufactured in the 33rd week of '97
or later) do not have this bug.
* 486 class
* 386 class
286 class
Sorry, FreeBSD does not run on 80286 machines. It is nearly
impossible to run today's large full-featured UNIXes on such
hardware.
* Memory
The minimum amount of memory you must have to install FreeBSD
is 5 MB. Once your system is up and running you can build a custom kernel
that will use less memory. If you use the boot4.flp you can get
away with having only 4 MB.
* BIOS
Input/Output Devices
* Video cards
* Sound cards
Serial ports and multiport cards
The UART: What it is and how it works
Copyright © 1996 &a.uhclem;, All Rights
Reserved. 13 January 1996.
The Universal Asynchronous Receiver/Transmitter (UART)
controller is the key component of the serial communications
subsystem of a computer. The UART takes bytes of data and
transmits the individual bits in a sequential fashion. At the
destination, a second UART re-assembles the bits into complete
bytes.
Serial transmission is commonly used with modems and for
non-networked communication between computers, terminals and
other devices.
There are two primary forms of serial transmission:
Synchronous and Asynchronous. Depending on the modes that are
supported by the hardware, the name of the communication
sub-system will usually include a A if it supports
Asynchronous communications, and a S if it supports
Synchronous communications. Both forms are described
below.
Some common acronyms are:
UART Universal Asynchronous
Receiver/Transmitter
USART Universal Synchronous-Asynchronous
Receiver/Transmitter
Synchronous Serial Transmission
Synchronous serial transmission requires that the sender
and receiver share a clock with one another, or that the
sender provide a strobe or other timing signal so that the
receiver knows when to “read” the next bit of the data. In
most forms of serial Synchronous communication, if there is no
data available at a given instant to transmit, a fill
character must be sent instead so that data is always being
transmitted. Synchronous communication is usually more
efficient because only data bits are transmitted between
sender and receiver, and synchronous communication can be more
more costly if extra wiring and circuits are required to share
a clock signal between the sender and receiver.
A form of Synchronous transmission is used with printers
and fixed disk devices in that the data is sent on one set of
wires while a clock or strobe is sent on a different wire.
Printers and fixed disk devices are not normally serial
devices because most fixed disk interface standards send an
entire word of data for each clock or strobe signal by using a
separate wire for each bit of the word. In the PC industry,
these are known as Parallel devices.
The standard serial communications hardware in the PC does
not support Synchronous operations. This mode is described
here for comparison purposes only.
Asynchronous Serial Transmission
Asynchronous transmission allows data to be transmitted
without the sender having to send a clock signal to the
receiver. Instead, the sender and receiver must agree on
timing parameters in advance and special bits are added to
each word which are used to synchronize the sending and
receiving units.
When a word is given to the UART for Asynchronous
transmissions, a bit called the "Start Bit" is added to the
beginning of each word that is to be transmitted. The Start
Bit is used to alert the receiver that a word of data is about
to be sent, and to force the clock in the receiver into
synchronization with the clock in the transmitter. These two
clocks must be accurate enough to not have the frequency
drift by more than 10% during the transmission of the
remaining bits in the word. (This requirement was set in the
days of mechanical teleprinters and is easily met by modern
electronic equipment.)
After the Start Bit, the individual bits of the word of
data are sent, with the Least Significant Bit (LSB) being sent
first. Each bit in the transmission is transmitted for
exactly the same amount of time as all of the other bits, and
the receiver “looks” at the wire at approximately halfway
through the period assigned to each bit to determine if the
bit is a 1 or a 0. For example, if it takes two seconds
to send each bit, the receiver will examine the signal to
determine if it is a 1 or a 0 after one second has passed,
then it will wait two seconds and then examine the value of
the next bit, and so on.
The sender does not know when the receiver has “looked” at
the value of the bit. The sender only knows when the clock
says to begin transmitting the next bit of the word.
When the entire data word has been sent, the transmitter
may add a Parity Bit that the transmitter generates. The
Parity Bit may be used by the receiver to perform simple error
checking. Then at least one Stop Bit is sent by the
transmitter.
When the receiver has received all of the bits in the data
word, it may check for the Parity Bits (both sender and
receiver must agree on whether a Parity Bit is to be used),
and then the receiver looks for a Stop Bit. If the Stop Bit
does not appear when it is supposed to, the UART considers the
entire word to be garbled and will report a Framing Error to
the host processor when the data word is read. The usual
cause of a Framing Error is that the sender and receiver
clocks were not running at the same speed, or that the signal
was interrupted.
Regardless of whether the data was received correctly or
not, the UART automatically discards the Start, Parity and
Stop bits. If the sender and receiver are configured
identically, these bits are not passed to the host.
If another word is ready for transmission, the Start Bit
for the new word can be sent as soon as the Stop Bit for the
previous word has been sent.
Because asynchronous data is “self synchronizing”, if
there is no data to transmit, the transmission line can be
idle.
Other UART Functions
In addition to the basic job of converting data from
parallel to serial for transmission and from serial to
parallel on reception, a UART will usually provide additional
circuits for signals that can be used to indicate the state of
the transmission media, and to regulate the flow of data in
the event that the remote device is not prepared to accept
more data. For example, when the device connected to the
UART is a modem, the modem may report the presence of a
carrier on the phone line while the computer may be able to
instruct the modem to reset itself or to not take calls by
asserting or deasserting one more more of these extra signals.
The function of each of these additional signals is defined in
the EIA RS232-C standard.
The RS232-C and V.24 Standards
In most computer systems, the UART is connected to
circuitry that generates signals that comply with the EIA
RS232-C specification. There is also a CCITT standard named
V.24 that mirrors the specifications included in
RS232-C.
RS232-C Bit Assignments (Marks and Spaces)
In RS232-C, a value of 1 is called a Mark and a
value of 0 is called a Space. When a communication line
is idle, the line is said to be “Marking”, or transmitting
continuous 1 values.
The Start bit always has a value of 0 (a Space). The
Stop Bit always has a value of 1 (a Mark). This means
that there will always be a Mark (1) to Space (0) transition
on the line at the start of every word, even when multiple
word are transmitted back to back. This guarantees that
sender and receiver can resynchronize their clocks
regardless of the content of the data bits that are being
transmitted.
The idle time between Stop and Start bits does not have
to be an exact multiple (including zero) of the bit rate of
the communication link, but most UARTs are designed this way
for simplicity.
In RS232-C, the "Marking" signal (a 1) is represented
by a voltage between -2 VDC and -12 VDC, and a "Spacing"
signal (a 0) is represented by a voltage between 0 and +12
VDC. The transmitter is supposed to send +12 VDC or -12
VDC, and the receiver is supposed to allow for some voltage
loss in long cables. Some transmitters in low power devices
(like portable computers) sometimes use only +5 VDC and -5
VDC, but these values are still acceptable to a RS232-C
receiver, provided that the cable lengths are short.
RS232-C Break Signal
RS232-C also specifies a signal called a Break, which
is caused by sending continuous Spacing values (no Start or
Stop bits). When there is no electricity present on the
data circuit, the line is considered to be sending Break.
The Break signal must be of a duration longer than the
time it takes to send a complete byte plus Start, Stop and
Parity bits. Most UARTs can distinguish between a Framing
Error and a Break, but if the UART cannot do this, the
Framing Error detection can be used to identify
Breaks.
In the days of teleprinters, when numerous printers
around the country were wired in series (such as news
services), any unit could cause a Break by temporarily
opening the entire circuit so that no current flowed. This
was used to allow a location with urgent news to interrupt
some other location that was currently sending
information.
In modern systems there are two types of Break signals.
If the Break is longer than 1.6 seconds, it is considered a
"Modem Break", and some modems can be programmed to
terminate the conversation and go on-hook or enter the
modems' command mode when the modem detects this signal. If
the Break is smaller than 1.6 seconds, it signifies a Data
Break and it is up to the remote computer to respond to this
signal. Sometimes this form of Break is used as an
Attention or Interrupt signal and sometimes is accepted as a
substitute for the ASCII CONTROL-C character.
Marks and Spaces are also equivalent to “Holes” and “No
Holes” in paper tape systems.
Breaks cannot be generated from paper tape or from any
other byte value, since bytes are always sent with Start
and Stop bit. The UART is usually capable of generating
the continuous Spacing signal in response to a special
command from the host processor.
RS232-C DTE and DCE Devices
The RS232-C specification defines two types of
equipment: the Data Terminal Equipment (DTE) and the Data
Carrier Equipment (DCE). Usually, the DTE device is the
terminal (or computer), and the DCE is a modem. Across the
phone line at the other end of a conversation, the receiving
modem is also a DCE device and the computer that is
connected to that modem is a DTE device. The DCE device
receives signals on the pins that the DTE device transmits
on, and vice versa.
When two devices that are both DTE or both DCE must be
connected together without a modem or a similar media
translater between them, a NULL modem must be used. The
NULL modem electrically re-arranges the cabling so that the
transmitter output is connected to the receiver input on the
other device, and vice versa. Similar translations are
performed on all of the control signals so that each device
will see what it thinks are DCE (or DTE) signals from the
other device.
The number of signals generated by the DTE and DCE
devices are not symmetrical. The DTE device generates fewer
signals for the DCE device than the DTE device receives from
the DCE.
RS232-C Pin Assignments
The EIA RS232-C specification (and the ITU equivalent,
V.24) calls for a twenty-five pin connector (usually a DB25)
and defines the purpose of most of the pins in that
connector.
In the IBM Personal Computer and similar systems, a
subset of RS232-C signals are provided via nine pin
connectors (DB9). The signals that are not included on the
PC connector deal mainly with synchronous operation, and
this transmission mode is not supported by the UART that IBM
selected for use in the IBM PC.
Depending on the computer manufacturer, a DB25, a DB9,
or both types of connector may be used for RS232-C
communications. (The IBM PC also uses a DB25 connector for
the parallel printer interface which causes some
confusion.)
Below is a table of the RS232-C signal assignments in
the DB25 and DB9 connectors.
DB25 RS232-C Pin
DB9 IBM PC Pin
EIA Circuit Symbol
CCITT Circuit Symbol
Common Name
Signal Source
Description
1
-
AA
101
PG/FG
-
Frame/Protective Ground
2
3
BA
103
TD
DTE
Transmit Data
3
2
BB
104
RD
DCE
Receive Data
4
7
CA
105
RTS
DTE
Request to Send
5
8
CB
106
CTS
DCE
Clear to Send
6
6
CC
107
DSR
DCE
Data Set Ready
7
5
AV
102
SG/GND
-
Signal Ground
8
1
CF
109
DCD/CD
DCE
Data Carrier Detect
9
-
-
-
-
-
Reserved for Test
10
-
-
-
-
-
Reserved for Test
11
-
-
-
-
-
Reserved for Test
12
-
CI
122
SRLSD
DCE
Sec. Recv. Line Signal Detector
13
-
SCB
121
SCTS
DCE
Secondary Clear to Send
14
-
SBA
118
STD
DTE
Secondary Transmit Data
15
-
DB
114
TSET
DCE
Trans. Sig. Element Timing
16
-
SBB
119
SRD
DCE
Secondary Received Data
17
-
DD
115
RSET
DCE
Receiver Signal Element Timing
18
-
-
141
LOOP
DTE
Local Loopback
19
-
SCA
120
SRS
DTE
Secondary Request to Send
20
4
CD
108.2
DTR
DTE
Data Terminal Ready
21
-
-
-
RDL
DTE
Remote Digital Loopback
22
9
CE
125
RI
DCE
Ring Indicator
23
-
CH
111
DSRS
DTE
Data Signal Rate Selector
24
-
DA
113
TSET
DTE
Trans. Sig. Element Timing
25
-
-
142
-
DCE
Test Mode
Bits, Baud and Symbols
Baud is a measurement of transmission speed in
asynchronous communication. Because of advances in modem
communication technology, this term is frequently misused when
describing the data rates in newer devices.
Traditionally, a Baud Rate represents the number of bits
that are actually being sent over the media, not the amount of
data that is actually moved from one DTE device to the other.
The Baud count includes the overhead bits Start, Stop and
Parity that are generated by the sending UART and removed by
the receiving UART. This means that seven-bit words of data
actually take 10 bits to be completely transmitted. Therefore,
a modem capable of moving 300 bits per second from one place
to another can normally only move 30 7-bit words if Parity is
used and one Start and Stop bit are present.
If 8-bit data words are used and Parity bits are also
used, the data rate falls to 27.27 words per second, because
it now takes 11 bits to send the eight-bit words, and the
modem still only sends 300 bits per second.
The formula for converting bytes per second into a baud
rate and vice versa was simple until error-correcting modems
came along. These modems receive the serial stream of bits
from the UART in the host computer (even when internal modems
are used the data is still frequently serialized) and converts
the bits back into bytes. These bytes are then combined into
packets and sent over the phone line using a Synchronous
transmission method. This means that the Stop, Start, and
Parity bits added by the UART in the DTE (the computer) were
removed by the modem before transmission by the sending modem.
When these bytes are received by the remote modem, the remote
modem adds Start, Stop and Parity bits to the words, converts
them to a serial format and then sends them to the receiving
UART in the remote computer, who then strips the Start, Stop
and Parity bits.
The reason all these extra conversions are done is so that
the two modems can perform error correction, which means that
the receiving modem is able to ask the sending modem to resend
a block of data that was not received with the correct
checksum. This checking is handled by the modems, and the DTE
devices are usually unaware that the process is
occurring.
By striping the Start, Stop and Parity bits, the
additional bits of data that the two modems must share between
themselves to perform error-correction are mostly concealed
from the effective transmission rate seen by the sending and
receiving DTE equipment. For example, if a modem sends ten
7-bit words to another modem without including the Start, Stop
and Parity bits, the sending modem will be able to add 30 bits
of its own information that the receiving modem can use to do
error-correction without impacting the transmission speed of
the real data.
The use of the term Baud is further confused by modems
that perform compression. A single 8-bit word passed over the
telephone line might represent a dozen words that were
transmitted to the sending modem. The receiving modem will
expand the data back to its original content and pass that
data to the receiving DTE.
Modern modems also include buffers that allow the rate
that bits move across the phone line (DCE to DCE) to be a
different speed than the speed that the bits move between the
DTE and DCE on both ends of the conversation. Normally the
speed between the DTE and DCE is higher than the DCE to DCE
speed because of the use of compression by the modems.
Because the number of bits needed to describe a byte
varied during the trip between the two machines plus the
differing bits-per-seconds speeds that are used present on
the DTE-DCE and DCE-DCE links, the usage of the term Baud to
describe the overall communication speed causes problems and
can misrepresent the true transmission speed. So Bits Per
Second (bps) is the correct term to use to describe the
transmission rate seen at the DCE to DCE interface and Baud or
Bits Per Second are acceptable terms to use when a connection
is made between two systems with a wired connection, or if a
modem is in use that is not performing error-correction or
compression.
Modern high speed modems (2400, 9600, 14,400, and
19,200bps) in reality still operate at or below 2400 baud, or
more accurately, 2400 Symbols per second. High speed modem
are able to encode more bits of data into each Symbol using a
technique called Constellation Stuffing, which is why the
effective bits per second rate of the modem is higher, but the
modem continues to operate within the limited audio bandwidth
that the telephone system provides. Modems operating at 28,800
and higher speeds have variable Symbol rates, but the
technique is the same.
The IBM Personal Computer UART
Starting with the original IBM Personal Computer, IBM
selected the National Semiconductor INS8250 UART for use in
the IBM PC Parallel/Serial Adapter. Subsequent generations of
compatible computers from IBM and other vendors continued to
use the INS8250 or improved versions of the National
Semiconductor UART family.
National Semiconductor UART Family Tree
There have been several versions and subsequent
generations of the INS8250 UART. Each major version is
described below.
INS8250 -> INS8250B
\
\
\-> INS8250A -> INS82C50A
\
\
\-> NS16450 -> NS16C450
\
\
\-> NS16550 -> NS16550A -> PC16550D
INS8250
This part was used in the original IBM PC and
IBM PC/XT. The original name for this part was the
INS8250 ACE (Asynchronous Communications Element)
and it is made from NMOS technology.
The 8250 uses eight I/O ports and has a one-byte
send and a one-byte receive buffer. This original
UART has several race conditions and other flaws.
The original IBM BIOS includes code to work around
these flaws, but this made the BIOS dependent on the
flaws being present, so subsequent parts like the
8250A, 16450 or 16550 could not be used in the
original IBM PC or IBM PC/XT.
INS8250-B
This is the slower speed of the INS8250 made
from NMOS technology. It contains the same problems
as the original INS8250.
INS8250A
An improved version of the INS8250 using XMOS
technology with various functional flaws corrected.
The INS8250A was used initially in PC clone
computers by vendors who used “clean” BIOS designs.
Because of the corrections in the chip, this part
could not be used with a BIOS compatible with the
INS8250 or INS8250B.
INS82C50A
This is a CMOS version (low power consumption)
of the INS8250A and has similar functional
characteristics.
NS16450
Same as NS8250A with improvements so it can be
used with faster CPU bus designs. IBM used this
part in the IBM AT and updated the IBM BIOS to no
longer rely on the bugs in the INS8250.
NS16C450
This is a CMOS version (low power consumption)
of the NS16450.
NS16550
Same as NS16450 with a 16-byte send and receive
buffer but the buffer design was flawed and could
not be reliably be used.
NS16550A
Same as NS16550 with the buffer flaws corrected.
The 16550A and its successors have become the most
popular UART design in the PC industry, mainly due
it its ability to reliably handle higher data rates
on operating systems with sluggish interrupt
response times.
NS16C552
This component consists of two NS16C550A CMOS
UARTs in a single package.
PC16550D
Same as NS16550A with subtle flaws corrected.
This is revision D of the 16550 family and is the
latest design available from National Semiconductor.
The NS16550AF and the PC16550D are the same
thing
National reorganized their part numbering system a few
years ago, and the NS16550AFN no longer exists by that name.
(If you have a NS16550AFN, look at the date code on the
part, which is a four digit number that usually starts with
a nine. The first two digits of the number are the year,
and the last two digits are the week in that year when the
part was packaged. If you have a NS16550AFN, it is probably
a few years old.)
The new numbers are like PC16550DV, with minor
differences in the suffix letters depending on the package
material and its shape. (A description of the numbering
system can be found below.)
It is important to understand that in some stores, you
may pay $15(US) for a NS16550AFN made in 1990 and in the
next bin are the new PC16550DN parts with minor fixes that
National has made since the AFN part was in production, the
PC16550DN was probably made in the past six months and it
costs half (as low as $5(US) in volume) as much as the
NS16550AFN because they are readily available.
As the supply of NS16550AFN chips continues to shrink,
the price will probably continue to increase until more
people discover and accept that the PC16550DN really has the
same function as the old part number.
National Semiconductor Part Numbering System
The older NSnnnnnrqp part numbers
are now of the format
PCnnnnnrgp.
The r is the revision field. The
current revision of the 16550 from National Semiconductor is
D.
The p is the package-type field.
The types are:
"F"
QFP
(quad flat pack) L lead type
"N"
DIP
(dual inline package) through hole straight
lead type
"V"
LPCC
(lead plastic chip carrier) J lead type
The g is the product grade field.
If an I precedes the package-type letter, it indicates an
“industrial” grade part, which has higher specs than a
standard part but not as high as Military Specification
(Milspec) component. This is an optional field.
So what we used to call a NS16550AFN (DIP Package) is
now called a PC16550DN or PC16550DIN.
Other Vendors and Similar UARTs
Over the years, the 8250, 8250A, 16450 and 16550 have been
licensed or copied by other chip vendors. In the case of the
8250, 8250A and 16450, the exact circuit (the “megacell”) was
licensed to many vendors, including Western Digital and Intel.
Other vendors reverse-engineered the part or produced
emulations that had similar behavior.
In internal modems, the modem designer will frequently
emulate the 8250A/16450 with the modem microprocessor, and the
emulated UART will frequently have a hidden buffer consisting
of several hundred bytes. Because of the size of the buffer,
these emulations can be as reliable as a 16550A in their
ability to handle high speed data. However, most operating
systems will still report that the UART is only a 8250A or
16450, and may not make effective use of the extra buffering
present in the emulated UART unless special drivers are
used.
Some modem makers are driven by market forces to abandon a
design that has hundreds of bytes of buffer and instead use a
16550A UART so that the product will compare favorably in
market comparisons even though the effective performance may
be lowered by this action.
A common misconception is that all parts with “16550A”
written on them are identical in performance. There are
differences, and in some cases, outright flaws in most of
these 16550A clones.
When the NS16550 was developed, the National Semiconductor
obtained several patents on the design and they also limited
licensing, making it harder for other vendors to provide a
chip with similar features. Because of the patents,
reverse-engineered designs and emulations had to avoid
infringing the claims covered by the patents. Subsequently,
these copies almost never perform exactly the same as the
NS16550A or PC16550D, which are the parts most computer and
modem makers want to buy but are sometimes unwilling to pay
the price required to get the genuine part.
Some of the differences in the clone 16550A parts are
unimportant, while others can prevent the device from being
used at all with a given operating system or driver. These
differences may show up when using other drivers, or when
particular combinations of events occur that were not well
tested or considered in the Windows driver. This is because
most modem vendors and 16550-clone makers use the Microsoft
drivers from Windows for Workgroups 3.11 and the Microsoft MSD
utility as the primary tests for compatibility with the
NS16550A. This over-simplistic criteria means that if a
different operating system is used, problems could appear due
to subtle differences between the clones and genuine
components.
National Semiconductor has made available a program named
COMTEST that performs compatibility tests independent of any
OS drivers. It should be remembered that the purpose of this
type of program is to demonstrate the flaws in the products of
the competition, so the program will report major as well as
extremely subtle differences in behavior in the part being
tested.
In a series of tests performed by the author of this
document in 1994, components made by National Semiconductor,
TI, StarTech, and CMD as well as megacells and emulations
embedded in internal modems were tested with COMTEST. A
difference count for some of these components is listed below.
Because these tests were performed in 1994, they may not
reflect the current performance of the given product from a
vendor.
It should be noted that COMTEST normally aborts when an
excessive number or certain types of problems have been
detected. As part of this testing, COMTEST was modified so
that it would not abort no matter how many differences were
encountered.
Vendor
Part Number
Errors (aka "differences" reported)
National
(PC16550DV)
- 0
- To date, the author of this document has not
- found any non-National parts that report zero
- differences using the COMTEST program. It should
- also be noted that National has had five versions
- of the 16550 over the years and the newest parts
- behave a bit differently than the classic
- NS16550AFN that is considered the benchmark for
- functionality. COMTEST appears to turn a blind eye
- to the differences within the National product
- line and reports no errors on the National parts
- (except for the original 16550) even when there
- are official erratas that describe bugs in the A,
- B and C revisions of the parts, so this bias in
- COMTEST must be taken into account.
-
-
+ 0
National
(NS16550AFN)
0
National
(NS16C552V)
0
TI
(TL16550AFN)
3
CMD
(16C550PE)
19
StarTech
(ST16C550J)
23
Rockwell
Reference modem with internal 16550 or an
emulation (RC144DPi/C3000-25)
117
Sierra
Modem with an internal 16550
(SC11951/SC11351)
91
+
+
+ To date, the author of this document has not
+ found any non-National parts that report zero
+ differences using the COMTEST program. It should
+ also be noted that National has had five versions
+ of the 16550 over the years and the newest parts
+ behave a bit differently than the classic
+ NS16550AFN that is considered the benchmark for
+ functionality. COMTEST appears to turn a blind eye
+ to the differences within the National product
+ line and reports no errors on the National parts
+ (except for the original 16550) even when there
+ are official erratas that describe bugs in the A,
+ B and C revisions of the parts, so this bias in
+ COMTEST must be taken into account.
+
It is important to understand that a simple count of
differences from COMTEST does not reveal a lot about what
differences are important and which are not. For example,
about half of the differences reported in the two modems
listed above that have internal UARTs were caused by the clone
UARTs not supporting five- and six-bit character modes. The
real 16550, 16450, and 8250 UARTs all support these modes and
COMTEST checks the functionality of these modes so over fifty
differences are reported. However, almost no modern modem
supports five- or six-bit characters, particularly those with
error-correction and compression capabilities. This means
that the differences related to five- and six-bit character
modes can be discounted.
Many of the differences COMTEST reports have to do with
timing. In many of the clone designs, when the host reads
from one port, the status bits in some other port may not
update in the same amount of time (some faster, some slower)
as a real NS16550AFN and COMTEST looks
for these differences. This means that the number of
differences can be misleading in that one device may only have
one or two differences but they are extremely serious, and
some other device that updates the status registers faster or
slower than the reference part (that would probably never
affect the operation of a properly written driver) could have
dozens of differences reported.
COMTEST can be used as a screening tool to alert the
administrator to the presence of potentially incompatible
components that might cause problems or have to be handled as
a special case.
If you run COMTEST on a 16550 that is in a modem or a
modem is attached to the serial port, you need to first issue
a ATE0&W command to the modem so that the modem will not
echo any of the test characters. If you forget to do this,
COMTEST will report at least this one difference:
Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61
8250/16450/16550 Registers
The 8250/16450/16550 UART occupies eight contiguous I/O
port addresses. In the IBM PC, there are two defined
locations for these eight ports and they are known
collectively as COM1 and COM2. The makers of PC-clones and
add-on cards have created two additional areas known as COM3
and COM4, but these extra COM ports conflict with other
hardware on some systems. The most common conflict is with
video adapters that provide IBM 8514 emulation.
COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ
4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3
COM3 is located from 0x3e8 to 0x3ef and has no standardized
IRQ COM4 is located from 0x2e8 to 0x2ef and has no
standardized IRQ.
A description of the I/O ports of the 8250/16450/16550
UART is provided below.
I/O Port
Access Allowed
Description
+0x00
write (DLAB==0)
Transmit Holding Register (THR).Information written to this port are treated as
data words and will be transmitted by the
UART.
+0x00
read (DLAB==0)
Receive Buffer Register (RBR).Any data words received by the UART form the
serial link are accessed by the host by reading this
port.
+0x00
write/read (DLAB==1)
Divisor Latch LSB (DLL)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 0 thru 7 of the
divisor.
+0x01
write/read (DLAB==1)
Divisor Latch MSB (DLH)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 8 thru 15 of the
divisor.
+0x01
write/read (DLAB==0)
Interrupt Enable
Register (IER)The 8250/16450/16550 UART classifies
events into one of four categories. Each
category can be configured to generate an
interrupt when any of the events occurs. The
8250/16450/16550 UART generates a single
external interrupt signal regardless of how
many events in the enabled categories have
occurred. It is up to the host processor to
respond to the interrupt and then poll the
enabled interrupt categories (usually all
categories have interrupts enabled) to
determine the true cause(s) of the
interrupt.
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Enable Modem Status Interrupt (EDSSI).
Setting this bit to "1" allows the UART to
generate an interrupt when a change occurs
on one or more of the status lines.
Bit 2
Enable Receiver Line Status Interrupt (ELSI)
Setting this bit to "1" causes the UART to
generate an interrupt when the an error
(or a BREAK signal) has been detected in
the incoming data.
Bit 1
Enable Transmitter Holding Register Empty
Interrupt (ETBEI) Setting this bit to "1"
causes the UART to generate an interrupt
when the UART has room for one or more
additional characters that are to be
transmitted.
Bit 0
Enable Received Data Available Interrupt
(ERBFI) Setting this bit to "1" causes the
UART to generate an interrupt when the
UART has received enough characters to
exceed the trigger level of the FIFO, or
the FIFO timer has expired (stale data),
or a single character has been received
when the FIFO is disabled.
+0x02
write
FIFO Control Register (FCR)
(This port does not exist on the 8250 and 16450
UART.)
Bit 7
Receiver Trigger Bit
#1
Bit 6
Receiver Trigger Bit
#0These two bits control at what
point the receiver is to generate an interrupt
when the FIFO is active.
7
6
How many words are received
before an interrupt is generated
0
0
1
0
1
4
1
0
8
1
1
14
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
DMA Mode Select. If Bit 0
is set to "1" (FIFOs enabled), setting this bit
changes the operation of the -RXRDY and -TXRDY
signals from Mode 0 to Mode 1.
Bit 2
Transmit FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
transmitted will be sent intact. This function
is useful in aborting transfers.
Bit 1
Receiver FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
assembled in the shift register will be received
intact.
Bit 0
16550 FIFO Enable. When
set, both the transmit and receive FIFOs are
enabled. Any contents in the holding register,
shift registers or FIFOs are lost when FIFOs are
enabled or disabled.
+0x02
read
Interrupt Identification
Register
Bit 7
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 6
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Interrupt ID Bit #2. On the
8250/16450 UART, this bit is zero.
Bit 2
Interrupt ID Bit #1
Bit 1
Interrupt ID Bit #0.These
three bits combine to report the category of
event that caused the interrupt that is in
progress. These categories have priorities, so
if multiple categories of events occur at the
same time, the UART will report the more
important events first and the host must resolve
the events in the order they are reported. All
events that caused the current interrupt must be
resolved before any new interrupts will be
generated. (This is a limitation of the PC
architecture.)
2
1
0
Priority
Description
0
1
1
First
Received Error (OE, PE, BI,
or FE)
0
1
0
Second
Received Data
Available
1
1
0
Second
Trigger level identification
(Stale data in receive buffer)
0
0
1
Third
Transmitter has room for
more words (THRE)
0
0
0
Fourth
Modem Status Change (-CTS,
-DSR, -RI, or -DCD)
Bit 0
Interrupt Pending Bit. If
this bit is set to "0", then at least one
interrupt is pending.
+0x03
write/read
Line Control
Register (LCR)
Bit 7
Divisor Latch Access Bit
(DLAB). When set, access to the data
transmit/receive register (THR/RBR) and the
Interrupt Enable Register (IER) is disabled. Any
access to these ports is now redirected to the
Divisor Latch Registers. Setting this bit,
loading the Divisor Registers, and clearing DLAB
should be done with interrupts disabled.
Bit 6
Set Break. When set to "1",
the transmitter begins to transmit continuous
Spacing until this bit is set to "0". This
overrides any bits of characters that are being
transmitted.
Bit 5
Stick Parity. When parity
is enabled, setting this bit causes parity to
always be "1" or "0", based on the value of Bit
4.
Bit 4
Even Parity Select (EPS).
When parity is enabled and Bit 5 is "0", setting
this bit causes even parity to be transmitted
and expected. Otherwise, odd parity is
used.
Bit 3
Parity Enable (PEN). When
set to "1", a parity bit is inserted between the
last bit of the data and the Stop Bit. The UART
will also expect parity to be present in the
received data.
Bit 2
Number of Stop Bits (STB).
If set to "1" and using 5-bit data words, 1.5
Stop Bits are transmitted and expected in each
data word. For 6, 7 and 8-bit data words, 2
Stop Bits are transmitted and expected. When
this bit is set to "0", one Stop Bit is used on
each data word.
Bit 1
Word Length Select Bit #1
(WLSB1)
Bit 0
Word Length Select Bit #0
(WLSB0)
Together
these bits specify the number of bits in each
data word.
1
0
Word
Length
0
0
5 Data
Bits
0
1
6 Data
Bits
1
0
7 Data
Bits
1
1
8 Data
Bits
+0x04
write/read
Modem Control Register
(MCR)
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Loop-Back Enable. When set to "1", the UART
transmitter and receiver are internally
connected together to allow diagnostic
operations. In addition, the UART modem control
outputs are connected to the UART modem control
inputs. CTS is connected to RTS, DTR is
connected to DSR, OUT1 is connected to RI, and
OUT 2 is connected to DCD.
Bit 3
OUT 2. An auxiliary output that the host
processor may set high or low. In the IBM PC
serial adapter (and most clones), OUT 2 is used
to tri-state (disable) the interrupt signal from
the 8250/16450/16550 UART.
Bit 2
OUT 1. An auxiliary output that the host
processor may set high or low. This output is
not used on the IBM PC serial adapter.
Bit 1
Request to Send (RTS). When set to "1", the
output of the UART -RTS line is Low
(Active).
Bit 0
Data Terminal Ready (DTR). When set to "1",
the output of the UART -DTR line is Low
(Active).
+0x05
write/read
Line Status Register
(LSR)
Bit 7
Error in Receiver FIFO. On the 8250/16450
UART, this bit is zero. This bit is set to "1"
when any of the bytes in the FIFO have one or
more of the following error conditions: PE, FE,
or BI.
Bit 6
Transmitter Empty (TEMT). When set to "1",
there are no words remaining in the transmit
FIFO or the transmit shift register. The
transmitter is completely idle.
Bit 5
Transmitter Holding Register Empty
(THRE). When set to "1", the FIFO (or holding
register) now has room for at least one
additional word to transmit. The transmitter may
still be transmitting when this bit is set to
"1".
Bit 4
Break Interrupt (BI). The receiver has
detected a Break signal.
Bit 3
Framing Error (FE). A Start Bit was
detected but the Stop Bit did not appear at the
expected time. The received word is probably
garbled.
Bit 2
Parity Error (PE). The parity bit was
incorrect for the word received.
Bit 1
Overrun Error (OE). A new word was received
and therewas no room in the receive buffer. The
newly-arrived word in the shift register is
discarded. On 8250/16450 UARTs, the word in the
holding register is discarded and the newly-
arrived word is put in the holding
register.
Bit 0
Data Ready (DR) One or more words are in
the receive FIFO that the host may read. A word
must be completely received and moved from the
shift register into the FIFO (or holding
register for 8250/16450 designs) before this bit
is set.
+0x06
write/read
Modem Status Register
(MSR)
Bit 7
Data Carrier Detect (DCD). Reflects the
state of the DCD line on the UART.
Bit 6
Ring Indicator (RI). Reflects the state of
the RI line on the UART.
Bit 5
Data Set Ready (DSR). Reflects the state of
the DSR line on the UART.
Bit 4
Clear To Send (CTS). Reflects the state of
the CTS line on the UART.
Bit 3
Delta Data Carrier Detect (DDCD). Set to
"1" if the -DCD line has changed state one more
more times since the last time the MSR was read
by the host.
Bit 2
Trailing Edge Ring Indicator (TERI). Set to
"1" if the -RI line has had a low to high
transition since the last time the MSR was read
by the host.
Bit 1
Delta Data Set Ready (DDSR). Set to "1" if
the -DSR line has changed state one more more
times since the last time the MSR was read by
the host.
Bit 0
Delta Clear To Send (DCTS). Set to "1" if
the -CTS line has changed state one more more
times since the last time the MSR was read by
the host.
+0x07
write/read
Scratch Register (SCR). This register performs no
function in the UART. Any value can be written by the
host to this location and read by the host later
on.
Beyond the 16550A UART
Although National Semiconductor has not offered any
components compatible with the 16550 that provide additional
features, various other vendors have. Some of these
components are described below. It should be understood that
to effectively utilize these improvements, drivers may have to
be provided by the chip vendor since most of the popular
operating systems do not support features beyond those
provided by the 16550.
ST16650
By default this part is similar to the NS16550A,
but an extended 32-byte send and receive buffer can be
optionally enabled. Made by Startech.
TIL16660
By default this part behaves similar to the
NS16550A, but an extended 64-byte send and receive
buffer can be optionally enabled. Made by Texas
Instruments.
Hayes ESP
This proprietary plug-in card contains a 2048-byte
send and receive buffer, and supports data rates to
230.4Kbit/sec. Made by Hayes.
In addition to these “dumb” UARTs, many vendors produce
intelligent serial communication boards. This type of design
usually provides a microprocessor that interfaces with several
UARTs, processes and buffers the data, and then alerts the
main PC processor when necessary. Because the UARTs are not
directly accessed by the PC processor in this type of
communication system, it is not necessary for the vendor to
use UARTs that are compatible with the 8250, 16450, or the
16550 UART. This leaves the designer free to components that
may have better performance characteristics.
Configuring the <devicename>sio</devicename>
driver
The sio driver provides
support for NS8250-, NS16450-, NS16550 and NS16550A-based EIA
RS-232C (CCITT V.24) communications interfaces. Several
multiport cards are supported as well. See the sio4 manual page for detailed technical
documentation.
Digi International (DigiBoard) PC/8
Contributed by &a.awebster;.26
August 1995.
Here is a config snippet from a machine with a Digi
International PC/8 with 16550. It has 8 modems connected to
these 8 lines, and they work just great. Do not forget to add
options COM_MULTIPORT or it will
not work very well!
device sio4 at isa? port 0x100 tty flags 0xb05
device sio5 at isa? port 0x108 tty flags 0xb05
device sio6 at isa? port 0x110 tty flags 0xb05
device sio7 at isa? port 0x118 tty flags 0xb05
device sio8 at isa? port 0x120 tty flags 0xb05
device sio9 at isa? port 0x128 tty flags 0xb05
device sio10 at isa? port 0x130 tty flags 0xb05
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
The trick in setting this up is that the MSB of the flags
represent the last SIO port, in this case 11 so flags are
0xb05.
Boca 16
Contributed by &a.whiteside;.26
August 1995.
The procedures to make a Boca 16 pord board with FreeBSD
are pretty straightforward, but you will need a couple things
to make it work:
You either need the kernel sources installed so you
can recompile the necessary options or you will need
someone else to compile it for you. The 2.0.5 default
kernel does not come with
multiport support enabled and you will need to add a
device entry for each port anyways.
Two, you will need to know the interrupt and IO
setting for your Boca Board so you can set these options
properly in the kernel.
One important note — the actual UART chips for the Boca 16
are in the connector box, not on the internal board itself. So
if you have it unplugged, probes of those ports will fail. I
have never tested booting with the box unplugged and plugging
it back in, and I suggest you do not either.
If you do not already have a custom kernel configuration
file set up, refer to Kernel Configuration for
general procedures. The following are the specifics for the
Boca 16 board and assume you are using the kernel name
MYKERNEL and editing with vi.
Add the line
options COM_MULTIPORT
to the config file.
Where the current device
sion lines are,
you will need to add 16 more devices. Only
the last device includes the interrupt vector for the
board. (See the sio4 manual page for detail as
to why.) The following example is for a Boca Board with
an interrupt of 3, and a base IO address 100h. The IO
address for Each port is +8 hexadecimal from the
previous port, thus the 100h, 108h, 110h... addresses.
device sio1 at isa? port 0x100 tty flags 0x1005
device sio2 at isa? port 0x108 tty flags 0x1005
device sio3 at isa? port 0x110 tty flags 0x1005
device sio4 at isa? port 0x118 tty flags 0x1005
…
device sio15 at isa? port 0x170 tty flags 0x1005
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
The flags entry
must be changed from this example
unless you are using the exact same sio assignments.
Flags are set according to 0xMYY
where M indicates the minor number
of the master port (the last port on a Boca 16) and
YY indicates if FIFO is enabled or
disabled(enabled), IRQ sharing is used(yes) and if there
is an AST/4 compatible IRQ control register(no). In this
example,
flags 0x1005 indicates that the master port is
sio16. If I added another board and assigned sio17
through sio28, the flags for all 16 ports on
that board would be 0x1C05, where
1C indicates the minor number of the master port. Do not
change the 05 setting.
Save and complete the kernel configuration,
recompile, install and reboot. Presuming you have
successfully installed the recompiled kernel and have it
set to the correct address and IRQ, your boot message
should indicate the successful probe of the Boca ports
as follows: (obviously the sio numbers, IO and IRQ could
be different)
sio1 at 0x100-0x107 flags 0x1005 on isa
sio1: type 16550A (multiport)
sio2 at 0x108-0x10f flags 0x1005 on isa
sio2: type 16550A (multiport)
sio3 at 0x110-0x117 flags 0x1005 on isa
sio3: type 16550A (multiport)
sio4 at 0x118-0x11f flags 0x1005 on isa
sio4: type 16550A (multiport)
sio5 at 0x120-0x127 flags 0x1005 on isa
sio5: type 16550A (multiport)
sio6 at 0x128-0x12f flags 0x1005 on isa
sio6: type 16550A (multiport)
sio7 at 0x130-0x137 flags 0x1005 on isa
sio7: type 16550A (multiport)
sio8 at 0x138-0x13f flags 0x1005 on isa
sio8: type 16550A (multiport)
sio9 at 0x140-0x147 flags 0x1005 on isa
sio9: type 16550A (multiport)
sio10 at 0x148-0x14f flags 0x1005 on isa
sio10: type 16550A (multiport)
sio11 at 0x150-0x157 flags 0x1005 on isa
sio11: type 16550A (multiport)
sio12 at 0x158-0x15f flags 0x1005 on isa
sio12: type 16550A (multiport)
sio13 at 0x160-0x167 flags 0x1005 on isa
sio13: type 16550A (multiport)
sio14 at 0x168-0x16f flags 0x1005 on isa
sio14: type 16550A (multiport)
sio15 at 0x170-0x177 flags 0x1005 on isa
sio15: type 16550A (multiport)
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
sio16: type 16550A (multiport master)
If the messages go by too fast to
see,
&prompt.root; dmesg | more
will
show you the boot messages.
Next, appropriate entries in
/dev for the devices must be made
using the /dev/MAKEDEV script.
After becoming root:
&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tty1
&prompt.root; ./MAKEDEV cua1
(everything in between)
&prompt.root; ./MAKEDEV ttyg
&prompt.root; ./MAKEDEV cuag
If you do not want or need callout
devices for some reason, you can dispense with making
the cua* devices.
If you want a quick and sloppy way to make sure the
devices are working, you can simply plug a modem into
each port and (as root)
&prompt.root; echo at > ttyd*
for each device you have made. You
should see the RX lights flash for
each working port.
Configuring the <devicename>cy</devicename>
driver
Contributed by &a.alex;.6 June
1996.
The Cyclades multiport cards are based on the
cy driver instead of the usual
sio driver used by other multiport
cards. Configuration is a simple matter of:
Add the cy device to
your kernel
configuration (note that your irq and
iomem settings may differ).
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
Rebuild
and install the new kernel.
Make the device
nodes by typing (the following example
assumes an 8-port board):
&prompt.root; cd /dev
&prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
If appropriate, add dialup
entries to /etc/ttys
by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example:
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
…
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
Reboot with the new kernel.
* Parallel ports
* Modems
* Network cards
* Keyboards
* Mice
* Other
Storage Devices
Using ESDI hard disks
Copyright © 1995, &a.wilko;.24
September 1995.
ESDI is an acronym that means Enhanced Small Device Interface.
It is loosely based on the good old ST506/412 interface originally
devised by Seagate Technology, the makers of the first affordable
5.25" winchester disk.
The acronym says Enhanced, and rightly so. In the first place
the speed of the interface is higher, 10 or 15 Mbits/second
instead of the 5 Mbits/second of ST412 interfaced drives. Secondly
some higher level commands are added, making the ESDI interface
somewhat 'smarter' to the operating system driver writers. It is
by no means as smart as SCSI by the way. ESDI is standardized by
ANSI.
Capacities of the drives are boosted by putting more sectors
on each track. Typical is 35 sectors per track, high capacity
drives I have seen were up to 54 sectors/track.
Although ESDI has been largely obsoleted by IDE and SCSI
interfaces, the availability of free or cheap surplus drives makes
them ideal for low (or now) budget systems.
Concepts of ESDI
Physical connections
The ESDI interface uses two cables connected to each
drive. One cable is a 34 pin flat cable edge connector that
carries the command and status signals from the controller to
the drive and vice-versa. The command cable is daisy chained
between all the drives. So, it forms a bus onto which all
drives are connected.
The second cable is a 20 pin flat cable edge connector
that carries the data to and from the drive. This cable is
radially connected, so each drive has its own direct
connection to the controller.
To the best of my knowledge PC ESDI controllers are
limited to using a maximum of 2 drives per controller. This is
compatibility feature(?) left over from the WD1003 standard
that reserves only a single bit for device addressing.
Device addressing
On each command cable a maximum of 7 devices and 1
controller can be present. To enable the controller to
uniquely identify which drive it addresses, each ESDI device
is equipped with jumpers or switches to select the devices
address.
On PC type controllers the first drive is set to address
0, the second disk to address 1. Always
make sure you set each disk to an unique address!
So, on a PC with its two drives/controller maximum the first
drive is drive 0, the second is drive 1.
Termination
The daisy chained command cable (the 34 pin cable
remember?) needs to be terminated at the last drive on the
chain. For this purpose ESDI drives come with a termination
resistor network that can be removed or disabled by a jumper
when it is not used.
So, one and only one drive,
the one at the farthest end of the command cable has its
terminator installed/enabled. The controller automatically
terminates the other end of the cable. Please note that this
implies that the controller must be at one end of the cable
and not in the middle.
Using ESDI disks with FreeBSD
Why is ESDI such a pain to get working in the first
place?
People who tried ESDI disks with FreeBSD are known to have
developed a profound sense of frustration. A combination of
factors works against you to produce effects that are hard to
understand when you have never seen them before.
This has also led to the popular legend ESDI and FreeBSD is
a plain NO-GO. The following sections try to list all the
pitfalls and solutions.
ESDI speed variants
As briefly mentioned before, ESDI comes in two speed
flavors. The older drives and controllers use a 10
Mbits/second data transfer rate. Newer stuff uses 15
Mbits/second.
It is not hard to imagine that 15 Mbits/second drive cause
problems on controllers laid out for 10 Mbits/second. As
always, consult your controller and drive documentation to see if
things match.
Stay on track
Mainstream ESDI drives use 34 to 36 sectors per track.
Most (older) controllers cannot handle more than this number
of sectors. Newer, higher capacity, drives use higher numbers
of sectors per track. For instance, I own a 670 Mb drive that
has 54 sectors per track.
In my case, the controller could not handle this number of
sectors. It proved to work well except that it only used 35
sectors on each track. This meant losing a lot of disk
space.
Once again, check the documentation of your hardware for
more info. Going out-of-spec like in the example might or
might not work. Give it a try or get another more capable
controller.
Hard or soft sectoring
Most ESDI drives allow hard or soft sectoring to be
selected using a jumper. Hard sectoring means that the drive
will produce a sector pulse on the start of each new sector.
The controller uses this pulse to tell when it should start to
write or read.
Hard sectoring allows a selection of sector size (normally
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
512 byte sectors. The number of sectors per track also varies
while still using the same number of bytes per formatted
sector. The number of unformatted bytes
per sector varies, dependent on your controller it needs more
or less overhead bytes to work correctly. Pushing more
sectors on a track of course gives you more usable space, but
might give problems if your controller needs more bytes than
the drive offers.
In case of soft sectoring, the controller itself
determines where to start/stop reading or writing. For ESDI
hard sectoring is the default (at least on everything I came
across). I never felt the urge to try soft sectoring.
In general, experiment with sector settings before you
install FreeBSD because you need to re-run the low-level
format after each change.
Low level formatting
ESDI drives need to be low level formatted before they are
usable. A reformat is needed whenever you figgle with the
number of sectors/track jumpers or the physical orientation of
the drive (horizontal, vertical). So, first think, then
format. The format time must not be underestimated, for big
disks it can take hours.
After a low level format, a surface scan is done to find
and flag bad sectors. Most disks have a manufacturer bad block
list listed on a piece of paper or adhesive sticker. In
addition, on most disks the list is also written onto the
disk. Please use the manufacturer's list. It is much easier to
remap a defect now than after FreeBSD is installed.
Stay away from low-level formatters that mark all sectors
of a track as bad as soon as they find one bad sector. Not
only does this waste space, it also and more importantly
causes you grief with bad144 (see the section on
bad144).
Translations
Translations, although not exclusively a ESDI-only
problem, might give you real trouble. Translations come in
multiple flavors. Most of them have in common that they
attempt to work around the limitations posed upon disk
geometries by the original IBM PC/AT design (thanks
IBM!).
First of all there is the (in)famous 1024 cylinder limit.
For a system to be able to boot, the stuff (whatever
operating system) must be in the first 1024 cylinders of a
disk. Only 10 bits are available to encode the cylinder
number. For the number of sectors the limit is 64 (0-63). When
you combine the 1024 cylinder limit with the 16 head limit
(also a design feature) you max out at fairly limited disk
sizes.
To work around this problem, the manufacturers of ESDI PC
controllers added a BIOS prom extension on their boards. This
BIOS extension handles disk I/O for booting (and for some
operating systems all disk I/O)
by using translation. For instance, a big drive might be
presented to the system as having 32 heads and 64
sectors/track. The result is that the number of cylinders is
reduced to something below 1024 and is therefore usable by the
system without problems. It is noteworthy to know that FreeBSD
does not use the BIOS after its kernel has started. More on
this later.
A second reason for translations is the fact that most
older system BIOSes could only handle drives with 17 sectors
per track (the old ST412 standard). Newer system BIOSes
usually have a user-defined drive type (in most cases this is
drive type 47).
Whatever you do to translations after reading
this document, keep in mind that if you have multiple
operating systems on the same disk, all must use the same
translation
While on the subject of translations, I have seen one
controller type (but there are probably more like this) offer
the option to logically split a drive in multiple partitions
as a BIOS option. I had select 1 drive == 1 partition because
this controller wrote this info onto the disk. On power-up it
read the info and presented itself to the system based on the
info from the disk.
Spare sectoring
Most ESDI controllers offer the possibility to remap bad
sectors. During/after the low-level format of the disk bad
sectors are marked as such, and a replacement sector is put in
place (logically of course) of the bad one.
In most cases the remapping is done by using N-1 sectors
on each track for actual data storage, and sector N itself is
the spare sector. N is the total number of sectors physically
available on the track. The idea behind this is that the
operating system sees a 'perfect' disk without bad sectors. In
the case of FreeBSD this concept is not usable.
The problem is that the translation from bad to good is performed by the BIOS of the
ESDI controller. FreeBSD, being a true 32 bit operating
system, does not use the BIOS after it has been booted.
Instead, it has device drivers that talk directly to the
hardware.
So: don't use spare sectoring, bad block
remapping or whatever it may be called by the controller
manufacturer when you want to use the disk for
FreeBSD.
Bad block handling
The preceding section leaves us with a problem. The
controller's bad block handling is not usable and still
FreeBSD's filesystems assume perfect media without any flaws.
To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a
Digital Equipment standard for bad block handling) scans a
FreeBSD slice for bad blocks. Having found these bad blocks,
it writes a table with the offending block numbers to the end
of the FreeBSD slice.
When the disk is in operation, the disk accesses are
checked against the table read from the disk. Whenever a
block number is requested that is in the bad144 list, a
replacement block (also from the end of the FreeBSD slice) is
used. In this way, the bad144 replacement scheme presents
'perfect' media to the FreeBSD filesystems.
There are a number of potential pitfalls associated with
the use of bad144. First of all, the slice cannot have more
than 126 bad sectors. If your drive has a high number of bad
sectors, you might need to divide it into multiple FreeBSD
slices each containing less than 126 bad sectors. Stay away
from low-level format programs that mark
every sector of a track as bad when they
find a flaw on the track. As you can imagine, the 126 limit
is quickly reached when the low-level format is done this
way.
Second, if the slice contains the root filesystem, the
slice should be within the 1024 cylinder BIOS limit. During
the boot process the bad144 list is read using the BIOS and
this only succeeds when the list is within the 1024 cylinder
limit.
The restriction is not that only the root
filesystem must be within the 1024
cylinder limit, but rather the entire
slice that contains the root
filesystem.
Kernel configuration
ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The
wd driver should work for all
WD1003 compatible interfaces.
Most hardware is jumperable for one of two different I/O
address ranges and IRQ lines. This allows you to have two wd
type controllers in one system.
When your hardware allows non-standard strappings, you can
use these with FreeBSD as long as you enter the correct info
into the kernel config file. An example from the kernel config
file (they live in /sys/i386/conf
BTW).
# First WD compatible controller
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
disk wd0 at wdc0 drive 0
disk wd1 at wdc0 drive 1
# Second WD compatible controller
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
disk wd2 at wdc1 drive 0
disk wd3 at wdc1 drive 1
Particulars on ESDI hardware
Adaptec 2320 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a ACB-2320. No other operating system was
present on the disk.
To do so I low level formatted the disk using NEFMT.EXE
(ftpable from
www.adaptec.com) and answered NO to the
question whether the disk should be formatted with a spare
sector on each track. The BIOS on the ACD-2320 was disabled. I
used the free configurable option in the system BIOS to
allow the BIOS to boot it.
Before using NEFMT.EXE I tried to format the disk using
the ACB-2320 BIOS builtin formatter. This proved to be a show
stopper, because it did not give me an option to disable spare
sectoring. With spare sectoring enabled the FreeBSD
installation process broke down on the bad144 run.
Please check carefully which ACB-232xy variant you have.
The x is either 0 or 2, indicating a controller without or
with a floppy controller on board.
The y is more interesting. It can either be a blank, a
A-8 or a D. A blank indicates a plain 10 Mbits/second
controller. An A-8 indicates a 15 Mbits/second controller
capable of handling 52 sectors/track. A D means a 15
Mbits/second controller that can also handle drives with >
36 sectors/track (also 52 ?).
All variations should be capable of using 1:1
interleaving. Use 1:1, FreeBSD is fast enough to handle
it.
Western Digital WD1007 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a WD1007 controller. To be precise, it was a
WD1007-WA2. Other variations of the WD1007 do exist.
To get it to work, I had to disable the sector translation
and the WD1007's onboard BIOS. This implied I could not use
the low-level formatter built into this BIOS. Instead, I
grabbed WDFMT.EXE from www.wdc.com Running this formatted my
drive just fine.
Ultrastor U14F controllers
According to multiple reports from the net, Ultrastor ESDI
boards work OK with FreeBSD. I lack any further info on
particular settings.
Further reading
If you intend to do some serious ESDI hacking, you might
want to have the official standard at hand:
The latest ANSI X3T10 committee document is:
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11]
On Usenet the newsgroup comp.periphs is a noteworthy
place to look for more info.
The World Wide Web (WWW) also proves to be a very handy info
source: For info on Adaptec ESDI controllers see http://www.adaptec.com/.
For info on Western Digital controllers see http://www.wdc.com/.
Thanks to...
Andrew Gordon for sending me an Adaptec 2320 controller and
ESDI disk for testing.
What is SCSI?
Copyright © 1995, &a.wilko;.July
6, 1996.
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 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 million transfers per second
(20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers
per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold
today are single-ended Ultra SCSI (8 or 16 bits).
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.
Components of SCSI
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.
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.
SCSI bus types
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:
FWD: Fast Wide Differential
FND: Fast Narrow Differential
SE: Single Ended
FN: Fast Narrow
etc.
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 million transfers/second are also
emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI).
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.
Single ended buses
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
million transfers/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.
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 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.
Differential buses
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.
Terminators
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. Many SCSI devices come 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 not mix 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: every
single line on the SCSI bus has 2 (two) terminators, one at
each end of the bus. 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. (Note the
“potential” here; the nastiest part is that it may or may not
work.)
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.
Termination is to be done on a per-line basis. This
means if you have both narrow and wide buses connected to
the same host adapter, you need to enable termination on the
higher 8 bits of the bus on the adapter (as well as the last
devices on each bus, of course).
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 are software
configurable, using some sort of setup tool. Some will even
auto-detect the cables attached to the connectors and
automatically set up the termination as necessary. At any
rate, consult your documentation!
Terminator power
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.
Device addressing
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. Some SCSI host adapters let you change
the target ID from the boot menu. (Yet some others will not
let you change the ID from 7.) 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 (usually 16).
A narrow SCSI device can not communicate with a SCSI
device with a target ID larger than 7. This means it is
generally not a good idea to move your SCSI host adapter's
target ID to something higher than 7 (or your CD-ROM will
stop working).
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. Note however that the
lower 8 IDs have higher priorities than the higher 8 IDs on a
wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI
system. (If you you are wondering why the lower 8 have higher
priority, read the previous paragraph for a hint.)
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.
Bus layout
SCSI buses are linear. So, not shaped like Y-junctions,
star topologies, rings, cobwebs or whatever else people might
want to invent. One of the most common mistakes is for people
with wide-SCSI host adapters to connect devices on all three
connecters (external connector, internal wide connector,
internal narrow connector). Don't do that. It may appear to
work if you are really lucky, but I can almost guarantee that
your system will stop functioning at the most unfortunate
moment (this is also known as “Murphy's law”).
You might notice that the terminator issue discussed
earlier becomes rather hairy if your bus is not linear. Also,
if you have more connectors than devices on your internal SCSI
cable, make sure you attach devices on connectors on both ends
instead of using the connectors in the middle and let one or
both ends dangle. This will screw up the termination of the
bus.
The electrical characteristics, its noise margins and
ultimately the reliability of it all are tightly related to
linear bus rule.
Stick to the linear bus
rule!
Using SCSI with FreeBSD
About translations, BIOSes and magic...
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
translated 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 all operating systems on the disk use
the same translation 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:
aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512
Newer kernels usually do not report this information. e.g.
(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)
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 if the BIOS is never going to know about
this disk, (e.g. it is not a booting disk) to
supply a fictitious geometry that is convenient.
SCSI subsystem design
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), CD-ROMs (cd) etc. In case you are wondering where you
can find this stuff, it all lives in
/sys/scsi. 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.
Kernel configuration
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
not 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.
Note that most of the EISA/PCI drivers (namely
ahb, ahc,
ncr and
amd will automatically obtain the
correct parameters from the host adapters themselves at boot
time; thus, you just need to write, for instance,
controller ahc0.
An example loosely based on the FreeBSD 2.2.5-Release
kernel config file LINT with some added comments (between
[]):
# 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!)
# amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T)
# bt: Most Buslogic controllers
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
# ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards
# 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/294x/394x etc controller]
controller ahc0
[For an NCR/Symbios 53c875 based controller]
controller ncr0
[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 ncr0
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 ncr0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CD-ROM found, no wiring]
The example above tells the kernel to look for a ahc
(Adaptec 274x) controller, then for an NCR/Symbios board, and
so on. The lines following the controller specifications tell
the kernel to configure specific devices but
only 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.
Wired down devices need not be found 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 no 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 /etc/fstab
each time.
Although the old style still works, you are
strongly 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.
[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 CD-ROM]
device cd0 #Only need one of these, the code dynamically grows
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 man 4 scsi to check for
the latest info on the SCSI subsystem. For more detailed info
on host adapter drivers use eg man 4
ahc for info on the Adaptec 294x driver.
Tuning your SCSI kernel setup
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, CD-ROM 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:
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
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
CD-ROM 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.
Rogue SCSI devices
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:
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
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 CD-ROM 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.
Multiple LUN devices
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 initialized like below:
{
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
"mx1", SC_ONE_LU
}
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:
{
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
"sd", SC_MORE_LUS
}
The kernel on boot scans the inquiry data it receives
against the table and acts accordingly. See the source for
more info.
Tagged command queueing
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.
Busmaster host adapters
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:
options "TUNE_1542" #dynamic tune of bus DMA speed
Check the man pages for the host adapter that you use. Or
better still, use the ultimate documentation (read: driver
source).
Tracking down problems
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.
Check for loose connectors and cables.
Check and double check the location and number of your
terminators.
Check if your bus has at least one supplier of
terminator power (especially with external
terminators.
Check if no double target IDs are used.
Check if all devices to be used are powered up.
Make a minimal bus config with as little devices as
possible.
If possible, configure your host adapter to use slow
bus speeds.
Disable tagged command queuing to make things as
simple as possible (for a NCR hostadapter based system see
man ncrcontrol)
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 /sys/scsi/scsidebug.h.
If it probes but just does not work, you can use the
scsi8 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 man 4
scsi for more exact information. Also look at
man 8 scsi.
Further reading
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
13th Floor
11 West 42nd Street
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:
AT Attachment (ATA or IDE) [X3.221-1994]
(Approved)
ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991]
(Approved)
Small Computer System Interface — 2 (SCSI-2)
[X3.131-1994] (Approved)
SCSI-2 Common Access Method Transport and SCSI
Interface Module (CAM) [X3T10/792D Rev 11]
Other publications that might provide you with
additional information are:
“SCSI: Understanding the Small Computer System
Interface”, written by NCR Corporation. Available from:
Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201)
767-5937 ISBN 0-13-796855-8
“Basics of SCSI”, a SCSI tutorial written by Ancot
Corporation Contact Ancot for availability information at:
Phone: (415) 322-5322 Fax: (415) 322-0455
“SCSI Interconnection Guide Book”, an AMP publication
(dated 4/93, Catalog 65237) that lists the various SCSI
connectors and suggests cabling schemes. Available from
AMP at (800) 522-6752 or (717) 564-0100
“Fast Track to SCSI”, A Product Guide written by
Fujitsu. Available from: Prentice Hall, Englewood Cliffs,
NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X
“The SCSI Bench Reference”, “The SCSI Encyclopedia”,
and the “SCSI Tutor”, ENDL Publications, 14426 Black
Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642
“Zadian SCSI Navigator” (quick ref. book) and
“Discover the Power of SCSI” (First book along with a
one-hour video and tutorial book), Zadian Software, Suite
214, 1210 S. Bascom Ave., San Jose, CA 92128, (408)
293-0800
On Usenet the newsgroups comp.periphs.scsi and
comp.periphs are
noteworthy places to look for more info. You can also find the
SCSI-Faq there, which 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.
* Disk/tape controllers
* SCSI
* IDE
* Floppy
Hard drives
SCSI hard drives
Contributed by &a.asami;.17 February
1998.
As mentioned in the SCSI
section, virtually all SCSI hard drives sold today are SCSI-2
compliant and thus will work fine as long as you connect them to
a supported SCSI host adapter. Most problems people encounter
are either due to badly designed cabling (cable too long, star
topology, etc.), insufficient termination, or defective parts.
Please refer to the SCSI
section first if your SCSI hard drive is not working. However,
there are a couple of things you may want to take into account
before you purchase SCSI hard drives for your system.
Rotational speed
Rotational speeds of SCSI drives sold today range from
around 4,500RPM to 10,000RPM. Most of them are either 5,400RPM
or 7,200RPM. Even though the 7,200RPM drives can generally
transfer data faster, they run considerably hotter than their
5,400RPM counterparts. A large fraction of today's disk drive
malfunctions are heat-related. If you do not have very good
cooling in your PC case, you may want to stick with 5,400RPM
or slower drives.
Note that newer drives, with higher areal recording
densities, can deliver much more bits per rotation than older
ones. Today's top-of-line 5,400RPM drives can sustain a
throughput comparable to 7,200RPM drives of one or two model
generations ago. The number to find on the spec sheet for
bandwidth is “internal data (or transfer) rate”. It is
usually in megabits/sec so divide it by 8 and you'll get the
rough approximation of how much megabytes/sec you can get out
of the drive.
(If you are a speed maniac and want a 10,000RPM drive for
your cute little peecee, be my guest; however, those drives
become extremely hot. Don't even think about it if you don't
have a fan blowing air directly at the
drive or a properly ventilated disk enclosure.)
Obviously, the latest 10,000RPM drives and 7,200RPM drives
can deliver more data than the latest 5,400RPM drives, so if
absolute bandwidth is the necessity for your applications, you
have little choice but to get the faster drives. Also, if you
need low latency, faster drives are better; not only do they
usually have lower average seek times, but also the rotational
delay is one place where slow-spinning drives can never beat a
faster one. (The average rotational latency is half the time
it takes to rotate the drive once; thus, it's 3 milliseconds
for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for
5,400RPM drives.) Latency is seek time plus rotational delay.
Make sure you understand whether you need low latency or more
accesses per second, though; in the latter case (e.g., news
servers), it may not be optimal to purchase one big fast
drive. You can achieve similar or even better results by
using the ccd (concatenated disk) driver to create a striped
disk array out of multiple slower drives for comparable
overall cost.
Make sure you have adequate air flow around the drive,
especially if you are going to use a fast-spinning drive. You
generally need at least 1/2" (1.25cm) of spacing above and
below a drive. Understand how the air flows through your PC
case. Most cases have the power supply suck the air out of
the back. See where the air flows in, and put the drive where
it will have the largest volume of cool air flowing around it.
You may need to seal some unwanted holes or add a new fan for
effective cooling.
Another consideration is noise. Many 7,200 or faster
drives generate a high-pitched whine which is quite unpleasant
to most people. That, plus the extra fans often required for
cooling, may make 7,200 or faster drives unsuitable for some
office and home environments.
Form factor
Most SCSI drives sold today are of 3.5" form factor. They
come in two different heights; 1.6" (“half-height”) or 1"
(“low-profile”). The half-height drive is the same height as a
CD-ROM drive. However, don't forget the spacing rule
mentioned in the previous section. If you have three standard
3.5" drive bays, you will not be able to put three half-height
drives in there (without frying them, that is).
Interface
The majority of SCSI hard drives sold today are Ultra or
Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is
20MB/sec, and Ultra-wide SCSI is 40MB/sec. There is no
difference in max cable length between Ultra and Ultra-wide;
however, the more devices you have on the same bus, the sooner
you will start having bus integrity problems. Unless you have
a well-designed disk enclosure, it is not easy to make more
than 5 or 6 Ultra SCSI drives work on a single bus.
On the other hand, if you need to connect many drives,
going for Fast-wide SCSI may not be a bad idea. That will
have the same max bandwidth as Ultra (narrow) SCSI, while
electronically it's much easier to get it “right”. My advice
would be: if you want to connect many disks, get wide SCSI
drives; they usually cost a little more but it may save you
down the road. (Besides, if you can't afford the cost
difference, you shouldn't be building a disk array.)
There are two variant of wide SCSI drives; 68-pin and
80-pin SCA (Single Connector Attach). The SCA drives don't
have a separate 4-pin power connector, and also read the SCSI
ID settings through the 80-pin connector. If you are really
serious about building a large storage system, get SCA drives
and a good SCA enclosure (dual power supply with at least one
extra fan). They are more electronically sound than 68-pin
counterparts because there is no “stub” of the SCSI bus inside
the disk canister as in arrays built from 68-pin drives. They
are easier to install too (you just need to screw the drive in
the canister, instead of trying to squeeze in your fingers in
a tight place to hook up all the little cables (like the SCSI
ID and disk activity LED lines).
* IDE hard drives
Tape drives
Contributed by &a.jmb;.2 July
1996.
General tape access commands
mt1 provides generic access to the tape
drives. Some of the more common commands are
rewind, erase, and
status. See the mt1
manual page for a detailed description.
Controller Interfaces
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
Disk/tape
controllers.
SCSI drives
The st4 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
st4 manual page for a detailed
description.
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.
4mm (DAT: Digital Audio Tape)
Archive
Python
HP
C1533A
HP
C1534A
HP
35450A
HP
35470A
HP
35480A
SDT-5000
Wangtek
6200
8mm (Exabyte)
EXB-8200
EXB-8500
EXB-8505
QIC (Quarter-Inch Cartridge)
Archive
Ananconda 2750
Archive Viper
60
Archive Viper
150
Archive Viper
2525
Tandberg
TDC 3600
Tandberg
TDC 3620
Tandberg
TDC 4222
Wangtek
5525ES
DLT (Digital Linear Tape)
Digital
TZ87
Mini-Cartridge
Conner CTMS
3200
Exabyte
2501
Autoloaders/Changers
Hewlett-Packard
HP C1553A Autoloading DDS2
* IDE drives
Floppy drives
Conner
420R
* Parallel port drives
Detailed Information
Archive Anaconda 2750
The boot message identifier for this drive is
ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI
2
This is a QIC tape drive.
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.
Data transfer rate is 350kB/s using
dump8. Rates of 530kB/s have been
reported when using Amanda
Production of this drive has been discontinued.
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.
Two kernel code changes are required to use this drive.
This drive will not work as delivered.
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.
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.
*** 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,
Reported by: &a.jmb;
Archive Python
The boot message identifier for this drive is
ARCHIVE Python 28454-XXX4ASB type
1 removable SCSI 2 density code 0x8c,
512-byte blocks
This is a DDS-1 tape drive.
Native capacity is 2.5GB on 90m tapes.
Data transfer rate is XXX.
This drive was repackaged by Sun Microsystems as model
411.
Reported by: Bob Bishop rb@gid.co.uk
Archive Viper 60
The boot message identifier for this drive is
ARCHIVE VIPER 60 21116 -007 type 1
removable SCSI 1
This is a QIC tape drive.
Native capacity is 60MB.
Data transfer rate is XXX.
Production of this drive has been discontinued.
Reported by: Philippe Regnauld regnauld@hsc.fr
Archive Viper 150
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.
This is a QIC tape drive.
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.
Data transfer rate is 100kB/s
This drive reads and writes DC6150 (150MB) and DC6250
(250MB) tapes.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Under FreeBSD 2.2-current, use mt
blocksize 512 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.
Production of this drive has been discontinued.
Reported by: Pedro A M Vazquez
vazquez@IQM.Unicamp.BR
Mike Smith
msmith@atrad.adelaide.edu.au
Archive Viper 2525
The boot message identifier for this drive is ARCHIVE
VIPER 2525 25462 -011 type 1 removable SCSI 1
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s at 90 inches/sec.
The drive reads QIC-525, QIC-150, QIC-120 and QIC-24
tapes. Writes QIC-525, QIC-150, and QIC-120.
Firmware revisions prior to 25462 -011 are bug ridden
and will not function properly.
Production of this drive has been discontinued.
Conner 420R
The boot message identifier for this drive is Conner
tape.
This is a floppy controller, minicartridge tape
drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-80 tape cartridges.
Reported by: Mark Hannon mark@seeware.DIALix.oz.au
Conner CTMS 3200
The boot message identifier for this drive is CONNER CTMS
3200 7.00 type 1 removable SCSI 2.
This is a minicartridge tape drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-3080 tape cartridges.
Reported by: Thomas S. Traylor tst@titan.cs.mci.com
<ulink
URL="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink>
The boot message identifier for this drive is DEC TZ87
(C) DEC 9206 type 1 removable SCSI 2 density code
0x19
This is a DLT tape drive.
Native capacity is 10GB.
This drive supports hardware data compression.
Data transfer rate is 1.2MB/s.
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.
Reported by: &a.wilko;
<ulink
URL="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink>
The boot message identifier for this drive is EXABYTE
EXB-2501
This is a mini-cartridge tape drive.
Native capacity is 1GB when using MC3000XL
minicartridges.
Data transfer rate is XXX
This drive can read and write DC2300 (550MB), DC2750
(750MB), MC3000 (750MB), and MC3000XL (1GB)
minicartridges.
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
&prompt.root; mt -f /dev/st0ctl.0 blocksize 1024
Before using a minicartridge for the first time, the
minicartridge must be formated. FreeBSD 2.1.0-RELEASE and
earlier:
&prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0"
(Alternatively, fetch a copy of the scsiformat shell script from FreeBSD
2.1.5/2.2.) FreeBSD 2.1.5 and later:
&prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl
Right now, this drive cannot really be recommended for
FreeBSD.
Reported by: Bob Beaulieu ez@eztravel.com
Exabyte EXB-8200
The boot message identifier for this drive is EXABYTE
EXB-8200 252X type 1 removable SCSI 1
This is an 8mm tape drive.
Native capacity is 2.3GB.
Data transfer rate is 270kB/s.
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).
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.
Production of this drive has been discontinued.
Reported by: Mike Smith
msmith@atrad.adelaide.edu.au
Exabyte EXB-8500
The boot message identifier for this drive is EXABYTE
EXB-8500-85Qanx0 0415 type 1 removable SCSI 2
This is an 8mm tape drive.
Native capacity is 5GB.
Data transfer rate is 300kB/s.
Reported by: Greg Lehey grog@lemis.de
<ulink
URL="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink>
The boot message identifier for this drive is EXABYTE
EXB-85058SQANXR1 05B0 type 1 removable SCSI 2
This is an 8mm tape drive which supports compression, and
is upward compatible with the EXB-5200 and EXB-8500.
Native capacity is 5GB.
The drive supports hardware data compression.
Data transfer rate is 300kB/s.
Reported by: Glen Foster gfoster@gfoster.com
Hewlett-Packard HP C1533A
The boot message identifier for this drive is HP C1533A
9503 type 1 removable SCSI 2.
This is a DDS-2 tape drive. DDS-2 means hardware data
compression and narrower tracks for increased data
capacity.
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s.
This drive is used in Hewlett-Packard's SureStore 6000eU
and 6000i tape drives and C1533A DDS-2 DAT drive.
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.
switch 1
switch 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, with host
control
Off
Off
Compression disabled at power-on, no host
control
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.
See HP
SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 2 of these drives. Neither lasted more than 5
months.
Reported by: &a.se;
Hewlett-Packard HP 1534A
The boot message identifier for this drive is HP HP35470A
T503 type 1 removable SCSI 2 Sequential-Access density code
0x13, variable blocks.
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive and HP C1536A DDS format DAT drive.
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?)
Reported by Gary Crutcher gcrutchr@nightflight.com
Hewlett-Packard HP C1553A Autoloading DDS2
The boot message identifier for this drive is "".
This is a DDS-2 tape drive with a tape changer. DDS-2
means hardware data compression and narrower tracks for
increased data capacity.
Native capacity is 24GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s (native).
This drive is used in Hewlett-Packard's SureStore 12000e
tape drive.
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.
There are four internal switches. These should be set: 1
ON; 2 ON; 3 ON; 4 OFF.
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:
#!/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"
Hewlett-Packard HP 35450A
The boot message identifier for this drive is HP HP35450A
-A C620 type 1 removable SCSI 2 Sequential-Access density
code 0x13
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 1.2GB.
Data transfer rate is 160kB/s.
Reported by: mark thompson
mark.a.thompson@pobox.com
Hewlett-Packard HP 35470A
The boot message identifier for this drive is HP HP35470A
9 09 type 1 removable SCSI 2
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive, and HP C1536A DDS format DAT drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 5 of these drives. None lasted more than 9
months.
Reported by: David Dawes dawes@rf900.physics.usyd.edu.au
(9 09)
Hewlett-Packard HP 35480A
The boot message identifier for this drive is HP HP35480A
1009 type 1 removable SCSI 2 Sequential-Access density
code 0x13.
This is a DDS-DC tape drive. DDS-DC is DDS-1 with
hardware data compression. DDS-1 is the original DAT tape
format.
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 HP
C1533A for the proper switch settings.
Data transfer rate is 183kB/s.
This drive is used in Hewlett-Packard's SureStore 5000eU
and 5000i
tape drives and C35480A DDS format DAT drive..
This drive will occasionally hang during a tape eject
operation (mt offline).
Pressing the front panel button will eject the tape and bring
the tape drive back to life.
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.
<ulink
URL="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink>
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.
The boot message identifier for this drive is SONY
SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access
density code 0x13
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
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.
In order to get this drive to stream, set the blocksize to
512 bytes (mt blocksize 512)
reported by Kenneth Merry
ken@ulc199.residence.gatech.edu
SONY SDT-5000 327M information reported by Charles
Henrich henrich@msu.edu
Reported by: &a.jmz;
Tandberg TDC 3600
The boot message identifier for this drive is TANDBERG
TDC 3600 =08: type 1 removable SCSI 2
This is a QIC tape drive.
Native capacity is 150/250MB.
This drive has quirks which are known and work around code
is present in the scsi tape device driver (st4). Upgrading the firmware to XXX
version will fix the quirks and provide SCSI 2
capabilities.
Data transfer rate is 80kB/s.
IBM and Emerald units will not work. Replacing the
firmware EPROM of these units will solve the problem.
Reported by: Michael Smith
msmith@atrad.adelaide.edu.au
Tandberg TDC 3620
This is very similar to the Tandberg TDC 3600
drive.
Reported by: &a.joerg;
Tandberg TDC 4222
The boot message identifier for this drive is TANDBERG
TDC 4222 =07 type 1 removable SCSI 2
This is a QIC tape drive.
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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4)
beginning with FreeBSD 2.2-current. For previous versions of
FreeBSD, use mt to read one
block from the tape, rewind the tape, and then execute the
backup program (mt fsr 1; mt rewind; dump
...)
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.
Reported by: &a.joerg;
Wangtek 5525ES
The boot message identifier for this drive is WANGTEK
5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code
0x11, 1024-byte blocks
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s.
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 (mt erase) 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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Other firmware revisions that are known to work are:
M75D
Reported by: Marc van Kempen marc@bowtie.nl REV73R1
Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D
Wangtek 6200
The boot message identifier for this drive is WANGTEK
6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access
density code 0x13
This is a DDS-1 tape drive.
Native capacity is 2GB using 90m tapes.
Data transfer rate is 150kB/s.
Reported by: Tony Kimball alk@Think.COM
* Problem drives
CD-ROM drives
Contributed by &a.obrien;.23 November
1997.
As mentioned in
Jordan's Picks
Generally speaking those in The FreeBSD
Project 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 controllable by the various audio player
software.
Another area where SCSI CDROM manufacturers are cutting
corners is adhearance to the
SCSI specification.
Many SCSI CDROMs will respond to
multiple LUNs for its
target address. Known violators include the 6x Teac CD-56S
1.0D.
* Other
* Other
* PCMCIA
diff --git a/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml b/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml
index 0035977899..61c9047178 100644
--- a/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml
@@ -1,5684 +1,5685 @@
PC Hardware compatibility
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. You may also want to refer to the kernel configuration
file section in this handbook for
a list of supported devices.
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
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.
Resources on the Internet
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.
The Pentium
Systems Hardware Performance Guide
Sample Configurations
The following list of sample hardware configurations by no means
constitutes an endorsement of a given hardware vendor or product by
The FreeBSD Project. 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.
Jordan's Picks
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.
Motherboards
For Pentium Pro (P6) systems, I'm quite fond of the Tyan
S1668 dual-processor motherboard as well as the Intel PR440FX
motherboard with on-board SCSI WIDE and 100/10MB Intel
Etherexpress NIC. You can build a dandy little single or dual
processor system (which is supported in FreeBSD 3.0) for very
little cost now that the Pentium Pro 180/256K chips have fallen so
greatly in price, but no telling how much longer this will
last.
For the Pentium II, I'm rather partial to the ASUS P2l97-S motherboard with the on-board Adaptec SCSI WIDE controller.
For Pentium machines, the ASUS P55T2P4 motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems.
Those wishing to build more fault-tolerant systems should
also be sure to use Parity memory or, for truly 24/7
applications, ECC memory.
ECC memory does involve a slight performance trade-off
(which may or may not be noticeable depending on your
application) but buys you significantly increased
fault-tolerance to memory errors.
Disk Controllers
This one is a bit trickier, and while I used to recommend
the Buslogic
controllers unilaterally for everything from ISA to PCI, now I
tend to lean towards the Adaptec 1542CF for ISA,
Buslogic Bt747c for EISA and Adaptec 2940UW 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).
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.
There are two types of 3940 on the market—the older
model with AIC 7880 chips on it, and hte newer one with AIC 7895
chips. The newer model requires CAM support which is not yet part of FreeBSD—you have to add it, or install from one of the CAM binary snapshot release.
Disk drives
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! For a serious server configuration, there's not
even any argument—use SCSI equipment and good cables.
CDROM drives
My SCSI preferences extend to SCSI CDROM drives as well, and
while the Toshiba
drives have always been favourites of mine (in whatever speed is
hot that week), I'm still fond of my good old Plextor PX-12CS drive. It's
only a 12 speed, but it's offered excellent performance and
reliability.
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.
CD Recordable (WORM) drives
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 6020i. I myself use the HP 6020i for burning
CDROMs (in 2.2 and alter releases—it does not work with
earlier releases of the SCSI code) and it works very well. See
/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 HP6020i CDR.
Tape drives
I've had pretty good luck with both 8mm drives from Exabyte and 4mm (DAT) drives from HP.
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.
Video Cards
If you can also afford to buy a commercial X server for
US$99 from Xi Graphics,
Inc. (formerly X Inside, Inc) then I can heartily
recommend the Matrox
Millenium II card. Note that support for this card is also excellent with the XFree86 server, which is now at version 3.3.2.
You also certainly can't go wrong with one of 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. You can
also pick up their Revolution 3D cards very cheaply these days,
especially if you require a lot of video memory.
Monitors
I have had very good luck with the Sony Multiscan 17seII 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,000 for a 21" monitor or $1,700 for a 20" 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!
Networking
I can recommend the Intel EtherExpress Pro/100B card first
ande foremost, followed by the SMC Ultra 16 controller for
any ISA application and the SMC EtherPower or Compex ENET32
cards for slightly cheaper PCI based networking. In general, any
PCI NIC based around DEC's DC21041 Ethernet controller chip,
such as the Zynx ZX342 or DEC DE435, will generally work quite
well and can frequently be found in 2-port and 4-port version
(useful for firewalls and routers), though the Pro/100MB card has
the edge when it comes to providing the best performance with teh
lower overhead.
If what you're looking for is the
cheapest possible solution then almost any NE2000 clone will do
a fine job for very little cost.
Serial
If you're looking for high-speed serial networking
solutions, then Digi
International makes the SYNC/570 series, with drivers now in FreeBSD-current. Emerging Technologies also manufactures a board with T1/E1 capabilities, using software they provide. I have no direct experience using either product, however.
Multiport card options are somewhat more numerous, though it
has to be said that FreeBSD's support for 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 Stallion
Technologies apparently offers an unofficial driver
for their cards at this location.
Audio
I currently use a Creative Labs AWE32 though
just about anything from Creative Labs will generally work these
days. This is not to say that other types of sound cards don't
also work, simply that I have little experience with them (I was
a former GUS fan, but Gravis's soundcard situation has been dire
for some time).
Video
For video capture, there are two good choices — any card
based on the Brooktree BT848 chip, such as the Hauppage or WinTV
boards, will work very nicely with FreeBSD. Another board which
works for me is the Matrox Meteor
card. FreeBSD also supports the older video spigot card from
Creative Labs, but those are getting somewhat difficult to find.
Note that the Meteor frame grabber card will not
work with motherboards based on the 440FX chipset!
See the
motherboard reference section for
details. In such cases, it's better to go with a BT848 based
board.
Core/Processing
Motherboards, busses, and chipsets
* ISA
* EISA
* VLB
PCI
Contributed by &a.obrien; from postings by &a.rgrimes;.25 April
1995.
Continuing updates by &a.jkh;.Last update on 26 August 1996.
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.
Mercury:
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.
Saturn-I (ie, 82424ZX at rev 0,
1 or 2):
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.
Saturn-II (ie, 82424ZX at rev 3
or 4):
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).
Neptune:
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”.
Triton (ie,
430FX):
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.
Triton-II (ie,
430HX):
All reports on motherboards using this chipset have
been favorable so far. No known problems.
Orion:
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.
440FX:
This 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.
CPUs/FPUs
Contributed by &a.asami;.26 December
1997.
P6 class (Pentium Pro/Pentium II)
Both the Pentium Pro and Pentium II work fine with FreeBSD.
In fact, our main ftp site ftp.freebsd.org (also
known as "ftp.cdrom.com", world's largest
ftp site) runs FreeBSD on a Pentium Pro. Configurations details are available for interested parties.
Pentium class
The Intel Pentium (P54C), Pentium MMX (P55C), AMD K6 and
Cyrix/IBM 6x86MX processors are all reported to work with
FreeBSD. I will not go into details of which processor is
faster than what, there are zillions of web sites on the
Internet that tells you one way or another. :)
Various CPUs have different voltage/cooling requirements.
Make sure your motherboard can supply the exact voltage needed
by the CPU. For instance, many recent MMX chips require split
voltage (e.g., 2.9V core, 3.3V I/O). Also, some AMD and
Cyrix/IBM chips run hotter than Intel chips. In that case,
make sure you have good heatsink/fans (you can get the list of
certified parts from their web pages).
Clock speeds
Contributed by &a.rgrimes;.1
October 1996.
Updated by &a.asami;.27 December
1997.
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:
Rated CPU MHz
External Clock and Memory Bus MHz
External to Internal Clock Multiplier
PCI Bus Clock 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 (Intel, AMD)
150
75
2
37.5 (Cyrix/IBM 6x86MX)
166
66
2.5
33
180
60
3
30
200
66
3
33
233
66
3.5
33
66MHz may actually be 66.667MHz, but don't assume
so.
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.
As can be seen the best parts to be using are the 100,
133, 166, 200 and 233, with the exception that at a multiplier
of 3 or more the CPU starves for memory.
The AMD K6 Bug
In 1997, there have been reports of the AMD K6 seg
faulting during heavy compilation. That problem has been
fixed in 3Q '97. According to reports, K6 chips with date mark
“9733” or larger (i.e., manufactured in the 33rd week of '97
or later) do not have this bug.
* 486 class
* 386 class
286 class
Sorry, FreeBSD does not run on 80286 machines. It is nearly
impossible to run today's large full-featured UNIXes on such
hardware.
* Memory
The minimum amount of memory you must have to install FreeBSD
is 5 MB. Once your system is up and running you can build a custom kernel
that will use less memory. If you use the boot4.flp you can get
away with having only 4 MB.
* BIOS
Input/Output Devices
* Video cards
* Sound cards
Serial ports and multiport cards
The UART: What it is and how it works
Copyright © 1996 &a.uhclem;, All Rights
Reserved. 13 January 1996.
The Universal Asynchronous Receiver/Transmitter (UART)
controller is the key component of the serial communications
subsystem of a computer. The UART takes bytes of data and
transmits the individual bits in a sequential fashion. At the
destination, a second UART re-assembles the bits into complete
bytes.
Serial transmission is commonly used with modems and for
non-networked communication between computers, terminals and
other devices.
There are two primary forms of serial transmission:
Synchronous and Asynchronous. Depending on the modes that are
supported by the hardware, the name of the communication
sub-system will usually include a A if it supports
Asynchronous communications, and a S if it supports
Synchronous communications. Both forms are described
below.
Some common acronyms are:
UART Universal Asynchronous
Receiver/Transmitter
USART Universal Synchronous-Asynchronous
Receiver/Transmitter
Synchronous Serial Transmission
Synchronous serial transmission requires that the sender
and receiver share a clock with one another, or that the
sender provide a strobe or other timing signal so that the
receiver knows when to “read” the next bit of the data. In
most forms of serial Synchronous communication, if there is no
data available at a given instant to transmit, a fill
character must be sent instead so that data is always being
transmitted. Synchronous communication is usually more
efficient because only data bits are transmitted between
sender and receiver, and synchronous communication can be more
more costly if extra wiring and circuits are required to share
a clock signal between the sender and receiver.
A form of Synchronous transmission is used with printers
and fixed disk devices in that the data is sent on one set of
wires while a clock or strobe is sent on a different wire.
Printers and fixed disk devices are not normally serial
devices because most fixed disk interface standards send an
entire word of data for each clock or strobe signal by using a
separate wire for each bit of the word. In the PC industry,
these are known as Parallel devices.
The standard serial communications hardware in the PC does
not support Synchronous operations. This mode is described
here for comparison purposes only.
Asynchronous Serial Transmission
Asynchronous transmission allows data to be transmitted
without the sender having to send a clock signal to the
receiver. Instead, the sender and receiver must agree on
timing parameters in advance and special bits are added to
each word which are used to synchronize the sending and
receiving units.
When a word is given to the UART for Asynchronous
transmissions, a bit called the "Start Bit" is added to the
beginning of each word that is to be transmitted. The Start
Bit is used to alert the receiver that a word of data is about
to be sent, and to force the clock in the receiver into
synchronization with the clock in the transmitter. These two
clocks must be accurate enough to not have the frequency
drift by more than 10% during the transmission of the
remaining bits in the word. (This requirement was set in the
days of mechanical teleprinters and is easily met by modern
electronic equipment.)
After the Start Bit, the individual bits of the word of
data are sent, with the Least Significant Bit (LSB) being sent
first. Each bit in the transmission is transmitted for
exactly the same amount of time as all of the other bits, and
the receiver “looks” at the wire at approximately halfway
through the period assigned to each bit to determine if the
bit is a 1 or a 0. For example, if it takes two seconds
to send each bit, the receiver will examine the signal to
determine if it is a 1 or a 0 after one second has passed,
then it will wait two seconds and then examine the value of
the next bit, and so on.
The sender does not know when the receiver has “looked” at
the value of the bit. The sender only knows when the clock
says to begin transmitting the next bit of the word.
When the entire data word has been sent, the transmitter
may add a Parity Bit that the transmitter generates. The
Parity Bit may be used by the receiver to perform simple error
checking. Then at least one Stop Bit is sent by the
transmitter.
When the receiver has received all of the bits in the data
word, it may check for the Parity Bits (both sender and
receiver must agree on whether a Parity Bit is to be used),
and then the receiver looks for a Stop Bit. If the Stop Bit
does not appear when it is supposed to, the UART considers the
entire word to be garbled and will report a Framing Error to
the host processor when the data word is read. The usual
cause of a Framing Error is that the sender and receiver
clocks were not running at the same speed, or that the signal
was interrupted.
Regardless of whether the data was received correctly or
not, the UART automatically discards the Start, Parity and
Stop bits. If the sender and receiver are configured
identically, these bits are not passed to the host.
If another word is ready for transmission, the Start Bit
for the new word can be sent as soon as the Stop Bit for the
previous word has been sent.
Because asynchronous data is “self synchronizing”, if
there is no data to transmit, the transmission line can be
idle.
Other UART Functions
In addition to the basic job of converting data from
parallel to serial for transmission and from serial to
parallel on reception, a UART will usually provide additional
circuits for signals that can be used to indicate the state of
the transmission media, and to regulate the flow of data in
the event that the remote device is not prepared to accept
more data. For example, when the device connected to the
UART is a modem, the modem may report the presence of a
carrier on the phone line while the computer may be able to
instruct the modem to reset itself or to not take calls by
asserting or deasserting one more more of these extra signals.
The function of each of these additional signals is defined in
the EIA RS232-C standard.
The RS232-C and V.24 Standards
In most computer systems, the UART is connected to
circuitry that generates signals that comply with the EIA
RS232-C specification. There is also a CCITT standard named
V.24 that mirrors the specifications included in
RS232-C.
RS232-C Bit Assignments (Marks and Spaces)
In RS232-C, a value of 1 is called a Mark and a
value of 0 is called a Space. When a communication line
is idle, the line is said to be “Marking”, or transmitting
continuous 1 values.
The Start bit always has a value of 0 (a Space). The
Stop Bit always has a value of 1 (a Mark). This means
that there will always be a Mark (1) to Space (0) transition
on the line at the start of every word, even when multiple
word are transmitted back to back. This guarantees that
sender and receiver can resynchronize their clocks
regardless of the content of the data bits that are being
transmitted.
The idle time between Stop and Start bits does not have
to be an exact multiple (including zero) of the bit rate of
the communication link, but most UARTs are designed this way
for simplicity.
In RS232-C, the "Marking" signal (a 1) is represented
by a voltage between -2 VDC and -12 VDC, and a "Spacing"
signal (a 0) is represented by a voltage between 0 and +12
VDC. The transmitter is supposed to send +12 VDC or -12
VDC, and the receiver is supposed to allow for some voltage
loss in long cables. Some transmitters in low power devices
(like portable computers) sometimes use only +5 VDC and -5
VDC, but these values are still acceptable to a RS232-C
receiver, provided that the cable lengths are short.
RS232-C Break Signal
RS232-C also specifies a signal called a Break, which
is caused by sending continuous Spacing values (no Start or
Stop bits). When there is no electricity present on the
data circuit, the line is considered to be sending Break.
The Break signal must be of a duration longer than the
time it takes to send a complete byte plus Start, Stop and
Parity bits. Most UARTs can distinguish between a Framing
Error and a Break, but if the UART cannot do this, the
Framing Error detection can be used to identify
Breaks.
In the days of teleprinters, when numerous printers
around the country were wired in series (such as news
services), any unit could cause a Break by temporarily
opening the entire circuit so that no current flowed. This
was used to allow a location with urgent news to interrupt
some other location that was currently sending
information.
In modern systems there are two types of Break signals.
If the Break is longer than 1.6 seconds, it is considered a
"Modem Break", and some modems can be programmed to
terminate the conversation and go on-hook or enter the
modems' command mode when the modem detects this signal. If
the Break is smaller than 1.6 seconds, it signifies a Data
Break and it is up to the remote computer to respond to this
signal. Sometimes this form of Break is used as an
Attention or Interrupt signal and sometimes is accepted as a
substitute for the ASCII CONTROL-C character.
Marks and Spaces are also equivalent to “Holes” and “No
Holes” in paper tape systems.
Breaks cannot be generated from paper tape or from any
other byte value, since bytes are always sent with Start
and Stop bit. The UART is usually capable of generating
the continuous Spacing signal in response to a special
command from the host processor.
RS232-C DTE and DCE Devices
The RS232-C specification defines two types of
equipment: the Data Terminal Equipment (DTE) and the Data
Carrier Equipment (DCE). Usually, the DTE device is the
terminal (or computer), and the DCE is a modem. Across the
phone line at the other end of a conversation, the receiving
modem is also a DCE device and the computer that is
connected to that modem is a DTE device. The DCE device
receives signals on the pins that the DTE device transmits
on, and vice versa.
When two devices that are both DTE or both DCE must be
connected together without a modem or a similar media
translater between them, a NULL modem must be used. The
NULL modem electrically re-arranges the cabling so that the
transmitter output is connected to the receiver input on the
other device, and vice versa. Similar translations are
performed on all of the control signals so that each device
will see what it thinks are DCE (or DTE) signals from the
other device.
The number of signals generated by the DTE and DCE
devices are not symmetrical. The DTE device generates fewer
signals for the DCE device than the DTE device receives from
the DCE.
RS232-C Pin Assignments
The EIA RS232-C specification (and the ITU equivalent,
V.24) calls for a twenty-five pin connector (usually a DB25)
and defines the purpose of most of the pins in that
connector.
In the IBM Personal Computer and similar systems, a
subset of RS232-C signals are provided via nine pin
connectors (DB9). The signals that are not included on the
PC connector deal mainly with synchronous operation, and
this transmission mode is not supported by the UART that IBM
selected for use in the IBM PC.
Depending on the computer manufacturer, a DB25, a DB9,
or both types of connector may be used for RS232-C
communications. (The IBM PC also uses a DB25 connector for
the parallel printer interface which causes some
confusion.)
Below is a table of the RS232-C signal assignments in
the DB25 and DB9 connectors.
DB25 RS232-C Pin
DB9 IBM PC Pin
EIA Circuit Symbol
CCITT Circuit Symbol
Common Name
Signal Source
Description
1
-
AA
101
PG/FG
-
Frame/Protective Ground
2
3
BA
103
TD
DTE
Transmit Data
3
2
BB
104
RD
DCE
Receive Data
4
7
CA
105
RTS
DTE
Request to Send
5
8
CB
106
CTS
DCE
Clear to Send
6
6
CC
107
DSR
DCE
Data Set Ready
7
5
AV
102
SG/GND
-
Signal Ground
8
1
CF
109
DCD/CD
DCE
Data Carrier Detect
9
-
-
-
-
-
Reserved for Test
10
-
-
-
-
-
Reserved for Test
11
-
-
-
-
-
Reserved for Test
12
-
CI
122
SRLSD
DCE
Sec. Recv. Line Signal Detector
13
-
SCB
121
SCTS
DCE
Secondary Clear to Send
14
-
SBA
118
STD
DTE
Secondary Transmit Data
15
-
DB
114
TSET
DCE
Trans. Sig. Element Timing
16
-
SBB
119
SRD
DCE
Secondary Received Data
17
-
DD
115
RSET
DCE
Receiver Signal Element Timing
18
-
-
141
LOOP
DTE
Local Loopback
19
-
SCA
120
SRS
DTE
Secondary Request to Send
20
4
CD
108.2
DTR
DTE
Data Terminal Ready
21
-
-
-
RDL
DTE
Remote Digital Loopback
22
9
CE
125
RI
DCE
Ring Indicator
23
-
CH
111
DSRS
DTE
Data Signal Rate Selector
24
-
DA
113
TSET
DTE
Trans. Sig. Element Timing
25
-
-
142
-
DCE
Test Mode
Bits, Baud and Symbols
Baud is a measurement of transmission speed in
asynchronous communication. Because of advances in modem
communication technology, this term is frequently misused when
describing the data rates in newer devices.
Traditionally, a Baud Rate represents the number of bits
that are actually being sent over the media, not the amount of
data that is actually moved from one DTE device to the other.
The Baud count includes the overhead bits Start, Stop and
Parity that are generated by the sending UART and removed by
the receiving UART. This means that seven-bit words of data
actually take 10 bits to be completely transmitted. Therefore,
a modem capable of moving 300 bits per second from one place
to another can normally only move 30 7-bit words if Parity is
used and one Start and Stop bit are present.
If 8-bit data words are used and Parity bits are also
used, the data rate falls to 27.27 words per second, because
it now takes 11 bits to send the eight-bit words, and the
modem still only sends 300 bits per second.
The formula for converting bytes per second into a baud
rate and vice versa was simple until error-correcting modems
came along. These modems receive the serial stream of bits
from the UART in the host computer (even when internal modems
are used the data is still frequently serialized) and converts
the bits back into bytes. These bytes are then combined into
packets and sent over the phone line using a Synchronous
transmission method. This means that the Stop, Start, and
Parity bits added by the UART in the DTE (the computer) were
removed by the modem before transmission by the sending modem.
When these bytes are received by the remote modem, the remote
modem adds Start, Stop and Parity bits to the words, converts
them to a serial format and then sends them to the receiving
UART in the remote computer, who then strips the Start, Stop
and Parity bits.
The reason all these extra conversions are done is so that
the two modems can perform error correction, which means that
the receiving modem is able to ask the sending modem to resend
a block of data that was not received with the correct
checksum. This checking is handled by the modems, and the DTE
devices are usually unaware that the process is
occurring.
By striping the Start, Stop and Parity bits, the
additional bits of data that the two modems must share between
themselves to perform error-correction are mostly concealed
from the effective transmission rate seen by the sending and
receiving DTE equipment. For example, if a modem sends ten
7-bit words to another modem without including the Start, Stop
and Parity bits, the sending modem will be able to add 30 bits
of its own information that the receiving modem can use to do
error-correction without impacting the transmission speed of
the real data.
The use of the term Baud is further confused by modems
that perform compression. A single 8-bit word passed over the
telephone line might represent a dozen words that were
transmitted to the sending modem. The receiving modem will
expand the data back to its original content and pass that
data to the receiving DTE.
Modern modems also include buffers that allow the rate
that bits move across the phone line (DCE to DCE) to be a
different speed than the speed that the bits move between the
DTE and DCE on both ends of the conversation. Normally the
speed between the DTE and DCE is higher than the DCE to DCE
speed because of the use of compression by the modems.
Because the number of bits needed to describe a byte
varied during the trip between the two machines plus the
differing bits-per-seconds speeds that are used present on
the DTE-DCE and DCE-DCE links, the usage of the term Baud to
describe the overall communication speed causes problems and
can misrepresent the true transmission speed. So Bits Per
Second (bps) is the correct term to use to describe the
transmission rate seen at the DCE to DCE interface and Baud or
Bits Per Second are acceptable terms to use when a connection
is made between two systems with a wired connection, or if a
modem is in use that is not performing error-correction or
compression.
Modern high speed modems (2400, 9600, 14,400, and
19,200bps) in reality still operate at or below 2400 baud, or
more accurately, 2400 Symbols per second. High speed modem
are able to encode more bits of data into each Symbol using a
technique called Constellation Stuffing, which is why the
effective bits per second rate of the modem is higher, but the
modem continues to operate within the limited audio bandwidth
that the telephone system provides. Modems operating at 28,800
and higher speeds have variable Symbol rates, but the
technique is the same.
The IBM Personal Computer UART
Starting with the original IBM Personal Computer, IBM
selected the National Semiconductor INS8250 UART for use in
the IBM PC Parallel/Serial Adapter. Subsequent generations of
compatible computers from IBM and other vendors continued to
use the INS8250 or improved versions of the National
Semiconductor UART family.
National Semiconductor UART Family Tree
There have been several versions and subsequent
generations of the INS8250 UART. Each major version is
described below.
INS8250 -> INS8250B
\
\
\-> INS8250A -> INS82C50A
\
\
\-> NS16450 -> NS16C450
\
\
\-> NS16550 -> NS16550A -> PC16550D
INS8250
This part was used in the original IBM PC and
IBM PC/XT. The original name for this part was the
INS8250 ACE (Asynchronous Communications Element)
and it is made from NMOS technology.
The 8250 uses eight I/O ports and has a one-byte
send and a one-byte receive buffer. This original
UART has several race conditions and other flaws.
The original IBM BIOS includes code to work around
these flaws, but this made the BIOS dependent on the
flaws being present, so subsequent parts like the
8250A, 16450 or 16550 could not be used in the
original IBM PC or IBM PC/XT.
INS8250-B
This is the slower speed of the INS8250 made
from NMOS technology. It contains the same problems
as the original INS8250.
INS8250A
An improved version of the INS8250 using XMOS
technology with various functional flaws corrected.
The INS8250A was used initially in PC clone
computers by vendors who used “clean” BIOS designs.
Because of the corrections in the chip, this part
could not be used with a BIOS compatible with the
INS8250 or INS8250B.
INS82C50A
This is a CMOS version (low power consumption)
of the INS8250A and has similar functional
characteristics.
NS16450
Same as NS8250A with improvements so it can be
used with faster CPU bus designs. IBM used this
part in the IBM AT and updated the IBM BIOS to no
longer rely on the bugs in the INS8250.
NS16C450
This is a CMOS version (low power consumption)
of the NS16450.
NS16550
Same as NS16450 with a 16-byte send and receive
buffer but the buffer design was flawed and could
not be reliably be used.
NS16550A
Same as NS16550 with the buffer flaws corrected.
The 16550A and its successors have become the most
popular UART design in the PC industry, mainly due
it its ability to reliably handle higher data rates
on operating systems with sluggish interrupt
response times.
NS16C552
This component consists of two NS16C550A CMOS
UARTs in a single package.
PC16550D
Same as NS16550A with subtle flaws corrected.
This is revision D of the 16550 family and is the
latest design available from National Semiconductor.
The NS16550AF and the PC16550D are the same
thing
National reorganized their part numbering system a few
years ago, and the NS16550AFN no longer exists by that name.
(If you have a NS16550AFN, look at the date code on the
part, which is a four digit number that usually starts with
a nine. The first two digits of the number are the year,
and the last two digits are the week in that year when the
part was packaged. If you have a NS16550AFN, it is probably
a few years old.)
The new numbers are like PC16550DV, with minor
differences in the suffix letters depending on the package
material and its shape. (A description of the numbering
system can be found below.)
It is important to understand that in some stores, you
may pay $15(US) for a NS16550AFN made in 1990 and in the
next bin are the new PC16550DN parts with minor fixes that
National has made since the AFN part was in production, the
PC16550DN was probably made in the past six months and it
costs half (as low as $5(US) in volume) as much as the
NS16550AFN because they are readily available.
As the supply of NS16550AFN chips continues to shrink,
the price will probably continue to increase until more
people discover and accept that the PC16550DN really has the
same function as the old part number.
National Semiconductor Part Numbering System
The older NSnnnnnrqp part numbers
are now of the format
PCnnnnnrgp.
The r is the revision field. The
current revision of the 16550 from National Semiconductor is
D.
The p is the package-type field.
The types are:
"F"
QFP
(quad flat pack) L lead type
"N"
DIP
(dual inline package) through hole straight
lead type
"V"
LPCC
(lead plastic chip carrier) J lead type
The g is the product grade field.
If an I precedes the package-type letter, it indicates an
“industrial” grade part, which has higher specs than a
standard part but not as high as Military Specification
(Milspec) component. This is an optional field.
So what we used to call a NS16550AFN (DIP Package) is
now called a PC16550DN or PC16550DIN.
Other Vendors and Similar UARTs
Over the years, the 8250, 8250A, 16450 and 16550 have been
licensed or copied by other chip vendors. In the case of the
8250, 8250A and 16450, the exact circuit (the “megacell”) was
licensed to many vendors, including Western Digital and Intel.
Other vendors reverse-engineered the part or produced
emulations that had similar behavior.
In internal modems, the modem designer will frequently
emulate the 8250A/16450 with the modem microprocessor, and the
emulated UART will frequently have a hidden buffer consisting
of several hundred bytes. Because of the size of the buffer,
these emulations can be as reliable as a 16550A in their
ability to handle high speed data. However, most operating
systems will still report that the UART is only a 8250A or
16450, and may not make effective use of the extra buffering
present in the emulated UART unless special drivers are
used.
Some modem makers are driven by market forces to abandon a
design that has hundreds of bytes of buffer and instead use a
16550A UART so that the product will compare favorably in
market comparisons even though the effective performance may
be lowered by this action.
A common misconception is that all parts with “16550A”
written on them are identical in performance. There are
differences, and in some cases, outright flaws in most of
these 16550A clones.
When the NS16550 was developed, the National Semiconductor
obtained several patents on the design and they also limited
licensing, making it harder for other vendors to provide a
chip with similar features. Because of the patents,
reverse-engineered designs and emulations had to avoid
infringing the claims covered by the patents. Subsequently,
these copies almost never perform exactly the same as the
NS16550A or PC16550D, which are the parts most computer and
modem makers want to buy but are sometimes unwilling to pay
the price required to get the genuine part.
Some of the differences in the clone 16550A parts are
unimportant, while others can prevent the device from being
used at all with a given operating system or driver. These
differences may show up when using other drivers, or when
particular combinations of events occur that were not well
tested or considered in the Windows driver. This is because
most modem vendors and 16550-clone makers use the Microsoft
drivers from Windows for Workgroups 3.11 and the Microsoft MSD
utility as the primary tests for compatibility with the
NS16550A. This over-simplistic criteria means that if a
different operating system is used, problems could appear due
to subtle differences between the clones and genuine
components.
National Semiconductor has made available a program named
COMTEST that performs compatibility tests independent of any
OS drivers. It should be remembered that the purpose of this
type of program is to demonstrate the flaws in the products of
the competition, so the program will report major as well as
extremely subtle differences in behavior in the part being
tested.
In a series of tests performed by the author of this
document in 1994, components made by National Semiconductor,
TI, StarTech, and CMD as well as megacells and emulations
embedded in internal modems were tested with COMTEST. A
difference count for some of these components is listed below.
Because these tests were performed in 1994, they may not
reflect the current performance of the given product from a
vendor.
It should be noted that COMTEST normally aborts when an
excessive number or certain types of problems have been
detected. As part of this testing, COMTEST was modified so
that it would not abort no matter how many differences were
encountered.
Vendor
Part Number
Errors (aka "differences" reported)
National
(PC16550DV)
- 0
- To date, the author of this document has not
- found any non-National parts that report zero
- differences using the COMTEST program. It should
- also be noted that National has had five versions
- of the 16550 over the years and the newest parts
- behave a bit differently than the classic
- NS16550AFN that is considered the benchmark for
- functionality. COMTEST appears to turn a blind eye
- to the differences within the National product
- line and reports no errors on the National parts
- (except for the original 16550) even when there
- are official erratas that describe bugs in the A,
- B and C revisions of the parts, so this bias in
- COMTEST must be taken into account.
-
-
+ 0
National
(NS16550AFN)
0
National
(NS16C552V)
0
TI
(TL16550AFN)
3
CMD
(16C550PE)
19
StarTech
(ST16C550J)
23
Rockwell
Reference modem with internal 16550 or an
emulation (RC144DPi/C3000-25)
117
Sierra
Modem with an internal 16550
(SC11951/SC11351)
91
+
+
+ To date, the author of this document has not
+ found any non-National parts that report zero
+ differences using the COMTEST program. It should
+ also be noted that National has had five versions
+ of the 16550 over the years and the newest parts
+ behave a bit differently than the classic
+ NS16550AFN that is considered the benchmark for
+ functionality. COMTEST appears to turn a blind eye
+ to the differences within the National product
+ line and reports no errors on the National parts
+ (except for the original 16550) even when there
+ are official erratas that describe bugs in the A,
+ B and C revisions of the parts, so this bias in
+ COMTEST must be taken into account.
+
It is important to understand that a simple count of
differences from COMTEST does not reveal a lot about what
differences are important and which are not. For example,
about half of the differences reported in the two modems
listed above that have internal UARTs were caused by the clone
UARTs not supporting five- and six-bit character modes. The
real 16550, 16450, and 8250 UARTs all support these modes and
COMTEST checks the functionality of these modes so over fifty
differences are reported. However, almost no modern modem
supports five- or six-bit characters, particularly those with
error-correction and compression capabilities. This means
that the differences related to five- and six-bit character
modes can be discounted.
Many of the differences COMTEST reports have to do with
timing. In many of the clone designs, when the host reads
from one port, the status bits in some other port may not
update in the same amount of time (some faster, some slower)
as a real NS16550AFN and COMTEST looks
for these differences. This means that the number of
differences can be misleading in that one device may only have
one or two differences but they are extremely serious, and
some other device that updates the status registers faster or
slower than the reference part (that would probably never
affect the operation of a properly written driver) could have
dozens of differences reported.
COMTEST can be used as a screening tool to alert the
administrator to the presence of potentially incompatible
components that might cause problems or have to be handled as
a special case.
If you run COMTEST on a 16550 that is in a modem or a
modem is attached to the serial port, you need to first issue
a ATE0&W command to the modem so that the modem will not
echo any of the test characters. If you forget to do this,
COMTEST will report at least this one difference:
Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61
8250/16450/16550 Registers
The 8250/16450/16550 UART occupies eight contiguous I/O
port addresses. In the IBM PC, there are two defined
locations for these eight ports and they are known
collectively as COM1 and COM2. The makers of PC-clones and
add-on cards have created two additional areas known as COM3
and COM4, but these extra COM ports conflict with other
hardware on some systems. The most common conflict is with
video adapters that provide IBM 8514 emulation.
COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ
4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3
COM3 is located from 0x3e8 to 0x3ef and has no standardized
IRQ COM4 is located from 0x2e8 to 0x2ef and has no
standardized IRQ.
A description of the I/O ports of the 8250/16450/16550
UART is provided below.
I/O Port
Access Allowed
Description
+0x00
write (DLAB==0)
Transmit Holding Register (THR).Information written to this port are treated as
data words and will be transmitted by the
UART.
+0x00
read (DLAB==0)
Receive Buffer Register (RBR).Any data words received by the UART form the
serial link are accessed by the host by reading this
port.
+0x00
write/read (DLAB==1)
Divisor Latch LSB (DLL)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 0 thru 7 of the
divisor.
+0x01
write/read (DLAB==1)
Divisor Latch MSB (DLH)This
value will be divided from the master input clock
(in the IBM PC, the master clock is 1.8432MHz) and
the resulting clock will determine the baud rate of
the UART. This register holds bits 8 thru 15 of the
divisor.
+0x01
write/read (DLAB==0)
Interrupt Enable
Register (IER)The 8250/16450/16550 UART classifies
events into one of four categories. Each
category can be configured to generate an
interrupt when any of the events occurs. The
8250/16450/16550 UART generates a single
external interrupt signal regardless of how
many events in the enabled categories have
occurred. It is up to the host processor to
respond to the interrupt and then poll the
enabled interrupt categories (usually all
categories have interrupts enabled) to
determine the true cause(s) of the
interrupt.
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Enable Modem Status Interrupt (EDSSI).
Setting this bit to "1" allows the UART to
generate an interrupt when a change occurs
on one or more of the status lines.
Bit 2
Enable Receiver Line Status Interrupt (ELSI)
Setting this bit to "1" causes the UART to
generate an interrupt when the an error
(or a BREAK signal) has been detected in
the incoming data.
Bit 1
Enable Transmitter Holding Register Empty
Interrupt (ETBEI) Setting this bit to "1"
causes the UART to generate an interrupt
when the UART has room for one or more
additional characters that are to be
transmitted.
Bit 0
Enable Received Data Available Interrupt
(ERBFI) Setting this bit to "1" causes the
UART to generate an interrupt when the
UART has received enough characters to
exceed the trigger level of the FIFO, or
the FIFO timer has expired (stale data),
or a single character has been received
when the FIFO is disabled.
+0x02
write
FIFO Control Register (FCR)
(This port does not exist on the 8250 and 16450
UART.)
Bit 7
Receiver Trigger Bit
#1
Bit 6
Receiver Trigger Bit
#0These two bits control at what
point the receiver is to generate an interrupt
when the FIFO is active.
7
6
How many words are received
before an interrupt is generated
0
0
1
0
1
4
1
0
8
1
1
14
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
DMA Mode Select. If Bit 0
is set to "1" (FIFOs enabled), setting this bit
changes the operation of the -RXRDY and -TXRDY
signals from Mode 0 to Mode 1.
Bit 2
Transmit FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
transmitted will be sent intact. This function
is useful in aborting transfers.
Bit 1
Receiver FIFO Reset. When a
"1" is written to this bit, the contents of the
FIFO are discarded. Any word currently being
assembled in the shift register will be received
intact.
Bit 0
16550 FIFO Enable. When
set, both the transmit and receive FIFOs are
enabled. Any contents in the holding register,
shift registers or FIFOs are lost when FIFOs are
enabled or disabled.
+0x02
read
Interrupt Identification
Register
Bit 7
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 6
FIFOs enabled. On the
8250/16450 UART, this bit is zero.
Bit 5
Reserved, always 0.
Bit 4
Reserved, always 0.
Bit 3
Interrupt ID Bit #2. On the
8250/16450 UART, this bit is zero.
Bit 2
Interrupt ID Bit #1
Bit 1
Interrupt ID Bit #0.These
three bits combine to report the category of
event that caused the interrupt that is in
progress. These categories have priorities, so
if multiple categories of events occur at the
same time, the UART will report the more
important events first and the host must resolve
the events in the order they are reported. All
events that caused the current interrupt must be
resolved before any new interrupts will be
generated. (This is a limitation of the PC
architecture.)
2
1
0
Priority
Description
0
1
1
First
Received Error (OE, PE, BI,
or FE)
0
1
0
Second
Received Data
Available
1
1
0
Second
Trigger level identification
(Stale data in receive buffer)
0
0
1
Third
Transmitter has room for
more words (THRE)
0
0
0
Fourth
Modem Status Change (-CTS,
-DSR, -RI, or -DCD)
Bit 0
Interrupt Pending Bit. If
this bit is set to "0", then at least one
interrupt is pending.
+0x03
write/read
Line Control
Register (LCR)
Bit 7
Divisor Latch Access Bit
(DLAB). When set, access to the data
transmit/receive register (THR/RBR) and the
Interrupt Enable Register (IER) is disabled. Any
access to these ports is now redirected to the
Divisor Latch Registers. Setting this bit,
loading the Divisor Registers, and clearing DLAB
should be done with interrupts disabled.
Bit 6
Set Break. When set to "1",
the transmitter begins to transmit continuous
Spacing until this bit is set to "0". This
overrides any bits of characters that are being
transmitted.
Bit 5
Stick Parity. When parity
is enabled, setting this bit causes parity to
always be "1" or "0", based on the value of Bit
4.
Bit 4
Even Parity Select (EPS).
When parity is enabled and Bit 5 is "0", setting
this bit causes even parity to be transmitted
and expected. Otherwise, odd parity is
used.
Bit 3
Parity Enable (PEN). When
set to "1", a parity bit is inserted between the
last bit of the data and the Stop Bit. The UART
will also expect parity to be present in the
received data.
Bit 2
Number of Stop Bits (STB).
If set to "1" and using 5-bit data words, 1.5
Stop Bits are transmitted and expected in each
data word. For 6, 7 and 8-bit data words, 2
Stop Bits are transmitted and expected. When
this bit is set to "0", one Stop Bit is used on
each data word.
Bit 1
Word Length Select Bit #1
(WLSB1)
Bit 0
Word Length Select Bit #0
(WLSB0)
Together
these bits specify the number of bits in each
data word.
1
0
Word
Length
0
0
5 Data
Bits
0
1
6 Data
Bits
1
0
7 Data
Bits
1
1
8 Data
Bits
+0x04
write/read
Modem Control Register
(MCR)
Bit 7
Reserved, always 0.
Bit 6
Reserved, always 0.
Bit 5
Reserved, always 0.
Bit 4
Loop-Back Enable. When set to "1", the UART
transmitter and receiver are internally
connected together to allow diagnostic
operations. In addition, the UART modem control
outputs are connected to the UART modem control
inputs. CTS is connected to RTS, DTR is
connected to DSR, OUT1 is connected to RI, and
OUT 2 is connected to DCD.
Bit 3
OUT 2. An auxiliary output that the host
processor may set high or low. In the IBM PC
serial adapter (and most clones), OUT 2 is used
to tri-state (disable) the interrupt signal from
the 8250/16450/16550 UART.
Bit 2
OUT 1. An auxiliary output that the host
processor may set high or low. This output is
not used on the IBM PC serial adapter.
Bit 1
Request to Send (RTS). When set to "1", the
output of the UART -RTS line is Low
(Active).
Bit 0
Data Terminal Ready (DTR). When set to "1",
the output of the UART -DTR line is Low
(Active).
+0x05
write/read
Line Status Register
(LSR)
Bit 7
Error in Receiver FIFO. On the 8250/16450
UART, this bit is zero. This bit is set to "1"
when any of the bytes in the FIFO have one or
more of the following error conditions: PE, FE,
or BI.
Bit 6
Transmitter Empty (TEMT). When set to "1",
there are no words remaining in the transmit
FIFO or the transmit shift register. The
transmitter is completely idle.
Bit 5
Transmitter Holding Register Empty
(THRE). When set to "1", the FIFO (or holding
register) now has room for at least one
additional word to transmit. The transmitter may
still be transmitting when this bit is set to
"1".
Bit 4
Break Interrupt (BI). The receiver has
detected a Break signal.
Bit 3
Framing Error (FE). A Start Bit was
detected but the Stop Bit did not appear at the
expected time. The received word is probably
garbled.
Bit 2
Parity Error (PE). The parity bit was
incorrect for the word received.
Bit 1
Overrun Error (OE). A new word was received
and therewas no room in the receive buffer. The
newly-arrived word in the shift register is
discarded. On 8250/16450 UARTs, the word in the
holding register is discarded and the newly-
arrived word is put in the holding
register.
Bit 0
Data Ready (DR) One or more words are in
the receive FIFO that the host may read. A word
must be completely received and moved from the
shift register into the FIFO (or holding
register for 8250/16450 designs) before this bit
is set.
+0x06
write/read
Modem Status Register
(MSR)
Bit 7
Data Carrier Detect (DCD). Reflects the
state of the DCD line on the UART.
Bit 6
Ring Indicator (RI). Reflects the state of
the RI line on the UART.
Bit 5
Data Set Ready (DSR). Reflects the state of
the DSR line on the UART.
Bit 4
Clear To Send (CTS). Reflects the state of
the CTS line on the UART.
Bit 3
Delta Data Carrier Detect (DDCD). Set to
"1" if the -DCD line has changed state one more
more times since the last time the MSR was read
by the host.
Bit 2
Trailing Edge Ring Indicator (TERI). Set to
"1" if the -RI line has had a low to high
transition since the last time the MSR was read
by the host.
Bit 1
Delta Data Set Ready (DDSR). Set to "1" if
the -DSR line has changed state one more more
times since the last time the MSR was read by
the host.
Bit 0
Delta Clear To Send (DCTS). Set to "1" if
the -CTS line has changed state one more more
times since the last time the MSR was read by
the host.
+0x07
write/read
Scratch Register (SCR). This register performs no
function in the UART. Any value can be written by the
host to this location and read by the host later
on.
Beyond the 16550A UART
Although National Semiconductor has not offered any
components compatible with the 16550 that provide additional
features, various other vendors have. Some of these
components are described below. It should be understood that
to effectively utilize these improvements, drivers may have to
be provided by the chip vendor since most of the popular
operating systems do not support features beyond those
provided by the 16550.
ST16650
By default this part is similar to the NS16550A,
but an extended 32-byte send and receive buffer can be
optionally enabled. Made by Startech.
TIL16660
By default this part behaves similar to the
NS16550A, but an extended 64-byte send and receive
buffer can be optionally enabled. Made by Texas
Instruments.
Hayes ESP
This proprietary plug-in card contains a 2048-byte
send and receive buffer, and supports data rates to
230.4Kbit/sec. Made by Hayes.
In addition to these “dumb” UARTs, many vendors produce
intelligent serial communication boards. This type of design
usually provides a microprocessor that interfaces with several
UARTs, processes and buffers the data, and then alerts the
main PC processor when necessary. Because the UARTs are not
directly accessed by the PC processor in this type of
communication system, it is not necessary for the vendor to
use UARTs that are compatible with the 8250, 16450, or the
16550 UART. This leaves the designer free to components that
may have better performance characteristics.
Configuring the <devicename>sio</devicename>
driver
The sio driver provides
support for NS8250-, NS16450-, NS16550 and NS16550A-based EIA
RS-232C (CCITT V.24) communications interfaces. Several
multiport cards are supported as well. See the sio4 manual page for detailed technical
documentation.
Digi International (DigiBoard) PC/8
Contributed by &a.awebster;.26
August 1995.
Here is a config snippet from a machine with a Digi
International PC/8 with 16550. It has 8 modems connected to
these 8 lines, and they work just great. Do not forget to add
options COM_MULTIPORT or it will
not work very well!
device sio4 at isa? port 0x100 tty flags 0xb05
device sio5 at isa? port 0x108 tty flags 0xb05
device sio6 at isa? port 0x110 tty flags 0xb05
device sio7 at isa? port 0x118 tty flags 0xb05
device sio8 at isa? port 0x120 tty flags 0xb05
device sio9 at isa? port 0x128 tty flags 0xb05
device sio10 at isa? port 0x130 tty flags 0xb05
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
The trick in setting this up is that the MSB of the flags
represent the last SIO port, in this case 11 so flags are
0xb05.
Boca 16
Contributed by &a.whiteside;.26
August 1995.
The procedures to make a Boca 16 pord board with FreeBSD
are pretty straightforward, but you will need a couple things
to make it work:
You either need the kernel sources installed so you
can recompile the necessary options or you will need
someone else to compile it for you. The 2.0.5 default
kernel does not come with
multiport support enabled and you will need to add a
device entry for each port anyways.
Two, you will need to know the interrupt and IO
setting for your Boca Board so you can set these options
properly in the kernel.
One important note — the actual UART chips for the Boca 16
are in the connector box, not on the internal board itself. So
if you have it unplugged, probes of those ports will fail. I
have never tested booting with the box unplugged and plugging
it back in, and I suggest you do not either.
If you do not already have a custom kernel configuration
file set up, refer to Kernel Configuration for
general procedures. The following are the specifics for the
Boca 16 board and assume you are using the kernel name
MYKERNEL and editing with vi.
Add the line
options COM_MULTIPORT
to the config file.
Where the current device
sion lines are,
you will need to add 16 more devices. Only
the last device includes the interrupt vector for the
board. (See the sio4 manual page for detail as
to why.) The following example is for a Boca Board with
an interrupt of 3, and a base IO address 100h. The IO
address for Each port is +8 hexadecimal from the
previous port, thus the 100h, 108h, 110h... addresses.
device sio1 at isa? port 0x100 tty flags 0x1005
device sio2 at isa? port 0x108 tty flags 0x1005
device sio3 at isa? port 0x110 tty flags 0x1005
device sio4 at isa? port 0x118 tty flags 0x1005
…
device sio15 at isa? port 0x170 tty flags 0x1005
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
The flags entry
must be changed from this example
unless you are using the exact same sio assignments.
Flags are set according to 0xMYY
where M indicates the minor number
of the master port (the last port on a Boca 16) and
YY indicates if FIFO is enabled or
disabled(enabled), IRQ sharing is used(yes) and if there
is an AST/4 compatible IRQ control register(no). In this
example,
flags 0x1005 indicates that the master port is
sio16. If I added another board and assigned sio17
through sio28, the flags for all 16 ports on
that board would be 0x1C05, where
1C indicates the minor number of the master port. Do not
change the 05 setting.
Save and complete the kernel configuration,
recompile, install and reboot. Presuming you have
successfully installed the recompiled kernel and have it
set to the correct address and IRQ, your boot message
should indicate the successful probe of the Boca ports
as follows: (obviously the sio numbers, IO and IRQ could
be different)
sio1 at 0x100-0x107 flags 0x1005 on isa
sio1: type 16550A (multiport)
sio2 at 0x108-0x10f flags 0x1005 on isa
sio2: type 16550A (multiport)
sio3 at 0x110-0x117 flags 0x1005 on isa
sio3: type 16550A (multiport)
sio4 at 0x118-0x11f flags 0x1005 on isa
sio4: type 16550A (multiport)
sio5 at 0x120-0x127 flags 0x1005 on isa
sio5: type 16550A (multiport)
sio6 at 0x128-0x12f flags 0x1005 on isa
sio6: type 16550A (multiport)
sio7 at 0x130-0x137 flags 0x1005 on isa
sio7: type 16550A (multiport)
sio8 at 0x138-0x13f flags 0x1005 on isa
sio8: type 16550A (multiport)
sio9 at 0x140-0x147 flags 0x1005 on isa
sio9: type 16550A (multiport)
sio10 at 0x148-0x14f flags 0x1005 on isa
sio10: type 16550A (multiport)
sio11 at 0x150-0x157 flags 0x1005 on isa
sio11: type 16550A (multiport)
sio12 at 0x158-0x15f flags 0x1005 on isa
sio12: type 16550A (multiport)
sio13 at 0x160-0x167 flags 0x1005 on isa
sio13: type 16550A (multiport)
sio14 at 0x168-0x16f flags 0x1005 on isa
sio14: type 16550A (multiport)
sio15 at 0x170-0x177 flags 0x1005 on isa
sio15: type 16550A (multiport)
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
sio16: type 16550A (multiport master)
If the messages go by too fast to
see,
&prompt.root; dmesg | more
will
show you the boot messages.
Next, appropriate entries in
/dev for the devices must be made
using the /dev/MAKEDEV script.
After becoming root:
&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tty1
&prompt.root; ./MAKEDEV cua1
(everything in between)
&prompt.root; ./MAKEDEV ttyg
&prompt.root; ./MAKEDEV cuag
If you do not want or need callout
devices for some reason, you can dispense with making
the cua* devices.
If you want a quick and sloppy way to make sure the
devices are working, you can simply plug a modem into
each port and (as root)
&prompt.root; echo at > ttyd*
for each device you have made. You
should see the RX lights flash for
each working port.
Configuring the <devicename>cy</devicename>
driver
Contributed by &a.alex;.6 June
1996.
The Cyclades multiport cards are based on the
cy driver instead of the usual
sio driver used by other multiport
cards. Configuration is a simple matter of:
Add the cy device to
your kernel
configuration (note that your irq and
iomem settings may differ).
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
Rebuild
and install the new kernel.
Make the device
nodes by typing (the following example
assumes an 8-port board):
&prompt.root; cd /dev
&prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
If appropriate, add dialup
entries to /etc/ttys
by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example:
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
…
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
Reboot with the new kernel.
* Parallel ports
* Modems
* Network cards
* Keyboards
* Mice
* Other
Storage Devices
Using ESDI hard disks
Copyright © 1995, &a.wilko;.24
September 1995.
ESDI is an acronym that means Enhanced Small Device Interface.
It is loosely based on the good old ST506/412 interface originally
devised by Seagate Technology, the makers of the first affordable
5.25" winchester disk.
The acronym says Enhanced, and rightly so. In the first place
the speed of the interface is higher, 10 or 15 Mbits/second
instead of the 5 Mbits/second of ST412 interfaced drives. Secondly
some higher level commands are added, making the ESDI interface
somewhat 'smarter' to the operating system driver writers. It is
by no means as smart as SCSI by the way. ESDI is standardized by
ANSI.
Capacities of the drives are boosted by putting more sectors
on each track. Typical is 35 sectors per track, high capacity
drives I have seen were up to 54 sectors/track.
Although ESDI has been largely obsoleted by IDE and SCSI
interfaces, the availability of free or cheap surplus drives makes
them ideal for low (or now) budget systems.
Concepts of ESDI
Physical connections
The ESDI interface uses two cables connected to each
drive. One cable is a 34 pin flat cable edge connector that
carries the command and status signals from the controller to
the drive and vice-versa. The command cable is daisy chained
between all the drives. So, it forms a bus onto which all
drives are connected.
The second cable is a 20 pin flat cable edge connector
that carries the data to and from the drive. This cable is
radially connected, so each drive has its own direct
connection to the controller.
To the best of my knowledge PC ESDI controllers are
limited to using a maximum of 2 drives per controller. This is
compatibility feature(?) left over from the WD1003 standard
that reserves only a single bit for device addressing.
Device addressing
On each command cable a maximum of 7 devices and 1
controller can be present. To enable the controller to
uniquely identify which drive it addresses, each ESDI device
is equipped with jumpers or switches to select the devices
address.
On PC type controllers the first drive is set to address
0, the second disk to address 1. Always
make sure you set each disk to an unique address!
So, on a PC with its two drives/controller maximum the first
drive is drive 0, the second is drive 1.
Termination
The daisy chained command cable (the 34 pin cable
remember?) needs to be terminated at the last drive on the
chain. For this purpose ESDI drives come with a termination
resistor network that can be removed or disabled by a jumper
when it is not used.
So, one and only one drive,
the one at the farthest end of the command cable has its
terminator installed/enabled. The controller automatically
terminates the other end of the cable. Please note that this
implies that the controller must be at one end of the cable
and not in the middle.
Using ESDI disks with FreeBSD
Why is ESDI such a pain to get working in the first
place?
People who tried ESDI disks with FreeBSD are known to have
developed a profound sense of frustration. A combination of
factors works against you to produce effects that are hard to
understand when you have never seen them before.
This has also led to the popular legend ESDI and FreeBSD is
a plain NO-GO. The following sections try to list all the
pitfalls and solutions.
ESDI speed variants
As briefly mentioned before, ESDI comes in two speed
flavors. The older drives and controllers use a 10
Mbits/second data transfer rate. Newer stuff uses 15
Mbits/second.
It is not hard to imagine that 15 Mbits/second drive cause
problems on controllers laid out for 10 Mbits/second. As
always, consult your controller and drive documentation to see if
things match.
Stay on track
Mainstream ESDI drives use 34 to 36 sectors per track.
Most (older) controllers cannot handle more than this number
of sectors. Newer, higher capacity, drives use higher numbers
of sectors per track. For instance, I own a 670 Mb drive that
has 54 sectors per track.
In my case, the controller could not handle this number of
sectors. It proved to work well except that it only used 35
sectors on each track. This meant losing a lot of disk
space.
Once again, check the documentation of your hardware for
more info. Going out-of-spec like in the example might or
might not work. Give it a try or get another more capable
controller.
Hard or soft sectoring
Most ESDI drives allow hard or soft sectoring to be
selected using a jumper. Hard sectoring means that the drive
will produce a sector pulse on the start of each new sector.
The controller uses this pulse to tell when it should start to
write or read.
Hard sectoring allows a selection of sector size (normally
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
512 byte sectors. The number of sectors per track also varies
while still using the same number of bytes per formatted
sector. The number of unformatted bytes
per sector varies, dependent on your controller it needs more
or less overhead bytes to work correctly. Pushing more
sectors on a track of course gives you more usable space, but
might give problems if your controller needs more bytes than
the drive offers.
In case of soft sectoring, the controller itself
determines where to start/stop reading or writing. For ESDI
hard sectoring is the default (at least on everything I came
across). I never felt the urge to try soft sectoring.
In general, experiment with sector settings before you
install FreeBSD because you need to re-run the low-level
format after each change.
Low level formatting
ESDI drives need to be low level formatted before they are
usable. A reformat is needed whenever you figgle with the
number of sectors/track jumpers or the physical orientation of
the drive (horizontal, vertical). So, first think, then
format. The format time must not be underestimated, for big
disks it can take hours.
After a low level format, a surface scan is done to find
and flag bad sectors. Most disks have a manufacturer bad block
list listed on a piece of paper or adhesive sticker. In
addition, on most disks the list is also written onto the
disk. Please use the manufacturer's list. It is much easier to
remap a defect now than after FreeBSD is installed.
Stay away from low-level formatters that mark all sectors
of a track as bad as soon as they find one bad sector. Not
only does this waste space, it also and more importantly
causes you grief with bad144 (see the section on
bad144).
Translations
Translations, although not exclusively a ESDI-only
problem, might give you real trouble. Translations come in
multiple flavors. Most of them have in common that they
attempt to work around the limitations posed upon disk
geometries by the original IBM PC/AT design (thanks
IBM!).
First of all there is the (in)famous 1024 cylinder limit.
For a system to be able to boot, the stuff (whatever
operating system) must be in the first 1024 cylinders of a
disk. Only 10 bits are available to encode the cylinder
number. For the number of sectors the limit is 64 (0-63). When
you combine the 1024 cylinder limit with the 16 head limit
(also a design feature) you max out at fairly limited disk
sizes.
To work around this problem, the manufacturers of ESDI PC
controllers added a BIOS prom extension on their boards. This
BIOS extension handles disk I/O for booting (and for some
operating systems all disk I/O)
by using translation. For instance, a big drive might be
presented to the system as having 32 heads and 64
sectors/track. The result is that the number of cylinders is
reduced to something below 1024 and is therefore usable by the
system without problems. It is noteworthy to know that FreeBSD
does not use the BIOS after its kernel has started. More on
this later.
A second reason for translations is the fact that most
older system BIOSes could only handle drives with 17 sectors
per track (the old ST412 standard). Newer system BIOSes
usually have a user-defined drive type (in most cases this is
drive type 47).
Whatever you do to translations after reading
this document, keep in mind that if you have multiple
operating systems on the same disk, all must use the same
translation
While on the subject of translations, I have seen one
controller type (but there are probably more like this) offer
the option to logically split a drive in multiple partitions
as a BIOS option. I had select 1 drive == 1 partition because
this controller wrote this info onto the disk. On power-up it
read the info and presented itself to the system based on the
info from the disk.
Spare sectoring
Most ESDI controllers offer the possibility to remap bad
sectors. During/after the low-level format of the disk bad
sectors are marked as such, and a replacement sector is put in
place (logically of course) of the bad one.
In most cases the remapping is done by using N-1 sectors
on each track for actual data storage, and sector N itself is
the spare sector. N is the total number of sectors physically
available on the track. The idea behind this is that the
operating system sees a 'perfect' disk without bad sectors. In
the case of FreeBSD this concept is not usable.
The problem is that the translation from bad to good is performed by the BIOS of the
ESDI controller. FreeBSD, being a true 32 bit operating
system, does not use the BIOS after it has been booted.
Instead, it has device drivers that talk directly to the
hardware.
So: don't use spare sectoring, bad block
remapping or whatever it may be called by the controller
manufacturer when you want to use the disk for
FreeBSD.
Bad block handling
The preceding section leaves us with a problem. The
controller's bad block handling is not usable and still
FreeBSD's filesystems assume perfect media without any flaws.
To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a
Digital Equipment standard for bad block handling) scans a
FreeBSD slice for bad blocks. Having found these bad blocks,
it writes a table with the offending block numbers to the end
of the FreeBSD slice.
When the disk is in operation, the disk accesses are
checked against the table read from the disk. Whenever a
block number is requested that is in the bad144 list, a
replacement block (also from the end of the FreeBSD slice) is
used. In this way, the bad144 replacement scheme presents
'perfect' media to the FreeBSD filesystems.
There are a number of potential pitfalls associated with
the use of bad144. First of all, the slice cannot have more
than 126 bad sectors. If your drive has a high number of bad
sectors, you might need to divide it into multiple FreeBSD
slices each containing less than 126 bad sectors. Stay away
from low-level format programs that mark
every sector of a track as bad when they
find a flaw on the track. As you can imagine, the 126 limit
is quickly reached when the low-level format is done this
way.
Second, if the slice contains the root filesystem, the
slice should be within the 1024 cylinder BIOS limit. During
the boot process the bad144 list is read using the BIOS and
this only succeeds when the list is within the 1024 cylinder
limit.
The restriction is not that only the root
filesystem must be within the 1024
cylinder limit, but rather the entire
slice that contains the root
filesystem.
Kernel configuration
ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The
wd driver should work for all
WD1003 compatible interfaces.
Most hardware is jumperable for one of two different I/O
address ranges and IRQ lines. This allows you to have two wd
type controllers in one system.
When your hardware allows non-standard strappings, you can
use these with FreeBSD as long as you enter the correct info
into the kernel config file. An example from the kernel config
file (they live in /sys/i386/conf
BTW).
# First WD compatible controller
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
disk wd0 at wdc0 drive 0
disk wd1 at wdc0 drive 1
# Second WD compatible controller
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
disk wd2 at wdc1 drive 0
disk wd3 at wdc1 drive 1
Particulars on ESDI hardware
Adaptec 2320 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a ACB-2320. No other operating system was
present on the disk.
To do so I low level formatted the disk using NEFMT.EXE
(ftpable from
www.adaptec.com) and answered NO to the
question whether the disk should be formatted with a spare
sector on each track. The BIOS on the ACD-2320 was disabled. I
used the free configurable option in the system BIOS to
allow the BIOS to boot it.
Before using NEFMT.EXE I tried to format the disk using
the ACB-2320 BIOS builtin formatter. This proved to be a show
stopper, because it did not give me an option to disable spare
sectoring. With spare sectoring enabled the FreeBSD
installation process broke down on the bad144 run.
Please check carefully which ACB-232xy variant you have.
The x is either 0 or 2, indicating a controller without or
with a floppy controller on board.
The y is more interesting. It can either be a blank, a
A-8 or a D. A blank indicates a plain 10 Mbits/second
controller. An A-8 indicates a 15 Mbits/second controller
capable of handling 52 sectors/track. A D means a 15
Mbits/second controller that can also handle drives with >
36 sectors/track (also 52 ?).
All variations should be capable of using 1:1
interleaving. Use 1:1, FreeBSD is fast enough to handle
it.
Western Digital WD1007 controllers
I successfully installed FreeBSD onto a ESDI disk
controlled by a WD1007 controller. To be precise, it was a
WD1007-WA2. Other variations of the WD1007 do exist.
To get it to work, I had to disable the sector translation
and the WD1007's onboard BIOS. This implied I could not use
the low-level formatter built into this BIOS. Instead, I
grabbed WDFMT.EXE from www.wdc.com Running this formatted my
drive just fine.
Ultrastor U14F controllers
According to multiple reports from the net, Ultrastor ESDI
boards work OK with FreeBSD. I lack any further info on
particular settings.
Further reading
If you intend to do some serious ESDI hacking, you might
want to have the official standard at hand:
The latest ANSI X3T10 committee document is:
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11]
On Usenet the newsgroup comp.periphs is a noteworthy
place to look for more info.
The World Wide Web (WWW) also proves to be a very handy info
source: For info on Adaptec ESDI controllers see http://www.adaptec.com/.
For info on Western Digital controllers see http://www.wdc.com/.
Thanks to...
Andrew Gordon for sending me an Adaptec 2320 controller and
ESDI disk for testing.
What is SCSI?
Copyright © 1995, &a.wilko;.July
6, 1996.
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 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 million transfers per second
(20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers
per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold
today are single-ended Ultra SCSI (8 or 16 bits).
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.
Components of SCSI
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.
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.
SCSI bus types
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:
FWD: Fast Wide Differential
FND: Fast Narrow Differential
SE: Single Ended
FN: Fast Narrow
etc.
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 million transfers/second are also
emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI).
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.
Single ended buses
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
million transfers/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.
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 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.
Differential buses
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.
Terminators
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. Many SCSI devices come 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 not mix 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: every
single line on the SCSI bus has 2 (two) terminators, one at
each end of the bus. 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. (Note the
“potential” here; the nastiest part is that it may or may not
work.)
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.
Termination is to be done on a per-line basis. This
means if you have both narrow and wide buses connected to
the same host adapter, you need to enable termination on the
higher 8 bits of the bus on the adapter (as well as the last
devices on each bus, of course).
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 are software
configurable, using some sort of setup tool. Some will even
auto-detect the cables attached to the connectors and
automatically set up the termination as necessary. At any
rate, consult your documentation!
Terminator power
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.
Device addressing
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. Some SCSI host adapters let you change
the target ID from the boot menu. (Yet some others will not
let you change the ID from 7.) 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 (usually 16).
A narrow SCSI device can not communicate with a SCSI
device with a target ID larger than 7. This means it is
generally not a good idea to move your SCSI host adapter's
target ID to something higher than 7 (or your CD-ROM will
stop working).
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. Note however that the
lower 8 IDs have higher priorities than the higher 8 IDs on a
wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI
system. (If you you are wondering why the lower 8 have higher
priority, read the previous paragraph for a hint.)
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.
Bus layout
SCSI buses are linear. So, not shaped like Y-junctions,
star topologies, rings, cobwebs or whatever else people might
want to invent. One of the most common mistakes is for people
with wide-SCSI host adapters to connect devices on all three
connecters (external connector, internal wide connector,
internal narrow connector). Don't do that. It may appear to
work if you are really lucky, but I can almost guarantee that
your system will stop functioning at the most unfortunate
moment (this is also known as “Murphy's law”).
You might notice that the terminator issue discussed
earlier becomes rather hairy if your bus is not linear. Also,
if you have more connectors than devices on your internal SCSI
cable, make sure you attach devices on connectors on both ends
instead of using the connectors in the middle and let one or
both ends dangle. This will screw up the termination of the
bus.
The electrical characteristics, its noise margins and
ultimately the reliability of it all are tightly related to
linear bus rule.
Stick to the linear bus
rule!
Using SCSI with FreeBSD
About translations, BIOSes and magic...
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
translated 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 all operating systems on the disk use
the same translation 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:
aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512
Newer kernels usually do not report this information. e.g.
(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)
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 if the BIOS is never going to know about
this disk, (e.g. it is not a booting disk) to
supply a fictitious geometry that is convenient.
SCSI subsystem design
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), CD-ROMs (cd) etc. In case you are wondering where you
can find this stuff, it all lives in
/sys/scsi. 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.
Kernel configuration
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
not 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.
Note that most of the EISA/PCI drivers (namely
ahb, ahc,
ncr and
amd will automatically obtain the
correct parameters from the host adapters themselves at boot
time; thus, you just need to write, for instance,
controller ahc0.
An example loosely based on the FreeBSD 2.2.5-Release
kernel config file LINT with some added comments (between
[]):
# 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!)
# amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T)
# bt: Most Buslogic controllers
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
# ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards
# 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/294x/394x etc controller]
controller ahc0
[For an NCR/Symbios 53c875 based controller]
controller ncr0
[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 ncr0
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 ncr0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CD-ROM found, no wiring]
The example above tells the kernel to look for a ahc
(Adaptec 274x) controller, then for an NCR/Symbios board, and
so on. The lines following the controller specifications tell
the kernel to configure specific devices but
only 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.
Wired down devices need not be found 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 no 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 /etc/fstab
each time.
Although the old style still works, you are
strongly 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.
[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 CD-ROM]
device cd0 #Only need one of these, the code dynamically grows
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 man 4 scsi to check for
the latest info on the SCSI subsystem. For more detailed info
on host adapter drivers use eg man 4
ahc for info on the Adaptec 294x driver.
Tuning your SCSI kernel setup
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, CD-ROM 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:
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
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
CD-ROM 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.
Rogue SCSI devices
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:
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
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 CD-ROM 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.
Multiple LUN devices
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 initialized like below:
{
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
"mx1", SC_ONE_LU
}
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:
{
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
"sd", SC_MORE_LUS
}
The kernel on boot scans the inquiry data it receives
against the table and acts accordingly. See the source for
more info.
Tagged command queueing
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.
Busmaster host adapters
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:
options "TUNE_1542" #dynamic tune of bus DMA speed
Check the man pages for the host adapter that you use. Or
better still, use the ultimate documentation (read: driver
source).
Tracking down problems
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.
Check for loose connectors and cables.
Check and double check the location and number of your
terminators.
Check if your bus has at least one supplier of
terminator power (especially with external
terminators.
Check if no double target IDs are used.
Check if all devices to be used are powered up.
Make a minimal bus config with as little devices as
possible.
If possible, configure your host adapter to use slow
bus speeds.
Disable tagged command queuing to make things as
simple as possible (for a NCR hostadapter based system see
man ncrcontrol)
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 /sys/scsi/scsidebug.h.
If it probes but just does not work, you can use the
scsi8 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 man 4
scsi for more exact information. Also look at
man 8 scsi.
Further reading
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
13th Floor
11 West 42nd Street
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:
AT Attachment (ATA or IDE) [X3.221-1994]
(Approved)
ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
Enhanced Small Device Interface (ESDI)
[X3.170-1990/X3.170a-1991]
(Approved)
Small Computer System Interface — 2 (SCSI-2)
[X3.131-1994] (Approved)
SCSI-2 Common Access Method Transport and SCSI
Interface Module (CAM) [X3T10/792D Rev 11]
Other publications that might provide you with
additional information are:
“SCSI: Understanding the Small Computer System
Interface”, written by NCR Corporation. Available from:
Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201)
767-5937 ISBN 0-13-796855-8
“Basics of SCSI”, a SCSI tutorial written by Ancot
Corporation Contact Ancot for availability information at:
Phone: (415) 322-5322 Fax: (415) 322-0455
“SCSI Interconnection Guide Book”, an AMP publication
(dated 4/93, Catalog 65237) that lists the various SCSI
connectors and suggests cabling schemes. Available from
AMP at (800) 522-6752 or (717) 564-0100
“Fast Track to SCSI”, A Product Guide written by
Fujitsu. Available from: Prentice Hall, Englewood Cliffs,
NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X
“The SCSI Bench Reference”, “The SCSI Encyclopedia”,
and the “SCSI Tutor”, ENDL Publications, 14426 Black
Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642
“Zadian SCSI Navigator” (quick ref. book) and
“Discover the Power of SCSI” (First book along with a
one-hour video and tutorial book), Zadian Software, Suite
214, 1210 S. Bascom Ave., San Jose, CA 92128, (408)
293-0800
On Usenet the newsgroups comp.periphs.scsi and
comp.periphs are
noteworthy places to look for more info. You can also find the
SCSI-Faq there, which 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.
* Disk/tape controllers
* SCSI
* IDE
* Floppy
Hard drives
SCSI hard drives
Contributed by &a.asami;.17 February
1998.
As mentioned in the SCSI
section, virtually all SCSI hard drives sold today are SCSI-2
compliant and thus will work fine as long as you connect them to
a supported SCSI host adapter. Most problems people encounter
are either due to badly designed cabling (cable too long, star
topology, etc.), insufficient termination, or defective parts.
Please refer to the SCSI
section first if your SCSI hard drive is not working. However,
there are a couple of things you may want to take into account
before you purchase SCSI hard drives for your system.
Rotational speed
Rotational speeds of SCSI drives sold today range from
around 4,500RPM to 10,000RPM. Most of them are either 5,400RPM
or 7,200RPM. Even though the 7,200RPM drives can generally
transfer data faster, they run considerably hotter than their
5,400RPM counterparts. A large fraction of today's disk drive
malfunctions are heat-related. If you do not have very good
cooling in your PC case, you may want to stick with 5,400RPM
or slower drives.
Note that newer drives, with higher areal recording
densities, can deliver much more bits per rotation than older
ones. Today's top-of-line 5,400RPM drives can sustain a
throughput comparable to 7,200RPM drives of one or two model
generations ago. The number to find on the spec sheet for
bandwidth is “internal data (or transfer) rate”. It is
usually in megabits/sec so divide it by 8 and you'll get the
rough approximation of how much megabytes/sec you can get out
of the drive.
(If you are a speed maniac and want a 10,000RPM drive for
your cute little peecee, be my guest; however, those drives
become extremely hot. Don't even think about it if you don't
have a fan blowing air directly at the
drive or a properly ventilated disk enclosure.)
Obviously, the latest 10,000RPM drives and 7,200RPM drives
can deliver more data than the latest 5,400RPM drives, so if
absolute bandwidth is the necessity for your applications, you
have little choice but to get the faster drives. Also, if you
need low latency, faster drives are better; not only do they
usually have lower average seek times, but also the rotational
delay is one place where slow-spinning drives can never beat a
faster one. (The average rotational latency is half the time
it takes to rotate the drive once; thus, it's 3 milliseconds
for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for
5,400RPM drives.) Latency is seek time plus rotational delay.
Make sure you understand whether you need low latency or more
accesses per second, though; in the latter case (e.g., news
servers), it may not be optimal to purchase one big fast
drive. You can achieve similar or even better results by
using the ccd (concatenated disk) driver to create a striped
disk array out of multiple slower drives for comparable
overall cost.
Make sure you have adequate air flow around the drive,
especially if you are going to use a fast-spinning drive. You
generally need at least 1/2" (1.25cm) of spacing above and
below a drive. Understand how the air flows through your PC
case. Most cases have the power supply suck the air out of
the back. See where the air flows in, and put the drive where
it will have the largest volume of cool air flowing around it.
You may need to seal some unwanted holes or add a new fan for
effective cooling.
Another consideration is noise. Many 7,200 or faster
drives generate a high-pitched whine which is quite unpleasant
to most people. That, plus the extra fans often required for
cooling, may make 7,200 or faster drives unsuitable for some
office and home environments.
Form factor
Most SCSI drives sold today are of 3.5" form factor. They
come in two different heights; 1.6" (“half-height”) or 1"
(“low-profile”). The half-height drive is the same height as a
CD-ROM drive. However, don't forget the spacing rule
mentioned in the previous section. If you have three standard
3.5" drive bays, you will not be able to put three half-height
drives in there (without frying them, that is).
Interface
The majority of SCSI hard drives sold today are Ultra or
Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is
20MB/sec, and Ultra-wide SCSI is 40MB/sec. There is no
difference in max cable length between Ultra and Ultra-wide;
however, the more devices you have on the same bus, the sooner
you will start having bus integrity problems. Unless you have
a well-designed disk enclosure, it is not easy to make more
than 5 or 6 Ultra SCSI drives work on a single bus.
On the other hand, if you need to connect many drives,
going for Fast-wide SCSI may not be a bad idea. That will
have the same max bandwidth as Ultra (narrow) SCSI, while
electronically it's much easier to get it “right”. My advice
would be: if you want to connect many disks, get wide SCSI
drives; they usually cost a little more but it may save you
down the road. (Besides, if you can't afford the cost
difference, you shouldn't be building a disk array.)
There are two variant of wide SCSI drives; 68-pin and
80-pin SCA (Single Connector Attach). The SCA drives don't
have a separate 4-pin power connector, and also read the SCSI
ID settings through the 80-pin connector. If you are really
serious about building a large storage system, get SCA drives
and a good SCA enclosure (dual power supply with at least one
extra fan). They are more electronically sound than 68-pin
counterparts because there is no “stub” of the SCSI bus inside
the disk canister as in arrays built from 68-pin drives. They
are easier to install too (you just need to screw the drive in
the canister, instead of trying to squeeze in your fingers in
a tight place to hook up all the little cables (like the SCSI
ID and disk activity LED lines).
* IDE hard drives
Tape drives
Contributed by &a.jmb;.2 July
1996.
General tape access commands
mt1 provides generic access to the tape
drives. Some of the more common commands are
rewind, erase, and
status. See the mt1
manual page for a detailed description.
Controller Interfaces
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
Disk/tape
controllers.
SCSI drives
The st4 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
st4 manual page for a detailed
description.
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.
4mm (DAT: Digital Audio Tape)
Archive
Python
HP
C1533A
HP
C1534A
HP
35450A
HP
35470A
HP
35480A
SDT-5000
Wangtek
6200
8mm (Exabyte)
EXB-8200
EXB-8500
EXB-8505
QIC (Quarter-Inch Cartridge)
Archive
Ananconda 2750
Archive Viper
60
Archive Viper
150
Archive Viper
2525
Tandberg
TDC 3600
Tandberg
TDC 3620
Tandberg
TDC 4222
Wangtek
5525ES
DLT (Digital Linear Tape)
Digital
TZ87
Mini-Cartridge
Conner CTMS
3200
Exabyte
2501
Autoloaders/Changers
Hewlett-Packard
HP C1553A Autoloading DDS2
* IDE drives
Floppy drives
Conner
420R
* Parallel port drives
Detailed Information
Archive Anaconda 2750
The boot message identifier for this drive is
ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI
2
This is a QIC tape drive.
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.
Data transfer rate is 350kB/s using
dump8. Rates of 530kB/s have been
reported when using Amanda
Production of this drive has been discontinued.
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.
Two kernel code changes are required to use this drive.
This drive will not work as delivered.
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.
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.
*** 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,
Reported by: &a.jmb;
Archive Python
The boot message identifier for this drive is
ARCHIVE Python 28454-XXX4ASB type
1 removable SCSI 2 density code 0x8c,
512-byte blocks
This is a DDS-1 tape drive.
Native capacity is 2.5GB on 90m tapes.
Data transfer rate is XXX.
This drive was repackaged by Sun Microsystems as model
411.
Reported by: Bob Bishop rb@gid.co.uk
Archive Viper 60
The boot message identifier for this drive is
ARCHIVE VIPER 60 21116 -007 type 1
removable SCSI 1
This is a QIC tape drive.
Native capacity is 60MB.
Data transfer rate is XXX.
Production of this drive has been discontinued.
Reported by: Philippe Regnauld regnauld@hsc.fr
Archive Viper 150
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.
This is a QIC tape drive.
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.
Data transfer rate is 100kB/s
This drive reads and writes DC6150 (150MB) and DC6250
(250MB) tapes.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Under FreeBSD 2.2-current, use mt
blocksize 512 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.
Production of this drive has been discontinued.
Reported by: Pedro A M Vazquez
vazquez@IQM.Unicamp.BR
Mike Smith
msmith@atrad.adelaide.edu.au
Archive Viper 2525
The boot message identifier for this drive is ARCHIVE
VIPER 2525 25462 -011 type 1 removable SCSI 1
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s at 90 inches/sec.
The drive reads QIC-525, QIC-150, QIC-120 and QIC-24
tapes. Writes QIC-525, QIC-150, and QIC-120.
Firmware revisions prior to 25462 -011 are bug ridden
and will not function properly.
Production of this drive has been discontinued.
Conner 420R
The boot message identifier for this drive is Conner
tape.
This is a floppy controller, minicartridge tape
drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-80 tape cartridges.
Reported by: Mark Hannon mark@seeware.DIALix.oz.au
Conner CTMS 3200
The boot message identifier for this drive is CONNER CTMS
3200 7.00 type 1 removable SCSI 2.
This is a minicartridge tape drive.
Native capacity is XXXX
Data transfer rate is XXX
The drive uses QIC-3080 tape cartridges.
Reported by: Thomas S. Traylor tst@titan.cs.mci.com
<ulink
URL="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink>
The boot message identifier for this drive is DEC TZ87
(C) DEC 9206 type 1 removable SCSI 2 density code
0x19
This is a DLT tape drive.
Native capacity is 10GB.
This drive supports hardware data compression.
Data transfer rate is 1.2MB/s.
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.
Reported by: &a.wilko;
<ulink
URL="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink>
The boot message identifier for this drive is EXABYTE
EXB-2501
This is a mini-cartridge tape drive.
Native capacity is 1GB when using MC3000XL
minicartridges.
Data transfer rate is XXX
This drive can read and write DC2300 (550MB), DC2750
(750MB), MC3000 (750MB), and MC3000XL (1GB)
minicartridges.
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
&prompt.root; mt -f /dev/st0ctl.0 blocksize 1024
Before using a minicartridge for the first time, the
minicartridge must be formated. FreeBSD 2.1.0-RELEASE and
earlier:
&prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0"
(Alternatively, fetch a copy of the scsiformat shell script from FreeBSD
2.1.5/2.2.) FreeBSD 2.1.5 and later:
&prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl
Right now, this drive cannot really be recommended for
FreeBSD.
Reported by: Bob Beaulieu ez@eztravel.com
Exabyte EXB-8200
The boot message identifier for this drive is EXABYTE
EXB-8200 252X type 1 removable SCSI 1
This is an 8mm tape drive.
Native capacity is 2.3GB.
Data transfer rate is 270kB/s.
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).
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.
Production of this drive has been discontinued.
Reported by: Mike Smith
msmith@atrad.adelaide.edu.au
Exabyte EXB-8500
The boot message identifier for this drive is EXABYTE
EXB-8500-85Qanx0 0415 type 1 removable SCSI 2
This is an 8mm tape drive.
Native capacity is 5GB.
Data transfer rate is 300kB/s.
Reported by: Greg Lehey grog@lemis.de
<ulink
URL="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink>
The boot message identifier for this drive is EXABYTE
EXB-85058SQANXR1 05B0 type 1 removable SCSI 2
This is an 8mm tape drive which supports compression, and
is upward compatible with the EXB-5200 and EXB-8500.
Native capacity is 5GB.
The drive supports hardware data compression.
Data transfer rate is 300kB/s.
Reported by: Glen Foster gfoster@gfoster.com
Hewlett-Packard HP C1533A
The boot message identifier for this drive is HP C1533A
9503 type 1 removable SCSI 2.
This is a DDS-2 tape drive. DDS-2 means hardware data
compression and narrower tracks for increased data
capacity.
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s.
This drive is used in Hewlett-Packard's SureStore 6000eU
and 6000i tape drives and C1533A DDS-2 DAT drive.
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.
switch 1
switch 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, with host
control
Off
Off
Compression disabled at power-on, no host
control
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.
See HP
SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 2 of these drives. Neither lasted more than 5
months.
Reported by: &a.se;
Hewlett-Packard HP 1534A
The boot message identifier for this drive is HP HP35470A
T503 type 1 removable SCSI 2 Sequential-Access density code
0x13, variable blocks.
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive and HP C1536A DDS format DAT drive.
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?)
Reported by Gary Crutcher gcrutchr@nightflight.com
Hewlett-Packard HP C1553A Autoloading DDS2
The boot message identifier for this drive is "".
This is a DDS-2 tape drive with a tape changer. DDS-2
means hardware data compression and narrower tracks for
increased data capacity.
Native capacity is 24GB when using 120m tapes. This drive
supports hardware data compression.
Data transfer rate is 510kB/s (native).
This drive is used in Hewlett-Packard's SureStore 12000e
tape drive.
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.
There are four internal switches. These should be set: 1
ON; 2 ON; 3 ON; 4 OFF.
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:
#!/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"
Hewlett-Packard HP 35450A
The boot message identifier for this drive is HP HP35450A
-A C620 type 1 removable SCSI 2 Sequential-Access density
code 0x13
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 1.2GB.
Data transfer rate is 160kB/s.
Reported by: mark thompson
mark.a.thompson@pobox.com
Hewlett-Packard HP 35470A
The boot message identifier for this drive is HP HP35470A
9 09 type 1 removable SCSI 2
This is a DDS-1 tape drive. DDS-1 is the original DAT
tape format.
Native capacity is 2GB when using 90m tapes.
Data transfer rate is 183kB/s.
The same mechanism is used in Hewlett-Packard's SureStore
2000i
tape drive, C35470A DDS format DAT drive, C1534A DDS format
DAT drive, and HP C1536A DDS format DAT drive.
Warning: Quality control on these
drives varies greatly. One FreeBSD core-team member has
returned 5 of these drives. None lasted more than 9
months.
Reported by: David Dawes dawes@rf900.physics.usyd.edu.au
(9 09)
Hewlett-Packard HP 35480A
The boot message identifier for this drive is HP HP35480A
1009 type 1 removable SCSI 2 Sequential-Access density
code 0x13.
This is a DDS-DC tape drive. DDS-DC is DDS-1 with
hardware data compression. DDS-1 is the original DAT tape
format.
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 HP
C1533A for the proper switch settings.
Data transfer rate is 183kB/s.
This drive is used in Hewlett-Packard's SureStore 5000eU
and 5000i
tape drives and C35480A DDS format DAT drive..
This drive will occasionally hang during a tape eject
operation (mt offline).
Pressing the front panel button will eject the tape and bring
the tape drive back to life.
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.
<ulink
URL="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink>
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.
The boot message identifier for this drive is SONY
SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access
density code 0x13
Native capacity is 4GB when using 120m tapes. This drive
supports hardware data compression.
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.
In order to get this drive to stream, set the blocksize to
512 bytes (mt blocksize 512)
reported by Kenneth Merry
ken@ulc199.residence.gatech.edu
SONY SDT-5000 327M information reported by Charles
Henrich henrich@msu.edu
Reported by: &a.jmz;
Tandberg TDC 3600
The boot message identifier for this drive is TANDBERG
TDC 3600 =08: type 1 removable SCSI 2
This is a QIC tape drive.
Native capacity is 150/250MB.
This drive has quirks which are known and work around code
is present in the scsi tape device driver (st4). Upgrading the firmware to XXX
version will fix the quirks and provide SCSI 2
capabilities.
Data transfer rate is 80kB/s.
IBM and Emerald units will not work. Replacing the
firmware EPROM of these units will solve the problem.
Reported by: Michael Smith
msmith@atrad.adelaide.edu.au
Tandberg TDC 3620
This is very similar to the Tandberg TDC 3600
drive.
Reported by: &a.joerg;
Tandberg TDC 4222
The boot message identifier for this drive is TANDBERG
TDC 4222 =07 type 1 removable SCSI 2
This is a QIC tape drive.
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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4)
beginning with FreeBSD 2.2-current. For previous versions of
FreeBSD, use mt to read one
block from the tape, rewind the tape, and then execute the
backup program (mt fsr 1; mt rewind; dump
...)
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.
Reported by: &a.joerg;
Wangtek 5525ES
The boot message identifier for this drive is WANGTEK
5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code
0x11, 1024-byte blocks
This is a QIC tape drive.
Native capacity is 525MB.
Data transfer rate is 180kB/s.
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 (mt erase) 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.
This drives quirks are known and pre-compiled into the
scsi tape device driver (st4).
Other firmware revisions that are known to work are:
M75D
Reported by: Marc van Kempen marc@bowtie.nl REV73R1
Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D
Wangtek 6200
The boot message identifier for this drive is WANGTEK
6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access
density code 0x13
This is a DDS-1 tape drive.
Native capacity is 2GB using 90m tapes.
Data transfer rate is 150kB/s.
Reported by: Tony Kimball alk@Think.COM
* Problem drives
CD-ROM drives
Contributed by &a.obrien;.23 November
1997.
As mentioned in
Jordan's Picks
Generally speaking those in The FreeBSD
Project 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 controllable by the various audio player
software.
Another area where SCSI CDROM manufacturers are cutting
corners is adhearance to the
SCSI specification.
Many SCSI CDROMs will respond to
multiple LUNs for its
target address. Known violators include the 6x Teac CD-56S
1.0D.
* Other
* Other
* PCMCIA