It is currently Tue, 17 May 2022 01:51:59 GMT

Author Message
 Linux SCSI HOWTO (part 2/3)
Archive-name: linux/howto/scsi/part2
Last-modified: 30 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/3 ---

    Currently, this is a 1.2.10 and newer patch, although the next
    release will be 1.3.x exclusively.  These patches are NOT
    entirely clean due to some ELF and other patches which were
    in the baseline revision of my source tree, and if you
    can't manually correct the (four) problems you should get,
    you shouldn't use them.  Note that only the newest patch is
    needed; these are not incremental.

    If you wish to run the newer NCR driver with a 1.3.x kernel
    before then, Harald Evensen <> has
    adapted the patches for 1.3.x

    These patches should be clean.

    Please see all of the READMEs in these directories.  You should
    also join the NCR mailing list if you are interested in running
    the ALPHA code, since interim bug fixes and announcements of the
    next release are posted to this list.

    To subscribe, send mail to with

        subscribe ncr53c810

    in the text.  You can unsubscribe by sending mail to the same address
    and including

        unsubscribe ncr53c810

    in the text.

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.

8.  The command line overrides ncr53c810=xxx, etc. don't work.  

        In stock kernels, this is because their entry points are not included
        in init/main.c, which is quite intentional :

            The driver makes no attempt to avoid autoprobing for a board
            where a command line override was used, so if an override
            is used where the board actually showed up to the PCI
            configuration routines, you'll have big problems.

            The only reason you would need an  override would be if the
            PCI hardware + BIOS were broken, in which case certain error
            recovery routines wouldn't work, rendering the override
            less than useful.

            Finally, nearly all of people who _think_ they need a command line
            override do because they get configuration or other error messages
            from the driver.  If the driver says you have a configuration
            problem, you have a broken system or a configuration problem
            and no override is going to fix this.

        If some one has gone and added the appropriate entry points to
        init/main.c for command line overrides, they are totally unsupported
        and may not work.

9.  Certain NCR boards (most notably Nexstor) which don't use an
        NCR BIOS get timeouts.  Some of these ROMs handle synchronous
        and transfers, negotiate for sync. transfers on power up,
        and leave the drives in an unknown state.  When the distribution
        Linux NCR driver attempts to talk with them, it gets timeouts
        and cannot recover because it won't do a bus reset or renegotiate.

        If you run into this problem, you can either disable
        synchronous transfers in the board's setup program, or
        upgrade to a newer ALPHA release of the NCR driver which
        will do synchronous negotiation.

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

read more »

 Mon, 20 Apr 1998 03:00:00 GMT   
 Linux SCSI HOWTO (part 2/3)
Archive-name: linux/howto/scsi/part3
Last-modified: 30 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 3/3 ---

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 3/3 ---

Version: 2.6.2
Comment: finger for public key


 Mon, 20 Apr 1998 03:00:00 GMT   
   [ 2 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 1/3)

5. Linux SCSI HOWTO (part 1/2)

6. Linux SCSI HOWTO (part 2/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