It is currently Thu, 08 Jun 2023 13:25:44 GMT

Author Message
 Linux SCSI HOWTO (part 2/2)
Archive-name: linux/howto/scsi/part2
Last-modified: 2 Oct 95


*** The Linux SCSI HOWTO is posted automatically by the Linux
*** HOWTO coordinator, Greg Hankins <>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Drew Eckhardt <d...@PoohSticks.ORG>.

- --- BEGIN Linux SCSI HOWTO part 2/2 ---

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.  DOUBLE CHECK
                - The IRQ you are using is used only by your onboard NCR chip,
                  or the slot an NCR board is installed in
                - Any main board jumpers selecting the IRQ for the onboard
                  chip or slot match your 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.  If you
        are using an NCR board which has jumpers to select between PCI
        interrupt lines, make sure you are using 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

        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 / other problems occur when using an S3 928, or Tseng
        ET4000W32 PCI video board.

        There are hardware bugs in at least some revisions of these
        chips.  Don't use them.

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

6.  If you encounter the message

        "scsi%d: IRQ0 not free, detaching"

        The NCR chip had a 0 stored in the PCI configuration register.  
        Either you have configuration problems (see Common Problem 1), or
        you have a defective mainboard BIOS.

        As a work arround, you could edit drivers/scsi/ncr53c7,8xx.c,
        and change pci_init() so that you have

                irq = my_irq;

                return normal_init (tpnt, board, chip, (int) base,
                    (int) io_port, (int) irq, DMA_NONE, 1, bus, device_fn,

7.  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.

1.  CONFIG_PCI must be set

Section 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 channels : DMA is 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

        1.  Write byte to data register, data register is asserted to bus
        2.  time_remaining = 12us
        3.  wait while time_remaining > 0 and REQ is not asserted
        4.  if time_remaining > 0, assert ACK
        5.  wait while time remaining > 0  and REQ is asserted
        6.  deassert ACK

        The problem was encountered in slow devices that do the command
        processing as they read the command, where the REQ/ACK handshake
        takes over 12us - REQ didn't go false when the driver expected it
        to, so the driver ended up sending multiple bytes of data for
        each REQ pulse.

2.  With Linux .99.12, a bug was introduced when I fixed the arbitration
        code, resulting in failed selections on some systems.  This was
        fixed in .99.13.

Common Problems :

1.  There are command timeouts when Linux attempts to read the partition
    table or do other disk access.

    The board ships with the defaults set up for MSDOS, ie interrupts
    are disabled.  To jumper the board for interrupts, on the Seagate
    use jumper W3 (ST01) or JP3 (ST02) and short pins F-G to select
    IRQ 5.

2.  The driver can't handle some devices, particularly cheap SCSI
    tapes and CDROMs.

    The Seagate ties the SCSI bus REQ/ACK handshaking into the PC bus
    IO CHANNEL READY and (optionally) 0WS signals.  Unfortunately, it
    doesn't tell you when the watchdog timer runs out, and you have
    no way of knowing for certain that REQ went low, and may end up
    seeing one REQ pulse as multiple REQ pulses.

    Dealing with this means using a tight loop to look for REQ to
    go low, with a timeout incase you don't catch the transition due
    to an interrupt, etc.  This results in a performance decrease, so it
    would be undesireable to apply this to all SCSI devices.  Instead,
    it is selected on a per-device basis with the "borken" field for
    the given SCSI device in the scsi_devices array.  If you run into
    problems, you should try adding your device to the list of
    devices for which borken is not reset to zero (currently,
    only the TENEX CDROM drives).

3.  A future domain board (specific examples include the 840,841,
    880, and 881) doesn't work.

    A few of the Future domain boards use the Seagate
    register mapping, and have the MSG and CD bits of the
    status register flipped.

    You should edit seagate.h, swapping the definitions for
    STAT_MSG and STAT_CD, and recompile the kernel with
    CONTROLLER defined to SEAGATE and an appropriate
    IRQ and OVERRIDE specified.

4.  When attempting to fdisk your drive, you get error messages
    indicating that the HDIO_REQ or HDIO_GETGEO ioctl failed,

        You must set heads sectors and cylinders.
        You can do this from the extra functions menu.

    See Section 5.4 : Disks : Partitioning

5.  After manually specifying the drive geometry, subsequent
    attempts to read the partition table result in partition
    boundary not on a cylinder boundary, physical and logical
    boundaries don't match, etc. error messages.

    See Section 5.4 : Disks : Partitioning

6.  Some systems which worked prior to .99.13 fail with newer
    versions of Linux.  Older versions of Linux assigned the
    CONTROL and DATA registers in an order different than that
    outlined in the Seagate documentation, which broke on some
    systems.  Newer versions make the assignment in the correct
    way, but this breaks other systems.

    The code in seagate.c looks like this now :

    DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
            (reselect ? CMD_ATTN : 0);

    Changing this to

            (reselect ? CMD_ATTN : 0);
    DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));

    may fix your problem.

Defines :

FAST or FAST32 will use blind transfers where possible

ARBITRATE will cause the host adapter to arbitrate for the
        bus for better SCSI-II compatability, rather than just
        waiting for BUS FREE and then doing its thing.  Should
        let us do one command per Lun when I integrate my
        reorganization changes into the distribution sources.

