From: Drew Eckhardt (drew@ophelia.cs.colorado.edu)
Date: 07/06/92


From: drew@ophelia.cs.colorado.edu (Drew Eckhardt)
Subject: SCSI FAQ
Date: 7 Jul 1992 03:58:02 GMT

Q : What SCSI hosts are supported?

A : The Adaptec 154x, Adaptec 174x in "standard" mode,
        Future Domain 16x0, Seagate ST0x, Ultrastor 14F,
        and Western Digital 7000FASST are supported in
        the scsi distribution.

        The "stock" Linux distribution has some older versions of
        the Adaptec, Seagate, and Ultrastor driver - these are slow,
        and kill interactive performance because they don't use
        interrupts, and no processes are scheduled while they
        are in the strategy routine.

        Linux is scheduled to get the latest SCSI drivers in
        version .97.

        If you have a SCSI board, *GET* the SCSI distribution.

        Some patches for Future Domain TMC 950 boards were posted to
        the net These will be incorporated into the
        "Standard" SCSI release RSN.

Q : Which disks ?

A : Anything that works with your host adapter electronically,
        is new enough to support a December 1985 draft of SCSI-I,
        and is formatted with a 512 byte block size.

        Sysquest removable drives are known to work. However, DO NOT
        remove a mounted cartridge. This will trash your filesystem.

        CDROM should also work, but we don't support the High Sierra
        filesystem.

        Large disks work OK, however, the current Linux filesystem
        (Minix fs + symbolic links) does not support partitions > 64M,
        and I haven't had time to fix extended partitions - which means
        you can only get 64 * 4M to work with Linux.

Q : What about SCSI tapes ?

A : Tapes will be supported after the new interface is inplace
        on the SCSI driver stack. The new interface will allow
        transfer between USER and KERNEL memory, which is
        what is needed for character devices (like tapes),
        without using the generic SCSI ioctl call.

Q : How do I get SCSI information?

A : Subscribe to the SCSI channel of the linux-activists mailing list.

        mail linux-activists@joker.cs.hut.fi

        And put

        X-MN-Admin: join SCSI

        in the header.

        Mailing linux-activists-request@joker.cs.hut.fi
        will get you a list of commands.

Q : Why does the system "hang" when SCSI disk access occurs.
A : The "stock" Linux distribution still uses an earlier
        version of the SCSI drivers, where the drivers are
        not interrupt driven (easier debugging, or so we
        thought). Since the drivers do not return
        from the device driver strategy routine, until
        the SCSI command completes, no other tasks
        are scheduled, and ineteractive performance
        is abysmall.

        The SCSI distribution, from headrest.woz.colorado.edu
        does not suffer from these problems - if you
        use SCSI, GET IT.

Q : How do I partition the disk?

A : Use pfdisk or the DOS partitioning program of your choice.

        The problem with partitioning SCSI disks and Linux is that Linux
        talks directly to the SCSI interface. Each disk is viewed
        as the SCSI host sees it : N blocks, numbered from 0 to N-1,
        all error free. There is no portable way to get disk
        geometry.

        However, DOS doesn't like things like this, it demmands that
        BIOS present it with a normal Cylinder / Head / Sector
        coordinates. So, BIOS does, and it comes up with some fabrication
        that fits what DOS wants to see. You don't want to disagree with
        what BIOS thinks when you write the partition table.

        Moral : if you partition under Linux, and use a disk with
        DOS too, you MUST know the geometry according to the BIOS.

        If you partition under Linux, as long as you have the starting
        sector number of a partition, and the length in sectors,
        Linux will be happy.

Q : The stock {f,pf}disk programs don't work.
A : Yes. The device names /dev/hd* are hard coded into these
        programs, and they don't see /dev/sd*.

        If you want, YOU can change the /dev/hd* devices to
        be links to or other entries for the SCSI devices.

        Also, pfdisk should be callable with a device name.

        Hopefully, some one will change the partitioning programs
        to respect the SCSI devices.

 
Q : Where is the latest version maintained?

A : headrest.woz.colorado.edu:/pub/linux

        Since SCSI made it into .96, this is mostly alpha/beta
        test for new things. Right now,
        interrupt driven Seagate / Adaptec / Ultrastor / Future
        Domain 16 bit / WD7000 support is there.

        It works for me, but your mileage may vary.
        Join the list before you grab anything.

Q : what about extended partitions?

A : not yet. Let's just say that I almost have a very
        large drive up on a SCSI->SMD bridge, and
        that it's a priority.

Q : I get a message saying READ CAPACITY FAILED.
        What does this mean?

A : One of two things. First thing is that there is a bug in
        the midlevel error handling code. When an error
        condition is returned, things aren't retried. Some
        SCSI disks get unhappy at the sight of the
        initialization routines, and will return an
        error condition for the first "real"
        command that they run. INQUIRE doesn't count,
        since that will allways return successfully,
        irregardless of pending error conditions,
        unless your drive is Kaput.

        You could also have a flakey disk, but this is
        unlikely.

        The latest version of the SCSI drivers is kludged
        to retry the READ_CAPACITY, even though the
        midlevel driver claims to have retried it, and
        you should no longer get this message.

        Upgrade.

Q : What are the major / minor numbers for SCSI drives?

