Archive-name: linux/howto/scsi/part1
Version: 2.08
Last-modified: 3 Jun 95

  Linux SCSI HOWTO
  Drew Eckhardt, d...@cs.colorado.edu
  v2.15, 20 March 1995

  This HOWTO covers the Linux SCSI subsystem, as implemented in Linux
  kernel revision 1.1.74 and newer alpha code.  Earlier revisions of the
  SCSI code are unsupported, and may differ significantly in terms of
  the drivers implemented, performance, and options available.

  1.  Introduction

  1.1.  License

  Noncommercial redistributions of a verbatim copy in any medium
  physical or electronic are permitted without express permission of the
  author.  Translations are similarly permitted without express
  permission if they includes a notice on who translated it.

  Commercial redistribution is allowed and encouraged, provided that the
  author is notified of any such distributions and given opportunity to
  to provide a more up-to-date version.

  Short quotes may be used without prior consent by the author.
  Derivative work and partial distributions of the SCSI-HOWTO must
  include either a verbatim copy of this file or make a verbatim copy of
  this file available. If the latter is the case, a pointer to the
  verbatim copy must be stated at a clearly visible place.

  In short, we wish to promote dissemination of this information through
  as many channels as possible. However, we do wish to retain copyright
  on the HOWTO documents, to be notified of any plans to redistribute
  the HOWTOs to insure that outdated versions don't spread too far, and
  for ALL the information provided in the HOWTOS to be disseminated. If
  you have questions on the Linux documentation project, please contact
  Matt Welsh, the Linux HOWTO coordinator, at m...@sunsite.unc.edu.
  Questions regarding this document itself should be addressed to Drew
  Eckhardt, d...@Colorado.EDU.

  1.2.  Important Note

  IMPORTANT:

  BUG REPORTS WHICH FAIL TO FOLLOW THE PROCEDURE OUTLINED IN SECTION 2
  WILL BE IGNORED.

  For additional information, you may wish to join the SCSI channel of
  the Linux activists list - mail to linux-activists-
  requ...@joker.cs.hut.fi.  with the line

  X-Mn-Admin: join SCSI

  in the header, as well as the Linux SCSI list by mailing
  majord...@vger.rutgers.edu with the line

  subscribe linux-scsi

  in the text.

  I'm aware that this document isn't the most user-friendly, and that
  there may be inaccuracies and oversights.  If you have constructive
  comments on how to rectify the situation you're free to mail me about
  it.

  2.  Common Problems

  This section lists some of the common problems that people have.  If
  there is not anything here that answers your questions, you should
  also consult the sections for your host adapter and the devices in
  that are giving you problems.

  2.1.  General Flakiness

  If you experience random errors, the most likely causes are cabling
  and termination problems.

  Some products, such as those built arround the newer NCR chips,
  feature digital filtering and active signal negation, and aren't very
  sensitive to cabling problems.

  Others, such as the Adaptec 154xC, 154xCF, and 274x, are extremely
  sensitive and may fail with cables that work with other systems.

  I reiterate: some host adapters are extremely sensitive to cabling and
  termination problems and therefore, cabling and termination should be
  the first things checked when there are problems.

  To minimize your problems, you should use cables which

  1. Claim SCSI-II compliance

  2. Have a characteristic impedance of 132 ohms

  3. All come from the same source to avoid impedance mismatches

  4. Come from a reputable vendor such as Amphenol

  Termination power should be provided by all devices on the SCSI bus,
  through a diode to prevent current backflow, so that sufficient power
  is available at the ends of the cable where it is needed.  To prevent
  damage if the bus is shorted, TERMPWR should be driven through a fuse
  or other current limiting device.

  If multiple devices, external cables, or FAST SCSI 2 are used, active
  or forced perfect termination should be used on both ends of the SCSI
  bus.

  See the comp.periphs.scsi FAQ
  (ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi) for more information about
  active termination.

  2.2.  The kernel command line

  Other parts of the documentation refer to a ``kernel command line''.

  The kernel command line is a set of options you may specify from
  either the LILO: prompt after an image name, or in the append field in
  your LILO configuration file (LILO .14 and newer use /etc/lilo.conf,
  older versions use /etc/lilo/config).

  Boot your system with LILO, and hit one of the alt, control, or shift
  keys when it first comes up to get a prompt.  LILO should respond with

       boot:

  At this prompt, you can select a kernel image to boot, or list them
  with ``?''.  Ie

       boot: ?

       ramdisk floppy harddisk

  To boot that kernel with the command line options you have selected,
  simply enter the name followed by a white space delimited list of
  options, terminating with a return.

  Options take the form of

  variable=valuelist

  Where valuelist may be a single value or comma delimited list of
  values with no whitespace.  With the exception of root device,
  individual values are numbers, and may be specified in either decimal
  or hexadecimal.

  Ie, to boot linux with an Adaptec 1520 clone not recognized at bootup,
  you might type

       boot: floppy aha152x=0x340,11,7,1

  If you don't care to type all of this at boot time, it is also
  possible to use the LILO configuration file ``append'' option with
  LILO .13 and newer.

  Ie,

       append="aha152x=0x340,11,7,1"

  2.3.  A SCSI device shows up at all possible IDs

  If this is the case, you have strapped the device at the same address
  as the controller (typically 7, although some boards use other
  addresses, with 6 being used by some Future Domain boards).
  Please change the jumper settings.

  2.4.  A SCSI device shows up at all possible LUNs

  The device has buggy firmware.

  As an interim solution, you should try using the kernel command line
  option

       max_scsi_luns=1

  If that works, there is a list of buggy devices in the kernel sources
  in drivers/scsi/scsi.c in the variable blacklist.  Add your device to
  this list and mail the patch to Linus.

  2.5.  You get sense errors when you know the devices are error free

  Sometimes this is caused by bad cables or impropper termination.

  See ``'': General Flakiness

  2.6.  A kernel configured with networking does not work.

  The auto-probe routines for many of the network drivers are not
  passive, and will interfere with operation with some of the SCSI
  drivers.

  2.7.  Device detected, but unable to access.

  A SCSI device is detected by the kernel, but you are unable to access
  it - ie mkfs /dev/sdc, tar xvf /dev/rst2, etc fails.

  You don't have a special file in /dev for the device.

  Unix devices are identified as either block or character (block
  devices go through the buffer cache, character devices do not)
  devices, a major number (ie which driver is used - block major 8
  corresponds to SCSI disks) and a minor number (ie which unit is being
  accessed through a given driver - ie character major 4, minor 0 is the
  first virtual console, minor 1 the next, etc).  However, accessing
  devices through this separate namespace would break the unix/Linux
  metaphor of ``everything is a file,'' so character and block device
  special files are created under /dev.  This lets you access the raw
  third SCSI disk device as /dev/sdc, the first serial port as
  /dev/ttyS0, etc.

  The preferred method for creating a file is using the MAKEDEV script:

       cd /dev

  and run MAKEDEV (as root) for the devices you want to create - ie

  wildcards ``should'' work - ie

  ``should'' create entries for all SCSI disk devices (doing this should
  create /dev/sda through /dev/sdp, with fif{*filter*} partition entries for
  each)

  ``should'' create entries for /dev/sdc and all fif{*filter*} permissible
  partitions on /dev/sdc, etc.

  I say ``should'' because this is the standard unix behavior - the
  MAKEDEV script in your installation may not conform to this behavior,
  or may have restricted the number of devices it will create.

  If MAKEDEV won't do the right magic for you, you'll have to create the
  device entries by hand with the mknod command.

  The block/character type, major, and minor numbers are specified for
  the various SCSI devices in Subsection 3: Device Files in the
  appropriate section.

  Take those numbers, and use (as root)

       mknod /dev/device b|c major minor

  ie -

       mknod /dev/sdc b 8 32
       mknod /dev/rst0 c 9 0

  2.8.  SCSI System Lockups

  This could be one of a number of things.  Also see the section for
  your specific host adapter for possible further solutions.

  There are cases where the lockups seem to occur when multiple devices
  are in use at the same time.  In this case, you can try contacting the
  manufacturer of the devices and see if firmware upgrades are available
  which would correct the problem.  If possible, try a different scsi
  cable, or try on another system.  This can also be caused by bad
  blocks on disks, or by bad handling of DMA by the motherboard (for
  host adapters that do DMA).  There are probably many other possible
  conditions that could lead to this type of event.

  Sometimes these problems occur when there are multiple devices in use
  on the bus at the same time.  In this case, if your host adapter
  driver supports more than one outstanding command on the bus at one
  time, try reducing this to 1 and see if this helps. If you have tape
  drives or slow cdrom drives on the bus, this might not be a practical
  solution.

  2.9.  Configuring and building the kernel

  Unused SCSI drivers eat