SLOW_HANDSHAKE will allow compatability with broken devices that don't
        handshake fast enough (ie, some CD ROM's) for the Seagate

SLOW_RATE=x, x some number will let you specify a default
        transfer rate if handshaking isn't working correctly.

Section 4.13 : PAS16 SCSI
Supported and Unsupported Configurations :
Ports : 0x388, 0x384, 0x38x, 0x288
IRQs : 10, 12, 14, 15
    IMPORTANT : IRQ MUST be different from the IRQ used for the sound
        portion of the board.
DMA is not used for the SCSI portion of the board
IO : port mapped

Autoprobe : does not require BIOS

Autoprobe Override :
Compile time : Define PAS16_OVERRIDE to be an array of port, irq
tupples.  Ie

#define PAS16_OVERRIDE {{0x388, 10}}

for a board at port 0x388, IRQ 10.

kernel command line :

Defines :
AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
for commands that return with a CHECK CONDITION status.

PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance
increase compared to polled I/O.

PARITY - enable parity checking.  Not supported

SCSI2 - enable support for SCSI-II tagged queueing.  Untested

UNSAFE - leave interrupts enabled during pseudo-DMA transfers.  You
         only really want to use this if you're having a problem with
         dropped characters during high speed communications, and even
         then, you're going to be better off twiddling with transfersize.

USLEEP - enable support for devices that don't disconnect.  Untested.

Common problems :

1.  Command timeouts, aborts, etc.

    You should install the NCR5380 patches that I posted to the net
    some time ago, which should be integrated into some future alpha
    release.  These patches fix a race condition in earlier NCR5380
    driver cores, as well as fixing support for multiple devices on
    NCR5380 based boards.

    If that fails, you should disable the PSEUDO_DMA option by
    changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef

    Note that the later should be considered a last resort, because
    there will be a severe performance degradation.

Section 4.14 : Trantor T128/T128F/T228
Supported and Unsupported Configurations :
Base addresses :  0xcc000, 00xc8000, 0xdc000, 0xd8000
IRQs : none, 3, 5, 7 (all boards)
        10, 12, 14, 15 (T128F only)
DMA is not used.
IO : memory mapped

Autoprobe : works for all supported configurations, requires
        installed BIOS.

Autoprobe Override :
Compile time : Define T128_OVERRIDE to be an array of address, irq
tupples.  Ie

#define T128_OVERRIDE {{0xcc000, 5}}

for a board at address 0xcc000, IRQ 5.

The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.

kernel command line : t128=address,irq

- -1 may be used for no irq, -2 for irq autoprobe.

Defines :
AUTOSENSE - if defined, REQUEST SENSE will be performed automatically
for commands that return with a CHECK CONDITION status.

PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance
increase compared to polled I/O.

PARITY - enable parity checking.  Not supported

SCSI2 - enable support for SCSI-II tagged queueing.  Untested

UNSAFE - leave interrupts enabled during pseudo-DMA transfers.  You
         only really want to use this if you're having a problem with
         dropped characters during high speed communications, and even
         then, you're going to be better off twiddling with transfersize.

USLEEP - enable support for devices that don't disconnect.  Untested.

Common Problems :
1.  Command timeouts, aborts, etc.

    You should install the NCR5380 patches that I posted to the net
    some time ago, which should be integrated into some future alpha
    release.  These patches fix a race condition in earlier NCR5380
    driver cores, as well as fixing support for multiple devices on
    NCR5380 based boards.

    If that fails, you should disable the PSEUDO_DMA option by
    changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef

    Note that the later should be considered a last resort, because
    there will be a severe performance degradation.

Section 4.15 : Ultrastor 14f (ISA), 24f (EISA), 34f (VLB)
Ports : 0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340
IRQs : 10, 11, 14, 15
DMA channels : 5, 6, 7
IO : port mapped, bus master

Autoprobe : does not work for boards at port 0x310, BIOS not required.  

Autoprobe override : compile time only, define PORT_OVERRIDE

Common Problems :
1.  The address 0x310 is not supported by the autoprobe code, and may
        cause conflicts if networking is enabled.

        Please use a different address.

2.  Using an Ultrastor at address 0x330 may cause the system to hang
        when the sound drivers are autoprobing.

        Please use a different address.

3.  Various other drivers do unsafe probes at various addresses, if you
        are having problems with detection or the system is{*filter*} at
        boot time, please try a different address.

        0x340 is recommended as an address that is known to work.

4.  Linux detects no SCSI devices, but detects your SCSI hard disk
        on an Ultrastor SCSI board as a normal hard disk, and the
        hard disk driver refuses to support it.  Note that when this
        occurs, you will probably also get a message

        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)

        If this is the case, you are running the Ultrastor board in
        WD1003 emulation mode.  You have

        1.  Switch the ultrastor into native mode.  This is the
            recommended action, since the SCSI driver can be
            significantly faster than the IDE driver, especially with
            the clustered read/write patches installed.  Some users have
            sustained in excess of 2M/sec through the file system using
            these patches.

            Note that this will be necessary if you wish to use any non-
            hard disk, or more than two hard disk devices on the Ultrastor.

        2.  Use the kernel command line switch


            to override the default setting to bootstrap yourself,
            keeping number of cylinders <= 2048, number of heads <= 16,
            and number of sectors <= 255 such that cylinders * heads * sectors
            is the same for both mappings.

            You'll also have to manually specify the disk geometry when
            running fdisk under Linux.  Failure to do so will result in
            incorrect partition entries being written, which will work
            correctly with Linux but fail under MSDOS which looks at
            the cylinder/head/sector entries in the table.

            Once Linux is up, you can avoid the inconvience of having
            to boot by hand by recompiling the kernel with an appropriately
            defined HD_TYPE macro in include/linux/config.h.

Section 4.16 : Western Digital 7000
Supported Configurations :
BIOS Addresses : 0xce000
Ports : 0x350
IRQs : 15
DMA Channels : 6
IO : port mapped, bus master

Autoprobe :  requires installed BIOS

Common Problems :