A : Right now, it is theoretically possible to have
        21 SCSI devices in the system. With SCSI-
        MFM / ESDI / SMD bridges this can be even
        more drives, as each id may have several drives on it
        each set up as a LUN of that id. Needless to say,
        if we have allowed for 16 partitions per SCSI drive,
        we're pushing the limits on minor numbers. Therefore,
        a yucky dynamic numbering scheme is used.

        Block device major 8 is used for SCSI drives. I
        personally like /dev/sd[n][p], where n is the drive
        number, and p partition letter - but this is
        entirely personal preference.
        
        Minors are assigned in increments of 16 to SCSI disks
        as they are found, scaning from host 0, ID 0 to host
        n, ID 7, excluding the host ID. Most hosts
        use ID 7 for themselves.

        A minor where minor mod 16 = 0 is the whole drive,
        where minor mod 16 is between 1 and 4, that partition,
        and extended partitions are not yet implemented.

        Example : I have four SCSI disks, set up as follows
        Seagate ST02, ID=0
        Seagate ST02, ID = 5
        Ultrastor 14, ID = 0
        Adaptec 1542, ID = 0

        The first disk on the seagate at ID 0 will become
        minors 0-15 inclusive, the second at ID5 16-31
        inclusive, the disk on the Ultrastor 32-47, on the
        Adaptec 48-63.

Q : I can't use more than X SCSI disks.

A: Change MAX_SD in sd.h, MAX_SCSI_DEVICE in scsi.h, and recompile the kernel. The current
        maximum is set up for 2 (stock kernel), or 4 (SCSI kernel from headrest.woz).

Q : How do I reduce kernel bloat and eliminate the drivers I
        don't want?

A : Simply #undef CONFIG_DISTRIBUTION in
        include/linux/config.h, and define the
        macros for the SCSI hosts you want
        enabled.

        Also, if you don't want ANY SCSI support, you can remove all
        references to scsi.a in the Makefile.

Q : What about bugs?

A : It works on MY hardware. It works on Tommy Thorn's
        Adaptec system, Dave Gentzel's Ultrastor, Thomas
        Wuensche's WD7000, Rick Faith's Future Domain,
        and quite a few other systems.

        Bugs that are there will mostly be very hardware
        specific, and nasty to track down. SCSI should
        be basically error free - consequently, the
        error code has not been heavily tested, and
        there are known bugs in it. The new drivers are
        much cleaner, and will fix this.

        If you have found a bug, please mail it
        to the mailing list with specifics of
        your hardware. Other people may have
        the same problem, a solution, etc.

        Chances are I will provide you with a debugging
        version of the kernel, which will dump out important
        SCSI information and let me see what exactly is
        going on.

Q : The seagate driver doesn't work.
A1 : Is the board jumpered for IRQ5 ?

        The factory settings are
        for MSLOSS, and have interrupts disabled. Interrupts are controlled
        by the W3 (ST01) or JP3 (ST02) jumper, which should have pins FG
        shorted. See your manual.

A2 : Cached machines will not have problems IF the Seagate's address
        space (typically C8000 - CAFFFF) is not marked "non cacheable."
        This applies to the i486 internal cache as well as i386/i486
        external caches.

        This can be set in the XCMOS of most machines. If you can't disable
        cache for the Seagate's area (16K in size, starting at the base
        address), then you must disable the cache entirely, otherwise
        it won't work.

Q : What are the known bugs?
A :
        The error routines are imperfect, meaning they trap errors but
        don't retry correctly. This can cause READ CAPACITY
        to fail in sd_init.

        Many of the drivers cannot abort a command that is in progress - if
        something goes haywire, all drives off that controller will hang.

        One user has problems with the seagate driver going "Kablooey", or
        reseting the system. Kablooey is defined as the screen
        disentigrating into multi-colored random garbage.

        Another user could never get the seagate driver to work period.

        
Q : Why can't I swap to a SCSI disk?
Q : Why can't I mount a SCSI disk as root?

A : This was due do a race condition that has since been fixed (I think).

        It only manifested itself in drivers using the command()
        interface (see bellow), but this interface isn't used very much
        as it was there mostly for develeopment.

Q : Why does Linux "hang" when the disk is accessed?

A : There are two possible interfaces between mid and lowlevel SCSI routines.
        These are the queue_command() and command() interfaces.

        The difference between the two is that queue_command()
        provides a way to do generic, interrupt driven SCSI,
        whereas command() is not interrupt driven.

        The latest SCSI drivers all support the queue_command() interface,
        the drivers in Linux through .96b are non-interrupt driven.
        If you want better performance, grab the latest sources
        from headrest.woz.

Q : I get SCSI timeouts.
A : Make sure your board has interrupts enabled correctly.

Q : What future developments are planned?

A : The following changes will occur (listed from highest to lowest priority) :

        - The new interface, providing for scatter / gather, one outstanding
                command per LUN, low-level driver specific IOCTL calls,
                such as DISK GEOMETRY, data transfer to/from
                user space at anylevel in the protocol stack, etc,
                will be added.

        - Support for extended partitions will be added

        - Support for LUN != 0 will be added

        - Support for block size, where 1024 % blocksize == 0
                will be added.

        - Support for tapes will be added
        

Q : WHEN?
A : I'm working on it, but other things like "real" work have been getting in
        the way. Now, if someone else wants to debug the hp9000/300 BSD X11R5
        server I have to install, measure our network performance, and....