...

read more »

Archive-name: linux/howto/scsi/part2
Version: 2.08
Last-modified: 3 Jun 95

---This is part 2/3---

  4.5.  Adaptec 174x

     Supported Configurations:

        Slots:
           1-8

        Ports:
           EISA board, not applicable

        IRQs:
           9, 10, 11, 12, 14, 15

        DMA Channels:
           EISA board, not applicable

        IO:
           port mapped, bus master

     Autoprobe:
        works with all supported configurations

     Autoprobe override:
        none

     Note:
        This board has been discontinued by Adaptec.

     Common Problems:

        1. If the Adaptec 1740 driver prints the message ``aha1740:
           Board detected, but EBCNTRL = % x, so disabled it.''  your
           board was disabled because it was not running in enhanced
           mode.  Boards running in standard 1542 mode are not
           supported.

  4.6.  Adaptec 274x, 284x, 294x (Standard)

  Newer revisions may be available at
  (ftp://ftp.cpsc.ucalgary.ca/pub/systems/linux/aha274x/aha274x-pre-
  alpha.tar .gz)

  Supported Configurations:

     274x:

        EISA Slots:
           1-12

        IRQs:
           ALL

        IO:
           port mapped, bus master

     284x:

        Ports:
           All

        IRQs:
           All

        DMA Channels:
           All

     294x
        PCI

     Note:
        BIOS MUST be enabled

     Note:
        The B channel on 2742AT boards is ignored.

  4.7.  Always IN2000  (ALPHA)

  ALPHA driver available at
  (ftp://tsx-11.mit.edu/pub/linux/ALPHA/SCSI/in2000).  The driver is
  in2000.tar.z, bootable kernel zImage

     Port:
        0x100, 0x110, 0x200, 0x220

     IRQs:
        10, 11, 14, 15

     DMA:
        not used

     IO:
        port mapped

     Autoprobe:
        BIOS not required

     Autoprobe override:
        none

     Common Problems:

        1. There are known problems in systems with IDE drives and with
           swapping.

  4.8.  EATA: DPT Smartcache, Smartcache Plus, Smartcache III (Standard)

     Supported boards:
        all, that support the EATA-DMA protocol (no PM2001).

        DPT Smartcache:
           PM2011  PM2012A PM2012B

        Smartcache III:
           PM2021  PM2022  PM2024 PM2122  PM2124 PM2322

        SmartRAID:
           PM3021  PM3222  PM3224 many of those boards are also
           available as SKXXXX versions, which are supported as well.

     Supported Configurations:

        Slots:
           ALL

        Ports:
           ALL

        IRQs:
           ALL level & edge triggered

        DMA Channels:
           ISA ALL, EISA/PCI not applicable

        IO:
           port mapped, bus master

        SCSI Channels:
           ALL

        Autoprobe:
           works with all supported configurations

        Compile time:
           diskgeometry in eata_dma.h for unusual disk geometries which
           came from the usage of the old DPTFMT utility.  The latest
           version of the EATA-DMA driver and a Slackware bootdisk
           should be available on: (ftp://ftp.uni-
           mainz.de/pub/Linux/arch/i386/system/EATA/)

        Common Problems:

           1. The IDE driver detects the ST-506 interface of the EATA
              board.

              a. This will look like similar to one of the following 2
                 examples:

                   hd.c: ST-506 interface disk with more than 16 heads detected,
                   probably due to non-standard sector translation.  Giving up.
                   (disk % d: cyl=% d, sect=63, head=64)

                   hdc: probing with STATUS instead of ALTSTATUS
                   hdc: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
                   hdc: cannot handle disk with 0 physical heads
                   hdd: probing with STATUS instead of ALTSTATUS
                   hdd: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
                   hdd: cannot handle disk with 0 physical heads

              If the IDE driver gets into trouble because of this, ie.
              you can't access your (real) IDE hardware, change the IO
              Port and/or the IRQ of the EATA board.

              b. If the IDE driver finds hardware it can handle ie.
                 harddisks with a capacity < =504MB, it      will allocate
                 the IO Port and IRQ, so that the eata driver can't
                 utilize them. In this case also change IO Port and IRQ
                 (!= 14,15).

           2. Some old SK2011 boards have a broken firmware. Please
              contact DPT's customer support for an update.

  4.9.  p Future Domain 16x0 with TMC-1800, TMC-18C30, TMC-18C50, or
  TMC-36C70 chi

     Supported Configurations:

        BIOSs:
           2.0, 3.0, 3.2, 3.4, 3.5

        BIOS Addresses:
           0xc8000, 0xca000, 0xce000, 0xde000

        Ports:
           0x140, 0x150, 0x160, 0x170

        IRQs:
           3, 5, 10, 11, 12, 14, 15

        DMA:
           not used

        IO:
           port mapped

     Autoprobe:
        works with all supported configurations, requires installed BIOS

     Autoprobe Override:
        none

     Antiquity Problems, fix by upgrading:

        1. Old versions do not support the TMC-18C50 chip, and will fail
           with newer boards.

        2. Old versions will not have the most current BIOS signatures
           for autodetection.

        3. Versions prior to the one included in Linux 1.0.9 and 1.1.6
           don't support the new SCSI chip or 3.4 BIOS.

  4.10.  Generic NCR5380 / T130B

     Supported and Unsupported Configurations:

        Ports:
           all

        IRQs:
           all

        DMA:
           not used

        IO:
           port mapped

     Autoprobe:
        none

     Autoprobe Override:

        Compile time:
           Define GENERIC_NCR5380_OVERRIDE to be an array of tupples
           with port, irq, dma, board type - ie

           _____________________________________________________________
           #define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}
           _____________________________________________________________

        for a NCR5380 board at port 330, IRQ 5.

        ________________________________________________________________
        #define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}
        ________________________________________________________________

        for a T130B at port 0x350.

        Older versions of the code eliminate the BOARD_* entry.

        The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.

        kernel command line:

        o  ncr5380=port,irq

        o  ncr5380=port,irq,dma

        o  ncr53c400=port,irq

           255 may be used for no irq, 254 for irq autoprobe.

     Common Problems:

        1. Using the T130B board with the old (pre public release 6)
           generic NCR5380 driver which doesn't support the ncr53c400
           command line option.

           The NCR5380 compatable registers are offset eight from the
           base address.  So, if your address is 0x350, use

             ncr53480=0x358,254

        on the kernel command line.

     Antiquity problems, fix by upgrading :

        1. The kernel locks up during disk access with T130B or other
           NCR53c400 boards

           Pre-public release 6 versions of the Generic NCR5380 driver
           didn't support interrupts on these boards.  Upgrade.

     Notes:
        the generic driver doesn't support DMA yet, and pseudo-DMA isn't
        supported in the generic driver.

  4.11.  NCR53c8xx (Standard)

     Supported and Unsupported Configurations:

        Base addresses:
           ALL
        IRQs:
           ALL

        DMA channels:
           PCI, not applicable

        IO:
           port mapped, busmastering

     Autoprobe:
        requires PCI BIOS, uses PCI BIOS routines to search for devices
        and read configuration space

        The driver uses the pre-programmed values in some registers for
        initialization, so a BIOS must be installed.

     Antiquity Problems, fix by upgrading:

        1. Older versions of Linux had a problem with swapping

           See Section ``'':System Hangs When Swapping

        2. Older versions of Linux didn't recognize '815 and '825
           boards.

     Common Problems:

        1. Many people have encountered problems where the chip worked
           fine under DOS, but failed under Linux with a timeout on test
           1 due to a lost interrupt.

           This is often due to a mismatch between the IRQ hardware
           jumper for a slot or mainboard device and the value set in
           the CMOS setup.

           It may also be due to PCI INTB, INTC, or INTD being selected
           on a PCI board in a system which only supports PCI INTA.

           Finally, PCI should be using level-sensitive rather than edge
           triggered interrupts.  Check that your board is jumpered for
           level-sensitive, and if that fails try edge-triggered because
           your system may be broken.

           This problem is especially common with Viglen some Viglen
           motherboards, where the mainboard IRQ jumper settings are NOT
           as documented in the manual.  I've been told that what claims
           to be IRQ5 is really IRQ9, your mileage will vary.

        2. Lockups occur when using an S3928P, X11, and the NCR chip at
           the same time.

           There are hardware bugs in at least some S3928P chip.  Don't
           do this.

        3. You get a message on boot up indicating that the I/O mapping
           was disabled because base address 0 bits 0..1 indicated a non
           I/O mapping

           This is due to a BIOS bug in some machines which results in
           dword reads of configuration regsisters returning the high
           and low 16 bit words swapped.

        4. Some systems have problems if PCI write posting, or CPU->PCI
           buffering are enabled.  If you have problems, disable these
           options.
        5. Some systems with the NCR SDMS software in an onboard BIOS
           ROM and in the system BIOS are unable to boot DOS.  Disabling
           the image in one place should rectify this problem.

        6. Some systems have hideous, broken, BIOS chips.  Don't make
           any bug reports until you've made sure you have the newest
           ROM from your vendor.

        o  Intel P90 boards require revision 1.00.04.AX1

  4.12.  Seagate ST0x/Future Domain TMC-8xx/TMC-9xx

     Supported and Unsupported Configurations :

        Base addresses:
           0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000

        IRQs:
           3, 5

        DMA:
           not used

        IO:
           memory mapped

     Autoprobe:
        probes for address only, IRQ is assumed to be 5, requires
        installed BIOS.

     Autoprobe Override:

        Compile time:
           Define OVERRIDE to be the base address, CONTROLLER to FD or
           SEAGATE as appropriate, and IRQ to the IRQ.

        kernel command line:
           st0x=address,irq or tmc8xx=address,irq (only works for
           .99.13b and newer)

     Antiquity Problems, fix by upgrading:

        1. .  Versions prior to the one in the Linux .99.12 kernel had a
           problem handshaking with some slow devices, where

           This is what happens when you write data out to the bus

           a. Write byte to data register, data register is asserted to
              bus

           b. time_remaining = 12us

           c. wait while time_remaining > 0 and      REQ is not
...

read more »

Archive-name: linux/howto/scsi/part3
Version: 2.08
Last-modified: 3 Jun 95

---This is part 3/3---

  None :-).

  8.3.  Device Files

  SCSI generic devices use character major 21.  Due to constraints
  imposed by Linux's use of a 16 bit dev_t, minor numbers are
  dynamically assigned from 0, one per device, with

  /dev/sg0

  corresponding to the lowest numerical target/lun on the first SCSI
  board.

  9.  Buyers' Guide

  A frequent question is:

  ``Linux supports quite a number of different boards, so which SCSI
  host adapter should I get.''

  The answer depends upon how much performance you expect or need,
  motherboard, and the scsi peripherals that you plan on attaching to
  your machine.

  9.1.  Transfer types

  The biggest factor affecting performance (in terms of throughput and
  interactive response time during SCSI I/O) is going to be the transfer
  type used.

  9.1.1.  Pure Polled handshaking.

  A pure polled I/O board will use the CPU to handle all of the SCSI
  processing, including the REQ/ACK

  Even a fast CPU will be slower handling the REQ/ACK handshake sequence
  than a simple finite state machine, resulting in peak transfer rates
  of about 150K/sec on a fast machine, perhaps 60K/sec on a slow machine
  (through the filesystem).

  The driver also must sit in a tight loop as long as the SCSI bus is
  busy, resulting in near 100% CPU utilitization and extremely poor
  responsiveness during SCSI/IO.  Slow CDROMs which don't
  disconnect/reconnect will kill interactive performance with these
  boards.

  Not recommended.

  9.1.2.  Interlocked Polled handshaking

  Boards using interlocked polled I/O are essentially the same as pure
  polled I/O boards, only the SCSI REQ/ACK signals the PC bus
  handshaking signals.  All SCSI processing beyond the handshaking is
  handled by the CPU.

  Peak transfer rates of 500-600K/sec through the filesystem re possible
  on these boards.

  As with pure polled I/O boards, the driver must sit in a tight loop as
  long as the SCSI bus is busy, resulting in CPU utilization dependant
  on the transfer rates of the devices, and when they
  disconnect/reconnect.  CPU utilization may vary between 25% for single
  speed CDs which handle disconnect/reconnect properly to 100% for
  faster drives or broken CDROMs which fail to disconnect/reconnect.

  On my 486-66, with a T128, I use 90% of my CPU time to sustain a
  throughput of 547K/sec on a drive with a headrate of 1080K/sec with a
  T128 board.

  Sometimes acceptable for slow tapes and CDROMs when low cost is
  essential.

  9.1.3.  FIFO Polled

  Boards using FIFO polled I/O put a small (typically 8K) buffer between
  the CPU and the SCSI bus, and often implement some amount of
  intelligence.  The net effect is that the CPU is only tied up when it
  is transfering data at top speed to the FIFO and when it's handling
  the rest of the interrupt processing for FIFO empty conditions,
  disconnect/reconnect, etc.

  Peak transfer rates should be sufficient to handle most SCSI devices,
  and have been measured at up to 4M/sec using raw SCSI commands to read
  64K blocks on a fast Seagate Barcuda with an Adaptec 1520.

  CPU utilization is dependant on the transfer rates of the devices,
  with faster devices generating more interrupts per unit time which
  require more CPU processing time.  Although CPU usage may be high
  (perhaps 75%) with fast devices, the system usually remains usable.
  These boards will provide excellent interactive performance with
  broken devices which don't disconnect/reconnect (typically cheap CDROM
  drives)

  Recommended for persons on a budget.

  9.1.4.  Slave DMA

  Drivers for boards using slave DMA program the PC's DMA controller for
  a channel when they do a data transfer, and return control to the CPU.

  Peak transfer rates are usually handicapped by the poor DMA controller
  used on PCs, with one such 8-bit board having problems going faster
  than 140-150K/sec with one mainboard.

  CPU utilization is very reasonable, slightly less than what is seen
  with FIFO polled I/O boards.  These boards are very tollerant of
  broken devices which don't disconnect/reconnect (typically cheap CSG
  limit DROM drives).

  Acceptable for slow CDROM drives, tapes, etc.

  9.1.5.  Busmastering DMA

  These boards are intelligent.  Drivers for these boards throw a SCSI
  command, the destination target and lun, and where the data should end
  upin a structure, and tell the board ``Hey, I have a command for
  you.''  The driver returns control to various running programs, and
  eventually the SCSI board gets back and says that it's done.

  Since the intelligence is in the host adapter firmware and not the
  driver, drivers for these boards typically support more features -
  synchronous transfers, tagged queing, etc.

  With the clustered read/write patches, peak transfer rates through the
  file system approach 100% of head rate writing, 75% reading.

  CPU utilization is minimal, irregardless of I/O load, with a measured
  5% CPU usage while accessing a double speed CDROM on an Adaptec 1540
  and 20% while sustaining a 1.2M/sec transfer rate on a SCSI disk.

  Recommended in all cases where money is not extremely tight, the main
  board is not broken (some broken main boards do not work with bus
  masters), and applications where time to data is more important than
  throughput are not being run (bus master overhead may hit 3-4ms per
  command).

  9.2.  Scatter/gather

  The second most important driver/hardware feature with respect to
  performance is support for scatter/gather I/O.  The overhead of
  executing a SCSI command is significant - on the order of
  milliseconds. Intelligent bus masters like the Adaptec 1540 may take
  3-4ms to process a SCSI command before the target even sees it.  On
  unbuffered devices, this overhead is allways enough to slip a
  revolution, resulting in a transfer rate of about 60K/sec (assuming a
  3600RPM drive) per block transfered at a time.  So, to maximize
  performance, it is necessary to minimize the number of SCSI commands
  needed to transfer a given amount of data by transfering more data per
  command.  Due to the design of the Linux buffer cache, contiguous disk
  blocks are not contiguous in memory. With the clustered read/write
  patches, 4K worth of buffers are contiguous.  So, the maximum amount
  of data which can be transfered per SCSI command is going to be 1K * #
  of scatter/gather regions without the clustered read/write patches, 4K
  * # of regions with.  Experimentally, we've determined that 64K is a
  reasonable amount to transfer with a single SCSI command - meaning 64
  scatter/gather buffers with clustered read/write patches, 16 without.
  With the change from 16K to 64K transfers, we saw an improvement from
  50% of headrate, through the filesystem, reading and writing, to 75%
  and 100% respectively using an Adaptec 1540 series board.

  9.3.  Mailbox vs. non-mailbox

  A number of intelligent host adapters, such as the Ultrastor, WD7000,
  Adaptec 1540, 1740, and Buslogic boards have used a mailbox-metaphor
  interface, where SCSI commands are executed by putting a SCSI command
  structure in a fixed memory location (mailbox), signaling the board
  (ie, raising the outgoing mail flag), and waiting for a return
  (incoming mail).  With this high level programming interface, users
  can often upgrade to a newer board revision to take advantage of new
  features, such as FAST + WIDE SCSI, without software changes.  Drivers
  tend to be simpler to implement, may implement a larger feature set,
  and may be more stable.

  Other intelligent host adapters, such as the NCR53c7/8xx family, and
  Adaptec AIC-7770/7870 chips (including the 274x, 284x, and 2940
  boards) use a lower level programming interface.  This may prove
  faster since processing can be shifted between the board's processor
  and faster host CPU, allow better flexibility in implementing certain
  features (ie, target mode for arbitrary devices), and these boards can
  be built for less money (In some cases, this is passed on to the
  consumer (ie, most NCR boards)).  On the down side, drivers tend to be
  more complex, and must be modified to take advantage of the features
  present on newer chips.

  9.4.  Bus types

  Bus type is the next thing to consider, with choices including ISA,
  EISA, VESA, and PCI.  Marketing types often spout of absurd bandwidth
  numbers based on burst transfer rates and fiction, which isn't very
  useful.  Instead, I've chosen to state ``real-world'' numbers based on
  measured performance with various peripherials.

  9.4.1.  ISA

  Bandwidth is slightly better than 5M/sec for busmastering devices.
  With an ISA bus, arbitration for busmasters is performed by the
  venerable 8237 third party DMA controller, resulting in relatively
  high bus aquisition times.  Interrupt drivers are tri-state and edge
  triggered, meaning interrupts cannot be shared. Generally, ISA is
  unbuffered, meaning the host/memory bus is tied up whenever a transfer
  is occuring. No mechanism is provided to prevent bus-hogging.

  9.4.2.  VESA

  Bandwidth is about 30M/sec.  Some VESA systems run the bus out of
  spec, rendering them incompatable with some boards, so this should be
  taken into consideration before purchasing hardware without a return
  guarantee.  Generally, VESA is unbuffered, meaning meaning the
  host/memory bus is tied up whenever a transfer is occuring.

  9.4.3.  EISA

  Bandwidth is about 30M/sec, with busmastering operations generally
  being faster than VESA.  Some EISA systems buffer the bus, allowing
  burst transfers to the faster host/memory bus and minimizing impact on
  CPU performance.  EISA interrupt drivers may be either tri-state edge-
  triggered or open collector level-active, allowing interrupt sharing
  with drivers that support it.  Since EISA allocates a separate address
  space for
...

read more »