1.  There are several revisisions of the chip and firmware.  Supposedly,
        revision 3 boards do not work, revision 5 boards do,
        chips with no suffix do not work, chips with an 'A' suffix do.

2.  The board supports a few BIOS addresses which aren't on the list
        of supported addresses.  If you run into this situation,
        please use one of the supported addresses and submit a bug
        report as outlined in Section 2, "Bug Reports"

Section 4.17 : AM53/79C974 (ALPHA)

Supported Configurations :
Ports : all
IRQs : all
DMA Channels : 6
IO : port mapped, bus master (unintelligent)

Section 5 : Disks

This section gives information that is specific to disk drives.

Section 5.1 : Supported and Unsupported Hardware

All direct access SCSI devices with a block size of 256, 512, or
1024 bytes should work.  Other block sizes will not work (Note
that this can often be fixed by changing the block and/or
sector sizes using the MODE SELECT SCSI command)

Sector size refers to the number of data bytes allocated per sector
on a device, ie CDROMs use a 2048 byte sector size.  

Block size refers to the size of the logical blocks used to interface
with the device.  Although this is usually identical to sector size,
some devices map multiple smaller physical sectors (ie, 256 bytes
in the case of 55M Syquest drives) to larger logical blocks or
vice versa (ie, 512 byte blocks on SUN compatable CDROM drives).

Removeable media devices, including Bernoulis, flopticals, and MO drives

In theory, drives up to a terrabyte in size should work.  There is
definately no problem with tiny 9G drives.

Section 5.2 : Common Problems

Section 5.2.1 : Cylinder > 1024 message.

        When partitioning, you get a warning message about "cylinder > 1024"
        or you are unable to boot from a partition including a logical
        cylinder past logical cylinder 1024.

        This is a BIOS limitation.

        See Section 5.4 Disk Geometry and Partitioning for an explanation.

Section 5.2.2 :  You are unable to partition "/dev/hd*"

        /dev/hd* aren't SCSI devices, /dev/sd* are.  

        See Section 5.3, Device files, and Section 5.4, Disk
        Geometry and Partitioning
        for the correct device names and partitioning procedure.

Section 5.2.3 :   Unable to eject media from a removeable media drive.

        Linux attempts to lock the drive door when a piece of
        media is mounted to prevent filesystem corruption due to
        an inadvertant media change.

        Please unmount your disks before ejecting them.

Section 5.2.4 : Unable to boot using LILO from a SCSI disk

        In some cases, the SCSI driver and BIOS will disagree
        over the correct BIOS mapping to use, and will result
        in LILO{*filter*} after 'LI' at boot time and/or
        other problems.

        To workarround this, you'll have to determine your BIOS
        geometry mapping used under DOS, and make an entry for
        your disk in /etc/lilo/disktab.

        Alternatively, you may be able to use the "linear" configuration
        file option.

Section 5.2.5 : Fdisk responds with

                You must set heads sectors and cylinders.
                You can do this from the extra functions menu.

        and disk geometry is not 'remembered' when fdisk is rerun.

        See Section 5.4 : Partitioning

Section 5.2.6 : Only one drive is detected on a bridge board with
        multiple drives connected.

        Linux won't search LUNs past zero on SCSI devices which
        predate ANSI SCSI revision 1.  If you wish devices on
        alternate LUNs to be recognized, you will have to modify

Section 5.2.7 : System hangs when swapping

        We think this has been fixed, try upgrading to 1.1.38.

Section 5.2.8 : Connor CFP1060S disks get corrupted

        This is due to a microcode bug in the read-ahead and
        caching code.  

        From Soenke Behrens of Conner tech. support :

During the past few weeks, we got several calls from customers stating
that they had severe problems with Conner CFP1060x 1GB SCSI drives
using the Linux operating system. Symptoms were corrupt filesystems
(damaged inodes) reported by e2fsck on each system boot and similar

There is now a fix available for customers with a CFP1060x (microcode
revisions 9WA1.62/1.66/1.68) and Linux. To apply the upgrade, you
will need a DOS boot disk and ASPI drivers that can access the hard
drive. The upgrade downloads new queuing and lookahead code into the
non-volatile SCSI RAM of the drive.

If you are experiencing problems with a disk that has microcode
revision 9WA1.60, you will have to contact your nearest Conner service
centre to get the disk upgraded. The microcode revision can be found
on the label of the drive and on the underside of the drive on a label
on one of the ICs.

If you are confident that you can perform the upgrade yourself, please
contact Conner Technical Support and have your microcode revision
ready. Conner Technical Support Europe can be reached on +44-1294-315333,
Conner Technical Support in the USA can be reached on 1-800-4CONNER.

Soenke Behrens
European Technical Support

Section 5.3 : Device Files

SCSI disks use block device major 8, and there are no "raw" devices
ala BSD.

16 minor numbers are allocated to each SCSI disk, with minor % 16 == 0
being the whole disk, minors  1 <= (minor % 16) <= 4 the four primary
partitions, minors 5 <= (minor % 16) <= 15 any extended partitions.

Ie, a configuration may work out like this (with one host adapter)

Device                  Target, Lun             SCSI disk
84M Seagate             0       0               /dev/sda
SCSI->SMD bridge disk 0      3       0               /dev/sdb
SCSI->SMD bridge disk 1      3       1               /dev/sdc
Wangtek tape            4       0               none
213M Maxtor             6       0               /dev/sdd


The standard naming convention is

/dev/sd{letter} for the entire disk device ((minor % 16) == 0)
/dev/sd{letter}{partition} for the partitions on that device
        (1 <= (minor % 16) <= 15)


