It is currently Tue, 17 May 2022 02:12:55 GMT



 
Author Message
 Linux SCSI HOWTO (part 1/3)
Archive-name: linux/howto/scsi/part1
Last-modified: 8 Nov 95

-----BEGIN PGP SIGNED MESSAGE-----

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

- --- BEGIN Linux SCSI HOWTO part 1/3 ---

Archive-name: linux/howto/scsi
Last-modified: 7 Nov 1995
Version: 2.24

Copyright 1994, 1995, Drew Eckhardt

    This documentation is free documentation; you can redistribute it and/or
    modify it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This documentation is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this documentation; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

That said, I'd appreciate it if people would ask me <d...@PoohSticks.ORG>
if there's a newer version available before they publish it.  When people
publish outdated versions, I get questions from users that are answered
in newer versions, and it reflects poorly on the publisher.  I'd also prefer
that all references to free distribution sites, and possibly competing
distributions/products be left intact.  

IMPORTANT :

BUG REPORTS OR OTHER REQUESTS FOR HELP WHICH FAIL TO FOLLOW THE PROCEDURES
OUTLINED IN SECTION 2 WILL BE IGNORED.  

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

For additional information, you may wish to join the linux-scsi mailing list
by mailing majord...@vger.rutgers.edu with the line

        subscribe linux-scsi

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

        unsubscribe linux-scsi

in the text.

Once you're subscribed, you can send mail to the list at

        linux-s...@vger.rutgers.edu

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

Table of contents
Section 1                       Common Problems
    Section 1.1                 General Flakiness
    Section 1.2                 The kernel command line
    Section 1.3                 A SCSI device shows up at all possible IDs
    Section 1.4                 A SCSI device shows up at all possible LUNs
    Section 1.5                 You get sense errors when you know the
                                    devices are error free
    Section 1.6                 A kernel configured with networking does
                                    not work.
    Section 1.7                 Device detected, but unable to access.
    Section 1.8                 Sometimes the scsi subsystem locks up
                                    completely.
    Section 1.9                 Configuring and building the kernel
    Section 1.10                LUNS other than 0 don't work

Section 2                       Reporting Bugs
    Section 2.1                 Capturing messages
    Section 2.2                 Locating the source of a panic()

Section 3                       Modules
    Section 3.1                 General information.
    Section 3.2                 Status of modules under 1.2 kernels.
    Section 3.3                 Status of modules under 1.3 kernels.

Section 4                       Hosts
    Section 4.1                 Supported and Unsupported Hardware
    Section 4.1.1               Multiple host adapters
    Section 4.2                 Common Problems
    Section 4.3                 Adaptec 152x, 151x, Sound Blaster 16 SCSI,
                                    SCSI Pro, Gigabyte, and other AIC
                                    6260/6360 based products (Standard)
    Section 4.4                 Adaptec 154x, Adaptec 1640, AMI FastDisk VLB,
                                    Buslogic (DTC 329x may also work),
                                    (Standard)  
    Section 4.5                 Adaptec 174x (Standard)
    Section 4.6                 Adaptec 274x, 284x (Standard), 294x (ALPHA)
    Section 4.7                 Allways IN2000 (ALPHA)
    Section 4.8                 EATA: DPT Smartcache, Smartcache Plus,
                                    Smartcache III (Standard)
    Section 4.9                 Future Domain 16x0 with TMC-1800, TMC-18C30,
                                    TMC-18C50, or TMC-36C70 chip (Standard)
    Section 4.10                Generic NCR5380 / T130B (Standard)
    Section 4.11                NCR53c8xx rel5 (Standard), rel10+ (ALPHA)
    Section 4.12                Seagate ST0x/Future Domain TMC-8xx/TMC-9xx
                                    (Standard)
    Section 4.13                PAS16 (Standard)
    Section 4.14                Trantor T128/T128F/T228 (Standard)
    Section 4.15                Ultrastor 14f, 24f,  34f (Standard)
    Section 4.16                Western Digital 7000 (Standard)
    Section 4.17                AM53/79C974 (ALPHA)
    Section 4.18                qlogic (STANDARD)

Section 5                       Disks
    Section 5.1                 Supported and Unsupported Hardware
    Section 5.2                 Common Problems
    Section 5.3                 Device Files
    Section 5.4                 Partitioning
    Section 5.5                 Disk Geometry

Section 6                       CD ROMs
    Section 6.1                 Supported and Unsupported Hardware
    Section 6.2                 Common Problems
    Section 6.3                 Device Files