/dev/sda        block device major 8 minor 0
/dev/sda1       block device major 8 minor 1
/dev/sda2       block device major 8 minor 2
/dev/sdb        block device major 8 minor 16


Section 5.4 : Partitioning

You can partition your SCSI disks using the partitioning program
of your choice, under DOS, OS/2, Linux or any other operating
system supporting the standard partitioning scheme.

The correct way to run the Linux fdisk program is by specifying the
device on the command line. Ie, to partition the first SCSI disk,

    fdisk /dev/sda

If you don't explicitly specify the device, the partitioning program
may default to /dev/hda, which isn't a SCSI disk.

In some cases, fdisk will respond with

        You must set heads sectors and cylinders.
        You can do this from the extra functions menu.

    Command (m for help):

and/or give a message to the effect that the HDIO_REQ or
HDIO_GETGEO ioctl failed.  In these cases, you must
manually specify the disk geometry as outlined in Subsection
5.5 : Disk Geometry when running fdisk, and also in /etc/disktab
if you wish to boot kernels off that disk with LILO.

If you have manually specified the disk geometry, subsequent
attempts to run fdisk will give the same error message.  This
is normal, since PCs don't store the disk geometry information
in the partition table. In and of itself, will cause _NO PROBLEMS_,
and you will have no problems accessing partitions you created on
the drive with Linux.  Some vendors' poor installation code will
{*filter*}on this, in which case you should contact your vendor
and insist that they fix the code.

In some cases, you will get a warning message about a partition ending
past cylinder 1024.  If you create one of these partitions, you will
be unable to boot Linux kernels off of that partition using LILO.  Note,
however, that this restriction does not preclude the creation of a
root partition partially or entirely above the 1024 cylinder mark,
since it is possible to create a small /boot partition below the
1024 cylinder mark or to boot kernels off existing partitions.

Section 5.5 : Disk Geometry

Under Linux, each disk is viewed as the SCSI host adapter sees it :
N blocks, numbered from 0 to N-1, all error free, where as DOS/BIOS
predate intelligent disks and apply an arbitrary head / cylinder /
sector mapping to this linear addressing.

This can pose a problem when you partition the drives under Linux,
since there is no portable way to get DOS/BIOS's idea of the mapped
geometry.  In most cases, a HDIO_GETGEO ioctl() can be implemented
to return this mapping.  Unfortunately, when the vendor (ie Seagate)
has chosen a perverse, non-standard, and undocumented mapping, this
is not possible and geometry must be manually specified

If manual specification of the is required, you have one of several
options :

1.  If you don't care about using DOS, or booting kernels from the
    drive with LILO, create a translation such that heads * cylinders *
    sectors * 512 < size of your drive in bytes (a megabyte is defined
    as 2^20 bytes).

    1 <= heads <= 256
    1 <= cylinders <= 1024
    1 <= sectors <= 63

2.  Use the BIOS mapping.  In some cases, this will mean reconfiguring the
    disk so that it is at SCSI ID 0, and disabling the second IDE drive (if you have one).

    You can either use a program like NU, or you can use the following
    program :

begin 664

    When run it prints the sectors, heads, and cylinders of the
    drive whose BIOS address was specified on the command line (0x80
    is the first disk, 0x81 the second).

    Ie, dparam 0x80
    60  17      1007

Would mean that C: had 60 sectors, 17 heads, and 1007 cylinders.

Section 6 : CD ROMs

This section gives information that is specific to cdrom drives.

Section 6.1 : Supported and Unsupported Hardware

SCSI CDs with a block size of 512 or 2048 bytes should work.  Other
block sizes will not work.

Section 6.2 : Common Problems

Section 6.2.1 : Unable to mount cdrom.

        The correct syntax to mount an ISO-9660 CDROM is

        mount -t iso9660 /dev/sr0 /mount_point -o ro

        Note that for this to work, you must have the kernel
        configured with support for SCSI, your host adapter,
        the SCSI CDROM driver, and the iso9660 filesystem.

        Note that as of Linux 1.1.32, read-only devices such
        as CDROMs CANNOT be mounted with the default read/write

Section 6.2.2 : Unable to eject cdrom.

        Linux attempts to lock the drive door when a piece of
        media is mounted to prevent filesystem corruption due to
        an inadvertant media change.

Section 6.2.3 : Unable to play audio.

        The programs Workman or xcdplayer will do this for you.

Section 6.2.4 :  Workman or Xcdplayer do not work.

        The functions to control audio functions are part of the
SCSI-II command set, so any drive that is not SCSI-II will probably
not work here.  Also, many SCSI-I and some SCSI-II CDROM drives use a
proprietary command set for accessing audio functions instead of the
SCSI-II command set.  For NEC drives, there is a version of xcdplayer
specially adapted to use this command set floating around - try
looking on in pub/linux/BETA/cdrom.

        These programs may work with some of the non-SCSI cdrom drives
if the driver implements the same ioctls as the scsi drivers.

Section 6.2.5: Additional drives on CD ROM changers do not work

        Most CD changers assign each disc to a logical unit.  Insure that
you have special files made for each platter (see Section 6.3 : Device Files)
and see Section 1.10 : LUNS other than 0 don't work

Section 6.3 : Device Files

SCSI CD ROMs use major 11.

Minors are allocated dynamically (See Section 5 : Disks, Subsection 5.3 :
Device Files for an example) with the first CDROM found being minor 0,
the second minor 1, etc.

The standard naming convention is

/dev/sr{digit}, although some distributions have used /dev/scd{digit}, with
examples being

/dev/sr0        /dev/scd0
/dev/sr1        /dev/scd1

Section 7 : Tapes

This setion gives information that is specific to scsi tape drives.

Section 7.1 : Supported and Unsupported Hardware

Drives using both fixed and variable length blocks smaller than the
the driver buffer length (set to 32K in the distribution sources) are

Parameters (block size, buffering, density) are set with ioctls
(usually with the mt program), and remain in effect after the
device is closed and reopened.

Virtually all drives should work, including :
        Archive Viper QIC drives, including the 150M and 525M models
        Exabyte 8mm drives
        Wangtek 5150S drives
        Wangdat DAT drives

Section 7.2 : Common Problems

Section 7.2.1 : Tape drive not recognized at boot time.

        Try booting with a tape in the drive.

Section 7.2.2 :  Tapes with multiple files cannot be read properly.

        When reading a tape with multiple files, the first tar
        is successful, a second tar fails silently, and retrying
        the second tar is successful.

        User level programs, such as tar, don't understand file marks.
        The first tar reads up until the end of the file.  The second
        tar attempts to read at the file mark, gets nothing, but the
        tape spaces over the file mark.  The third tar is successful
        since the tape is at the start of the next file.

        Use mt on the no-rewind device to space forward to the next file.

Section 7.2.3 :  Decompression fails.

        Decompressing programs cannot handle the zeros padding the
        last block of the file.

        To prevent warnings and errors, wrap your compressed files
        in a .tar file - ie, rather than doing

        tar cfvz /dev/nrst0 file.1 file.2 ...


        tar cfvz tmp.tar.z file.1 file.2 ...

        tar cf /dev/nrst0 tmp.tar.z

Section 7.2.4 :  Problems taking tapes to/from other systems.

        You can't read a tape made with another operating system or
        another operating system can't read a tape written in Linux.

        Different systems often use different block sizes.  On a
        tape device using a fixed blocksize, you will get errors
        when reading blocks written using a different block size.

        To read these tapes, you must set the blocksize of
        the tape driver to match the blocksize used when
        the tape was written, or to variable.

        NOTE : this is the hardware block size, not the blocking
        factor used with tar, dump, etc.

        You can do this with the mt command -

                mt setblk <size>


                mt setblk 0

        to get variable block length support.

        Note that these mt flags are NOT supported under the GNU version
        of mt which is included with some Linux distributions.  Instead,
        you must use the BSD derrived Linux SCSI mt command.  Source
        should be available from

Section 7.2.5 :  "No such device" error message.

        All attempts to access the tape result in a

        "No such device"

        or similar error message.  Check the type of
        your tape device - it MUST be a character device with
        major and minor numbers matching those specified in subsection
        C, Device Files.

Section 7.2.6 : Tape reads at a given density work, writes fail

        Many tape drives support reading at lower densities
        for compatability with older harware, but will not
        write at those same densities.  

        This is especially the case with QIC drives, which
        will read old 60M tapes but only write new 120, 150,
        250, and 525M formats.

Section 7.3 : Device Files

SCSI tapes use character device major 9.  

Due to constraints imposed by Linux's use of a six{*filter*} bit dev_t with
only eight bits allocated to the minor number, the SCSI tape minor
numbers are assigned dynamically starting with the lowest SCSI HOST/ID/LUN.

Rewinding devices are numbered from 0 - with the first
SCSI tape, /dev/rst0 being c 9 0, the second /dev/rst1 c 9 1, etc.  
Non-rewinding devices have the high bit set in the minor number,
ie /dev/nrst0 is c 9 128.

The standard naming convention is
/dev/nrst{digit}        for non-rewinding devices
/dev/rst{digit}         for rewinding devices

Section 8 : Generic

This information gives information that is specific to the generic
scsi driver.

Section 8.1 : Supported Hardware

The Generic SCSI device driver provides an interface for sending
SCSI commands to all SCSI devices - disks, tapes, CDROMs, media
changer robots, etc.

Everything electrically compatable with your SCSI board should work.

Section 8.2 : Common Problems

None :-).

Section 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


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

Section 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.

Section 9.1 : Transfer types

        The biggest factor affecting performance (in terms of throughput
and interactive response time during SCSI I/O) is the transfer type used.
The table below lists the various transfer types, the effects they have
on performance, and some recomendations as to their use.

Transfer type   Description / Performance / Recomendedations
Pure            A pure polled I/O board will use the CPU to handle
Polled          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 I/O.
                Slow CDROMs which don't disconnect/reconnect will kill
                interactive performance with these boards.

                Not recommended.

Interlocked     Boards using interlocked polled I/O are essentially
Polled          the same as pure polled I/O boards, only the SCSI REQ/ACK
                handshaking signals are interlocked with 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 are 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 CD ROMs 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.

FIFO            Boards using FIFO polled I/O put a small (typically 8K)
Polled          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

                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

                Recommended for persons on a budget.

Slave           Drivers for boards using slave DMA program the PC's
DMA             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 limitDROM drives).

                Acceptable for slow CDROM drives, tapes, etc.

Busmastering    These boards are intelligent.  Drivers
DMA             for these boards throw a SCSI command, the destination
                target and lun, and where the data should end up
                in 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).

Section 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 headreate, through the filesystem, reading and writing,
to 75% and 100% respectively using an Adaptec 1540 series board.

Section 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.

Section 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.

Bus     Bandwidth, description,
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.

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

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 each board, it is usually less prone to
        resource conflicts than ISA or VESA.