Section 7                       Tapes
    Section 7.1                 Supported and Unsupported Hardware
    Section 7.2                 Common Problems
    Section 7.3                 Device Files

Section 8                       Generic
    Section 8.1                 Supported and Unsupported Hardware
    Section 8.2                 Common Problems
    Section 8.3                 Device Files

Section 9                       Buyers' Guide
    Section 9.1                 Transfer types
    Section 9.2                 Scatter/gather
    Section 9.3                 Mailbox vs. non-mailbox
    Section 9.4                 Bus types
    Section 9.5                 Multiple devices
    Section 9.6                 SCSI-I, SCSI-II, FAST and WIDE options, etc.
    Section 9.7                 Driver feature comparison
    Section 9.8                 Board comparison
    Section 9.9                 Summary

Section 10
    Section 10.1                Assignment of minor numbers.

Section 1 : Common Problems

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

Section 1.1 : General Flakiness
        If you experience random errors, the most likely causes are
        cabling and termination problems.

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

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

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

        To minimize your problems, you should use cables which

        1.  Claim SCSI-II compliance
        2.  Have a characteristic impedance of 132 ohms
        3.  All come from the same source to avoid impedance mismatches
        4.  Come from a reputable vendor such as Amphenol

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

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

        See the Comp.Periphs.Scsi FAQ (available on tsx-11 in
        pub/linux/ALPHA/scsi) for more information about active
        termination.

Section 1.2 : The kernel command line

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

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

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

            :

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

            :?

            ramdisk floppy harddisk

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

        Options take the form of

            variable=valuelist

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

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

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

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

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

Section 1.3 :  A SCSI device shows up at all possible IDs

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

        Please change the jumper settings.

Section 1.4 :  A SCSI device shows up at all possible LUNs

        The device has buggy firmware.  

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

            max_scsi_luns=1

        If that works, there is a list of buggy devices
        in the kernel sources in drivers/scsi/scsi.c in the variable
        blacklist.  Add your device to this list and mail the patch
        to Linus Torvalds <Linus.Torva...@cs.Helsinki.FI>.

Section 1.5 :  You get sense errors when you know the devices are error free

        Sometimes this is caused by bad cables or impropper termination.

        See Section 1.1 : General Flakiness

Section 1.6 :  A kernel configured with networking does
...

read more »



 Sun, 21 Jun 1998 03:00:00 GMT   
 Linux SCSI HOWTO (part 1/3)
Archive-name: linux/howto/scsi/part2
Last-modified: 8 Nov 95

-----BEGIN PGP SIGNED MESSAGE-----

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

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

3.  Distribution kernels include release 4 or 5 of the driver, which does
    not support useful things like disconnect/reconnect (the most noticeable
    effect of this being attempts to retension/rewind/file space a tape
    lock you out of all SCSI devices), multiple host adapters, and
    BIOSless operation.

    The latest release of the driver is available at

        ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/ncr53c810

    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 <Harald.Even...@pvv.unit.no> has
    adapted the patches for 1.3.x

        ftp://ftp.pvv.unit.no/pub/Linux/ALPHA/ncr

    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 majord...@colorado.edu 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
        broken.

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

2.  Lockups / 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
        problem.

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;

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

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.

Notes:
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,
    or

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

read more »



 Sun, 21 Jun 1998 03:00:00 GMT   
 Linux SCSI HOWTO (part 1/3)
Archive-name: linux/howto/scsi/part3
Last-modified: 8 Nov 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux SCSI HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gr...@sunsite.unc.edu>.  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
    tried.

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 (s...@netcom.com) (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 (1505, 1510,
    1520, etc).

    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/1505 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 cache 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
                    max_scsi_luns.

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

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

- --- END Linux SCSI HOWTO part 3/3 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key

iQCVAwUBMOqva3tNTo2suu5NAQEzgwP9FRhc57Az2iCVbLLFP9exTf1IM9FwIqQB
Uotm1uS8pxj2rYL890OKgVieS1n5vjo53OAJnp5FhAv7JklgFkyr1yZo+suNKsSt
yVcGHKFAQnm5/TSpSEz1yfeMdI7mjk4zo/bVmn9Z5FoxjLLApCWCmYFFs1i0+v1a
VrBuPMxATpQ=
=aD5M
-----END PGP SIGNATURE-----



 Sun, 21 Jun 1998 03:00:00 GMT   
 
   [ 3 post ] 

Similar Threads

1. Linux SCSI HOWTO (part 1/3)

2. Linux SCSI HOWTO (part 1/3)

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