PCI     Bandwidth is about 60M/sec.  Most PCI systems implement write
        posting buffers on the host bridge, allowing speed mismatches
        on either side to have a minimum impact on bus/CPU performance.  
        PCI interrupt drivers are open collector level-active, allowing
        interrupt sharing with drivers that support it. Mechanisms
        are provided to prevent bus hogging, and for both master and
        slave to suspend a bus-mastering operation.

        Since PCI provides a plug-n-play mechanism with writeable
        configuration registers on every board, in a separate address space,
        a propperly implemented PCI system is plug-and play.  

        PCI is extremely strict as to trace length, loading, mechanical
        specifications, etc. and ultimately should be more reliable than
        VESA or ISA.

        In summary, PCI is the best PC bus, although it does
        have its dark side.  PCI is still in its infancy, and although
        most manufacturers have ironed out the problems, there is
        still stock of older, buggy PCI hardware and broken main
        BIOSes.  For this reason, I _strongly_ recommend a return
        guarantee on the hardware.  While the latest PCI mainboards
        are truly plug-and-play, older PCI boards may require the
        user to set options with both jumpers and in software (ie,
        interrupt assignments).  Although many users have
        resolved their PCI problems, it has taken time and for this
        reason I cannot recommend a PCI purchase if having the
        system operational is extremely time critical.

    For many slower SCSI devices, such as disks with head rates
arround 2M/sec or less, CDROMs, and tapes, there will be little difference
in throughputs with the different PC bus interfaces.  For faster contemporary
SCSI drives (Typical high end multi-gigabyte drives have a head rate of
4-5M/sec, and at least one company is currently ALPHA testing a parallel
head unit with a 14M/sec head rate), throughput will often be significantly
better with controllers on faster busses, with one user noting a 2.5 fold
performance improvement when going from an Adaptec 1542 ISA board to a
NCR53c810 PCI board.

    With the exception of situations where PCI write-posting or a
similar write-buffering mechanism is being used, when one of the busses in
your system is busy, all of the busses will be unaccessable.  So, although
bus saturation may not be interfering with SCSI performance, it may have a
negative effect on interactive performance.  Ie, if you have a 4M/sec SCSI
disk under ISA, you'll have lost 80% of your bandwidth, and in an
ISA/VESA system would only be able to bitblt at 6M/sec.  In most cases,
a similar impact on processing jobs in the background would also be felt.

    Note that having over 16M of memory does not preclude using
an ISA busmastering SCSI board.  Unlike various broken operating
systems, Linux will double buffer when using a DMA with an ISA controller
and a transfer is ultimately destined for an area above 16M.  Performance
on these transfers only suffers by about 1.5%, ie not noticably.

    Finally, the price difference between bus masters offered with the
different bus interfaces is often minimal.  

    With all that in mind, based on your priorities you will have
certain bus preferences

        Stability, time critical installations,         EISA ISA VESA PCI
            and poor return policies
        Performance, and typical hobbiest               PCI EISA VESA ISA

     As I pointed out earlier, bus mastering versus other transfer modes is
going to have a bigger impact on total system performance, and should be
considered more important than bus type when purchasing a SCSI controller.

Section 9.5 : Multiple devices

    If will you have multiple devices on your SCSI bus, you may
want to see whether the host adapter/driver that you are considering supports
more than one outstanding command at one time.  This is very
important if you are mixing devices of different speeds, like a
tape drive and a disk drive.  If the linux driver only supports one
outstanding command, you may be locked out of your disk drive while
a tape in the tape drive is rewinding, for example.  With two
disk drives, the problem will not be as noticeable, allthough
throughput would approach the average of the two transfer rates
rather than the sum of the two transfer rates.

Section 9.6: SCSI-I, SCSI-II, SCSI-III FAST and WIDE options, etc.

    Over the years, SCSI has evolved, with new revisions of the standard
introducing higher transfer rates, methods to increase throughput, standardized
commands for new devices, and new commands for previously supported devices.

    In and of themselves, the revision levels don't really mean anything.  
Excepting minor things like SCSI-II not allowing the single initiator option
of SCSI-I, SCSI is backwards compatable, with new features being introduced
as options and not mandatory.  So, the descision to call a SCSI adapter
SCSI, SCSI-II, or SCSI-III is almost entirely a marketing one.  

Section 9.7 : Driver feature comparison

Driver feature comparison (supported chips are listed in parenthesis)

Driver                                  Simultaneous    SG              > 1
                Transfer mode           Commands        limit           Boards
AM53C974        Busmastering DMA        12s/1s          255s            Y
aha152x         FIFO(8k) Polled         1s/1s           255s            N
aha1542         Busmastering DMA        8s/1s           16              Y
aha1740         Busmastering DMA        32s             16              N
aha274x         Busmastering DMA        4s/1s           255s            Y      
buslogic        Busmastering DMA        Y               64s, 8196h      Y
eata_dma        Busmastering DMA        64s/16s         64s             Y
fdomain         FIFO(8k) Polled         1s              64s             N
    (TMC1800,   except TMC18c30
    TMC18c30,   with 2k FIFO

in2000*         FIFO(2k) Polled         1s              255s            N
g_NCR5380       Pure Polled             16s/2s          255s            Y
gsi8*           Slave DMA               16s/2s          255s
PAS16           Pure Polled             16s/2s          255s            Y
    (NCR5380)   or Interlocked Polled
                (fails on some systems!)
seagate         Interlocked Polled      1s/1s           255s            N
wd7000          Busmastering DMA        16s/1s          16              Y
t128            Interlocked Polled      16s             255s            Y
qlogic          Interlocked Polled      1s/1s           255s            N
ultrastor       Busmastering DMA        16s/2s          32              Y
53c7,8xx        Busmastering DMA        
    rel5                                1s/1s           127s            N
    rel10                               8s/1s           127s            Y

Notes :
1.  drivers flagged with an '*' are not included with the
    distribution kernel, and binary boot images may be unavailable.

2.  numbers suffixed with an 's' are arbitrary limits set in software
    which may be changed with a compile time define.  

3.  hardware limits are indicated by an 'h' suffix, and may differ
    from the software limits currently imposed by the Linux drivers.

4.  unsuffixed numbers may indicate either hard or soft limits.

5.  rel5 of the NCR53c810 driver is included in the stock 1.2.x and
    1.3.x kernels; rel10 is available via anonymous FTP.

6.  With the exception of the AM53C974, the busmastering DMA boards
    are intelligent; with the NCR executing microcode from main memory,
    the AIC7770 executing microcode from on-chip RAM, and the rest using
    a mailbox-style interface.

Section 9.8 : Board comparison

Board                   Driver          Bus     Price   Notes
Adaptec AIC-6260        aha152x         ISA             chip, not board
Adaptec AIC-6360        aha152x         VLB             chip, not board
    (Used in most
    VESA/ISA multi-IO
    boards with SCSI,
    Zenon mainboards)
Adaptec 1520            aha152x         ISA              
Adaptec 1522            aha152x         ISA     $80     1520 w/FDC
Adaptec 1510            aha152x         ISA             1520 w/out boot ROM,
                                                        won't autoprobe.
Adaptec 1540C           aha1542         ISA            
Adaptec 1542C           aha1542         ISA             1540C w/FDC
Adaptec 1540CF          aha1542         ISA             FAST SCSI-II
Adaptec 1542CF          aha1542         ISA     $200    1540CF w/FDC

Adaptec 1740            aha1740         EISA            discontinued
Adaptec 1742            aha1740         EISA            discontinued, 1740
Adaptec 2740            aha274x         EISA
Adaptec 2742            aha274x         EISA            w/FDC
Adaptec 2840            aha274x         VLB
Adaptec 2842            aha274x         VLB             w/FDC
Adaptec 2940            aha274x         PCI            
Allways IN2000          in2000          ISA
Buslogic 445S           aha1542,        VLB     $250    FAST SCSI-II, active
                        buslogic                        termination, w/FDC
Buslogic 747S           aha1542,        EISA            FAST SCSI-II, active
                        buslogic                        termination, w/FDC
Buslogic 946S           buslogic        PCI             FAST SCSI-II, active
Buslogic 956C           buslogic        PCI             WIDE version of 946
DPT     PM2011          eata_dma        ISA             FAST SCSI-II
        PM2012A         eata_dma        EISA            FAST SCSI-II
        PM2012B         eata_dma        EISA            FAST SCSI-II
        PM2021          eata_dma        ISA     $245    FAST SCSI-II
        PM2022          eata_dma        EISA    $449    FAST SCSI-II
                                                        active termination
        PM2024          eata_dma        PCI     $395    FAST SCSI-II  
                                                        active termination
        PM2122          eata_dma        EISA    $595    FAST SCSI-II
                                                        active termination
        PM2124          eata_dma        PCI     $595    FAST SCSI-II
                                                        active termination
        PM2322          eata_dma        EISA            FAST SCSI-II
                                                        active termination
        PM3021          eata_dma        ISA     $1595   FAST SCSI-II
                                                        raid/simm sockets
                                                        active termination
        PM3122          eata_dma        EISA    $1795   FAST SCSI-II
                                                        active termination
        PM3222          eata_dma        EISA    $1795   FAST SCSI-II
                                                        raid/simm sockets
                                                        active termination
        PM3224          eata_dma        PCI     $1995   FAST SCSI-II
                                                        raid/simm sockets
                                                        active termination
DTC 3290                aha1542         EISA            Although it should work,
                                                        due to documentation
                                                        release polcies, DTC
                                                        hardware is unsupported
DTC 3292                aha1542         EISA            3290 w/FDC
DTC 3292                aha1542         EISA            3290 w/FDC
Future Domain 1680      fdomain         ISA             FDC
Future Domain 3260      fdomain         PCI
NCR53c810 (boards sold 53c7,8xx         PCI     $60     chip, not board. Boards
    by FIC, Chaintech,                          (board) don't include
    Nextor, Gigabyte, etc.                              BIOS, although most
    Mainboards with chip by                             non-NCR equipped main
    AMI, ASUS, J-Bond,                                  boards have the SDMS
    etc. Common in DEC                                  BIOS
    PCI systems)
NCR53c815 (            53c7,8xx         PCI     $100    NCR53c810 plus
    Intel PCISCSIKIT,                                   bios
    NCR8150S, etc)
NCR53c825              53c7,8xx         PCI     $120    Wide variant of
                                                        NCR53c815.  Note that
                                                        the current Linux
                                                        driver does not
                                                        negotiate for wide
Pro Audio Spectrum 16   pas16           ISA             Sound board w/SCSI
Seagate ST01            seagate         ISA     $20     BIOS only works with
                                                        some drives
Seagate ST02            seagate         ISA     $40     ST01 w/FDC
Sound Blaster 16 SCSI   aha152x         ISA             Sound board w/SCSI
Western Digital 7000    wd7000          ISA             w/FDC
Trantor T128            t128            ISA            
Trantor T128F           t128            ISA             T128 w/FDC and
                                                        support for high IRQs
Trantor T130B           g_NCR5380       ISA            
Ultrastor 14F           ultrastor       ISA             w/FDC
Ultrastor 24F           ultrastor       EISA            w/FDC
Ultrastor 34F           ultrastor       VLB

Notes :
1.  Trantor was recently purchased by Adaptec, and some products are being      
    sold under the Adaptec name.

2.  Ultrastor recently filed for Chapter 11 Bankruptcy, so technical
    support is non-existant at this time.

3.  Various Buslogic boards other than the 545S, 445S, 747S, and
    946S _should_ work,  although to my knowledge have not been

4.  The price for the busmastering NCR53c810 boards is not
    a typo, includes the standard ASPI/CAM driver package for
    DOS, OS/2 and Windows (32 bit access), and other drivers are
    available for free download.

    If you can't find one at that price, I would strongly suggest that
    you peruse Computer Shopper - I've seen '810 boards in there for
    $60, and '825 boards for $120.  If you refuse to do that, some people
    have had luck with the following companies :

       InteliSys at (703) 385-0347
       Superpower at (800) 736-0007
       SW ( (214) 907-0871 fax (214) 907-9339
       Insight Electronics (609) 985-5556

5.  Adaptec's recent SCSI chips show an unusual sensitivity
    to cabling and termination problems. For this reason,
    I cannot recommend the Adaptec 154x C and CF revisions or the
    2xxx series.

    Note that the reliability problems do not apply to the
    older 154x B revision boards, 174x A revision boards,
    or to my knowledge AIC-6360/AIC-6260 based boards.

    Also, the quality of their technical support has slipped markedly, with
    long delays becoming more common, and their employees being ignorant
    (suggesting there were non-disclosure policies affecting certain
    literature when there were none), and hostile (ie, refusing to pass
    questions on to some one else when they couldn't answer them).

    If users desire handholding, or wish to make a political statement,
    they should take this point into consideration.  Otherwise, the
    Adaptec 152x/1510 are nicer than the other ISA boards in the
    same price range, and there are some excellent deals on used and
    surplus 154x B revision boards and 1742 boards which IMHO outweigh
    the support problems.

6.  All given prices for the DPT controllers are official list prices.
    Street prices should be considerably lower.
    All boards can be upgraded with chache and raid modules, most of the
    boards are also available in Wide and/or Differential versions.

Section 9.9 : Summary

    Most ISA, EISA, and VESA users will probably be served best by
a Buslogic board, due to its performance, features such as active termination,
and Adaptec 1540 compatability.  There are a number of models available with
EISA, ISA, PCI, and VESA local bus interfaces, in single ended and differential,
and 8/16 bit SCSI bus widths.

    People with PCI systems should consider NCR53c810 based boards.  These
are bus mastering SCSI controllers, available in quantity one for about $60
(ie, cheaper than the Adaptec 1520).  In addition to being the cheapest PCI
SCSI boards, the NCR boards were also benchmarked as faster than the
Adaptec 2940 and Buslogic BT-946, and demonstrate excellent performance under
Linux (up to 4M/sec through the file system ). The disadvantages of these
boards versus the Buslogics are that they aren't Adaptec 1540 compatable,
may or may not come with active termination, and you'll need the alpha code
from tsx-11 to make full use of the hardware.

        People wanting non-PCI SCSI on a limited budget will probably be
happiest finding a surplus or used Adaptec 154x B revision or 174x A
revision, or an Adaptec 1520 clone of some sort (about $80) if they want
new hardware.  These boards offer reasonable throughput and interactive
performance at a modest price.

Section 10 : Assignment of minor numbers

Due to constraints imposed by Linux's use of a six{*filter*} bit dev_t with
only eight bits allocated to the minor number, SCSI disk, tape,
CDROM, and generic minor numbers are assigned dynamically.  
iaccording to the following procedure :

        For all SCSI host adapters, from scsi0 through scsiN
            For all SCSI IDs on this bus, from 0 through 7, except for
              this host adapter's ID
                For all logical units, from 0 through max_scsi_luns
                  - Probe the bus, target, and LUN combination by
                    issuing a TEST UNIT READY command.  If we don't
                    think a unit was here, don't probe any more LUNs
                    on this bus + SCSI ID.
                  - Send an INQUIRY command to determine what we've
                    found; including the device type, vendor, model,
                    firmware revision, etc.
                  - Pass the results of this to a special recognition
                    function for each high level driver present (i.e. disk,
                    tape, etc).  Attach this device to the next available
                    unit for any drivers that are willing to drive this.
                    The generic device will attach to all devices.
                  - If it was SCSI-I, or in a list of devices known
                    not to handle multiple LUNs, don't probe any more
                    LUNs on this bus + SCSI ID.
                  - If it is a device known to have multiple LUNs, then
                    a scan of the full LUN spectrum is forced, overriding

There are frequently problems with this approach because if you have a
system where some devices are only present some of the time, then the
minor numbers for a given device will depend upon which devices were
present at boot time.  This can present problem, because rc scripts or
the file /etc/fstab might contain instructions for mounting specific
partitions which fails when the disk appears with a different minor

        This problem has not yet been fully solved.  There is a
program which can be found on tsx-11 that creates a /dev/scsi heirarchy
based upon host number, id and lun.  This is a bit clumsy, but it would
help to alleviate some of the problems.

        A better solution will probably come out of the /proc/scsi pseudo
directory.  This is currently a work in progress, so at present we cannot
say exactly the form of the solution, but at the time of this writing
this appears to be a promising approach for resolving some of these

- --- END Linux SCSI HOWTO part 2/2 ---

Version: 2.6.2
Comment: finger for public key


 Fri, 20 Mar 1998 03:00:00 GMT   
   [ 1 post ] 

Similar Threads

1. Linux SCSI HOWTO (part 1/3)

2. Linux SCSI HOWTO (part 1/3)

3. Linux SCSI HOWTO (part 1/3)

4. Linux SCSI HOWTO (part 2/3)

5. Linux SCSI HOWTO (part 1/3)

6. Linux SCSI HOWTO (part 1/2)

7. Linux SCSI HOWTO (part 1/2)

8. Linux SCSI HOWTO (part 1/3)

9. Linux SCSI HOWTO (part 1/3)

10. Linux SCSI HOWTO (part 1/2)

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software