Archive-name: linux/howto/scsi/part1
Last-modified: 2 Oct 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/2 ---
Archive-name: linux/howto/scsi
Last-modified: 23 Jul 1995
Version: 2.17
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 WHICH FAIL TO FOLLOW THE PROCEDURE 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.
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, AMI FastDisk VLB,
Buslogic, DTC 329x (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 not work.
The auto-probe routines for many of the network drivers
are not passive, and will interfere with operation with some
of the SCSI drivers.
Section 1.7 : Device detected, but unable to access.
A SCSI device is detected by the kernel, but you are unable to
access it - ie mkfs /dev/sdc, tar xvf /dev/rst2, etc fails.
You don't have a special file in /dev for the device.
Unix devices are identified as either block or character (block
devices go through the buffer cache, character devices do not) devices,
a major number (ie which driver is used - block major 8 corresponds
to SCSI disks) and a minor number (ie which unit is being accessed
through a given driver - ie character major 4, minor 0 is the first
virtual console, minor 1 the next, etc). However, accessing devices
through this separate namespace would break the unix/Linux metaphor of
"everything is a file," so character and block device special files
are created under /dev. This lets you access the raw third SCSI disk
device as /dev/sdc, the first serial port as /dev/ttyS0, etc.
The preferred method for creating a file is using the MAKEDEV script -
cd /dev
and run MAKEDEV (as root) for the devices you want to create - ie
./MAKEDEV sdc
wildcards "should" work - ie
./MAKEDEV sd\*
"should" create entries for all SCSI disk devices (doing this should
create /dev/sda through /dev/sdp, with fif{*filter*} partition entries for
each)
./MAKEDEV sdc\*
"should" create entries for /dev/sdc and all fif{*filter*} permissible
partitions on /dev/sdc, etc.
I say "should" because this is the standard unix behavior - the MAKEDEV
script in your installation may not conform to this behavior, or may
have restricted the number of devices it will create.
If MAKEDEV won't do the right magic for you, you'll have to create the
device entries by hand with the mknod command.
The block/character type, major, and minor numbers are specified for the
various SCSI devices in Subsection 4 : Device Files in the appropriate
section.
Take those numbers, and use (as root)
mknod /dev/device b|c major minor
ie -
mknod /dev/sdc b 8 32
mknod /dev/rst0 c 9 0
Section 1.8 : SCSI System Lockups
This could be one of a number of things. Also see the section for
your specific host adapter for possible further solutions.
There are cases where the lockups seem to occur when multiple devices
are in use at the same time. In this case, you can try contacting
the manufacturer of the devices and see if firmware upgrades are
available which would correct the problem. If possible, try a
different scsi cable, or try on another system. This can also
be caused by bad blocks on disks, or by bad handling of DMA by the
motherboard (for host adapters that do DMA). There are probably
many other possible conditions that could lead to this type of event.
Sometimes these problems occur when there are multiple devices in
use on the bus at the same time. In this case, if your host
adapter driver supports more than one outstanding command on the bus
at one time, try reducing this to 1 and see if this helps. If you
have tape drives or slow cdrom drives on the bus, this might not be
a practical solution.
Section 1.9 : Configuring and building the kernel
Unused SCSI drivers eat up valuable memory, aggravating
memory shortage problems on small systems because kernel
memory is unpagable.
So, you will want to build a kernel tuned for your
system, with only the drivers you need installed.
cd to /usr/src/linux
If you are using a root device other than the current
one, or something other than 80x25 VGA, and you are
writing a boot floppy, you should edit the makefile,
and make sure the
ROOT_DEV =
and
SVGA_MODE =
lines are the way you want them.
If you've installed any patches, you may wish to guarantee that all
files are rebuilt. If this is the case, you should type
make mrproper
Irregardless of weather you ran make mrproper, type
make config
and answer the configuration questions. Then run
make depend
and finally
make
Once the build completes, you may wish to update the
lilo configuration, or write a boot floppy. A boot floppy
may be made by running
make zdisk
Section 1.10 : LUNS other than 0 don't work
Many SCSI devices are horrendously broken, lock the SCSI
bus up solid, and do other bad things when you attempt to
talk to them at a logical unit someplace other than zero.
So, by default recent versions of the Linux kernel will not
probe luns other than 0. To work arround this, you need to
the max_scsi_luns command line option, or recompile the kernel
wiuth the CONFIG_SCSI_MULTI_LUN option.
Usually, you'll put
max_scsi_luns=8
on your LILO command line.
If your multi-LUN devices still aren't detected correctly after
trying one of these fixes (as the case will be with many old
SCSI->MFM, RLL, ESDI, SMD, and similar bridge boards), you'll
be thwarted by this piece of code
/* Some scsi-1 peripherals do not handle lun != 0.
I am assuming that scsi-2 peripherals do better */
if((scsi_result[2] & 0x07) == 1 &&
(scsi_result[3] & 0x0f) == 0) break;
in scan_scsis() in drivers/scsi/scsi.c. Delete this code,
and you should be fine.
Section 2 : Reporting Bugs
The Linux SCSI developers don't necessarily maintain old revisions
of the code due to space constraints. So, if you are not running the
latest publically released Linux kernel (note that many of the Linux
distributions, such as MCC, SLS, Yggdrasil, etc. often lag one or even
twenty patches behind this) chances are we will be unable to solve your
problem. So, before reporting a bug, please check to see if it exists
with the latest publically available kernel.
If after upgrading, and reading this document thoroughly, you still
believe that you have a bug, please mail a bug report to the SCSI channel
of the mailing list where it will be seen by many of the people who've
contributed to the Linux SCSI drivers.
In your bug report, please provide as much information as possible
regarding your hardware configuration, the exact text of
all of the messages that Linux prints when it boots, when the
error condition occurs, and where in the source code the error
is. Use the procedures outlined in Section 2.1 : Capturing
messages and Section 2.2 : Locating the source of a panic().
Failure to provide the maximum possible amount of information
may result in misdiagnosis of your problem, or developers
deciding that there are other more interesting problems to
fix.
The bottom line is that if we can't reproduce your bug, and you can't
point at us what's broken, it won't get fixed.
Section 2.1 : Capturing messages
If you are not running a kernel message logging system :
Insure that the /proc filesystem is mounted.
grep proc /etc/mtab
If the /proc filesystem is not mounted, mount it
mkdir /proc
chmod 755 /proc
mount -t proc /proc /proc
Copy the kernel revision and messages into a log file
cat /proc/version > /tmp/log
cat /proc/kmsg >> /tmp/log
Type CNTRL-C after a second or two.
If you are running some logger, you'll have to poke through the
appropriate log files (/etc/syslog.conf should be of some use
in locating them), or use dmesg.
If Linux is not yet bootstrapped, format a floppy diskette under DOS.
Note that if you have a distribution which mounts the root diskette off of
floppy rather than RAM drive, you'll have to format a diskette readable
in the drive not being used to mount root or use their ramdisk boot option.
Boot Linux off your distribution boot floppy, preferably in single user mode
using a RAM disk as root.
mkdir /tmp/dos
Insert the diskette in a drive not being used to mount root, and
mount it. Ie
mount -t msdos /dev/fd0 /tmp/dos
or
mount -t msdos /dev/fd1 /tmp/dos
Copy your log to it
cp /tmp/log /tmp/dos/log
Unmount the DOS floppy
umount /tmp/dos
And shutdown Linux
shutdown
Reboot into DOS, and using your favorite communications software include
the log file in your trouble mail.
Section 2.2 : Locating the source of a panic()
Like other unices, when a fatal error is encountered, Linux calls the
kernel panic() function. Unlike other unices, Linux doesn't dump
core to the swap or dump device and reboot automatically. Instead,
a useful summary of state information is printed for the user to
manually copy down. Ie :
Unable to handle kernel NULL pointer dereference at virtual address c0000004
current->tss,cr3 = 00101000, %cr3 = 00101000
*pde = 00102027
*pte = 00000027
Oops: 0000
EIP: 0010:0019c905
EFLAGS: 00010002
eax: 0000000a ebx: 001cd0e8 ecx: 00000006 edx: 000003d5
esi: 001cd0a8 edi: 00000000 ebp: 00000000 esp: 001a18c0
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=001a09c8)
Stack: 0019c5c6 00000000 0019c5b2 00000000 0019c5a5 001cd0a8 00000002 00000000
001cd0e8 001cd0a8 00000000 001cdb38 001cdb00 00000000 001ce284 0019d001
001cd004 0000e800 fbfff000 0019d051 001cd0a8 00000000 001a29f4 00800000
Call Trace: 0019c5c6 0019c5b2 0018c5a5 0019d001 0019d051 00111508 00111502
0011e800 0011154d 00110f63 0010e2b3 0010ef55 0010ddb7
Code: 8b 57 04 52 68 d2 c5 19 00 e8 cd a0 f7 ff 83 c4 20 8b 4f 04
Aiee, killing interrupt handler
kfree of non-kmalloced memory: 001a29c0, next= 00000000, order=0
task[0] (swapper) killed: unable to recover
Kernel panic: Trying to free up swapper memory space
In swapper task - not syncing
Take the hexidecimal number on the EIP: line, in this case 19c905, and search
through /usr/src/linux/zSystem.map for the highest number not larger than
that address. Ie,
0019a000 T _fix_pointers
0019c700 t _intr_scsi
0019d000 t _NCR53c7x0_intr
That tells you what function its in. Recompile the source file which
defines that function file with debugging enabled, or the whole kernel
if you prefer by editing /usr/src/linux/Makefile and adding a "-g"
to the CFLAGS definition.
#
# standard CFLAGS
#
Ie,
CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
becomes
CFLAGS = -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
Rebuild the kernel, incrementally or by doing a
make clean
make
Make the kernel bootable by creating an entry in your /etc/lilo.conf
for it
image = /usr/src/linux/zImage
label = experimental
and re-running LILO as root, or by creating a boot floppy
make zImage
Reboot and record the new EIP for the error.
If you have script installed, you may want to start it, as
it will log your debugging session to the typescript file.
Now, run
gdb /usr/src/linux/tools/zSystem
and enter
info line *<your EIP>
Ie,
info line *0x19c905
To which GDB will respond something like
(gdb) info line *0x19c905
Line 2855 of "53c7,8xx.c" starts at address 0x19c905 <intr_scsi+641>
and ends at 0x19c913 <intr_scsi+655>.
Record this information. Then, enter
list <line number>
Ie,
(gdb) list 2855
2850 /* printk("scsi%d : target %d lun %d unexpected disconnect\n",
2851 host->host_no, cmd->cmd->target, cmd->cmd->lun); */
2852 printk("host : 0x%x\n", (unsigned) host);
2853 printk("host->host_no : %d\n", host->host_no);
2854 printk("cmd : 0x%x\n", (unsigned) cmd);
2855 printk("cmd->cmd : 0x%x\n", (unsigned) cmd->cmd);
2856 printk("cmd->cmd->target : %d\n", cmd->cmd->target);
2857 if (cmd) {
2858 abnormal_finished(cmd, DID_ERROR << 16);
2859 }
2860 hostdata->dsp = hostdata->script + hostdata->E_schedule /
2861 sizeof(long);
2862 hostdata->dsp_changed = 1;
2863 /* SCSI PARITY error */
2864 }
2865
2866 if (sstat0_sist0 & SSTAT0_PAR) {
2867 fatal = 1;
2868 if (cmd && cmd->cmd) {
2869 printk("scsi%d : target %d lun %d parity error.\n",
Obviously, quit will take you out of GDB.
Record this information too, as it will provide a context incase the
developers' kernels differ from yours.
Section 3 : Modules
This section gives specific details regarding the support for loadable
kernel modules and how it relates to SCSI.
Section 3.1 : General Information
Loadable modules are a means by which the user or system administrator
can load files into the kernel's memory in such a way that the kernel's
capabilities are expanded. The most common usages of modules are for
drivers to support hardware, or to load filessytems.
There are several advantages of modules for SCSI. One is that a
system administrator trying to maintain a large number of machines can
use a single kernel image for all of the machines, and then load
kernel modules to support hardware that is only present on some
machines.
It is also possible for someone trying to create a distribution to use
a script on the bootable floppy to query for which modules to be
loaded. This saves memory that would otherwise be wasted on unused
drivers, and it would also reduce the possibility that a probe for a
non-existant card would{*filter*}up some other card on the system.
Modules also work out nicely on laptops, which tend to have less
memory than desktop machines, and people tend to want to keep the
kernel image as small as possible and load modules as required. Also,
modules makes supporting PCMCIA SCSI cards on laptops somewhat easier,
since you can load and unload the driver as the card is
inserted/removed. [Note: currently the qlogic and 152x drivers support
PCMCIA].
Finally, there is the advantage that kernel developers can more easily
debug and test their drivers, since testing a new driver does not
require rebooting the machine (provided of course that the machine has
not completely crashed as a result of some bug in the driver).
Although modules are very nice, there is one limitation. If your root
disk partition is on a scsi device, you will not be able to use
modularized versions of scsi code required to access the disk. This
is because the system must be able to mount the root partition before
it can load any modules from disk. There are people thinking about
ways of fixing the loader and the kernel so that the kernel can
self-load modules prior to attempting to mount the root filesystem,
so at some point in the future this limitation may be lifted.
Section 3.2 : Module support in the 1.2.N kernel.
In the 1.2.N series of kernels, there is partial support for SCSI
kernel modules. While none of the high level drivers (such as disk,
tape, etc) can be used as modules, most of the low level drivers
(i.e. 1542, 1522) can be loaded and unloaded as required. Each time
you load a low-level driver, the driver first searches for cards that
can be driven. Next, the bus is scanned for each card that is found,
and then the internal data structures are set up so as to make it
possible to actually use the devices attached to the cards that the
driver is managing.
When you are through with a low-level driver, you can unload
it. You should keep in mind that usage counts are maintained based upon
mounted filesystems, open files, etc, so that if you are still using a
device that the driver is managing, the rmmod utillity will tell you that
the device is still busy and refuse to unload the driver. When the driver
is unloaded, all of the associated data structures are also freed so that
the system state should be back to where it was before the module was loaded.
This means that the driver could be reloaded at a later time if required.
Section 3.3 : Module support in the 1.3.N kernel.
In the 1.3 series of kernels, the scsi code is completely modularized.
This means that you can start with a kernel that has no scsi support
whatsoever, and start loading modules and you will eventually end up
with complete support.
If you wish, you can compile some parts of the SCSI code into the kernel
and then load other parts later - it is all up to you how much gets loaded
at runtime and how much is linked directly into the kernel.
If you are starting with a kernel that has no support whatsoever for
SCSI, then the first thing you will need to do is to load the scsi
core into the kernel - this is in a module called "scsi_mod". You
will not be able to load any other scsi modules until you have this
loaded into kernel memory. Since this does not contain any low-level
drivers, the act of loading this module will not scan any busses, nor
will it activate any drivers for scsi disks, tapes, etc. If you answered
'Y' to the CONFIG_SCSI question when you built your kernel, you will not
need to load this module.
At this point you can add modules in more or less any order to achieve
the desired functionality. Usage counts are interlocks are used to
prevent unloading of any component which might still be in use, and
you will get a message from rmmod if a module is still busy.
The high level drivers are in modules named "sd_mod", "sr_mod", "st",
and "sg", for disk, cdrom, tape, and scsi generics support
respectively. When you load a high level driver, the device list for
all attached hosts is examined for devices which the high level driver
can drive, and these are automatically activated.
The use of modules with low level drivers were described in the
Section 3.2. When a low-level driver is loaded, the bus is scanned,
and each device is examined by each of the high level drivers to see
if they recognize it as something that they can drive - anything
recognized is automatically attached and activated.
Section 4 : Hosts
This section gives specific information about the various host adapters that
are supported in some way or another under linux.
Section 4.1 : Supported and Unsupported Hardware
Drivers in the distribution kernel :
Adaptec 152x, Adaptec 154x (including clones from Bustek and DTC 329x
boards), Adaptec 174x, Adaptec 274x/284x/2940, EATA-DMA protocol compilant
boards (all DPT PMXXXXX/XX and SKXXXXX/XX except the PM2001, some boards
from NEC and ATT), Future Domain 850, 885, 950, and other boards in that
series (but not the 840, 841, 880, and 881 boards unless you make the
appropriate patch), Future Domain 16x0 with TMC-1800, TMC-18C30, or TMC-18C50
chips, NCR53c8xx,PAS16 SCSI ports, Seagate ST0x, Trantor T128/T130/T228 boards,
Ultrastor 14F, 24F, and 34F, and Western Digital 7000.
Alpha drivers :
Richoh GSI-8
Many of the ALPHA drivers are available via anonymous FTP from
tsx-11.mit.edu:/pub/linux/ALPHA/scsi
Drivers that are being developed, but aren't publically available yet,
and modifications needed to make existing drivers compatable with
other boards :
DPT PM2001
Announcements WILL be made when drivers are available for public
alpha testing. Until then, please don't use up the developers'
valuable time with mail asking for release dates, etc.
NCR53c8x0/7x0
A NCR53c8xx driver has been developed, and with modifications
ranging from minor to severe should support these chips
NCR53c720 - detection changes, initializaion changes, modification
of the assembler to use the 720's register mapping
NCR53c710 - detection changes, initialization changes, modification
of assembler, modification of the NCR code to use fatal
interrupts or GPIO generated non fatal interrupts for
command completion.
NCR53c700, NCR53c700-66 - detection changes, initialization changes,
modification of NCR code to not use DSA, modification of Linux
code to handle context switches.
NCR53c9x family
Qlogic
SCSI hosts that will not work :
All parallel->SCSI adapters, Rancho SCSI boards, and Grass Roots SCSI
boards.
SCSI hosts that will NEVER work :
Non Adaptec compatable DTC boards (including the 3270 and 3280).
CMD SCSI boards.
Aquiring programming information requires a non-disclosure agreement
with DTC/CMD. This means that it would be impossible to distribute a
Linux driver if one were written, since complying with the NDA would
mean distributing no source, in violation of the GPL, and complying
with the GPL would mean distributing source, in violation of the NDA.
If you want to run Linux on an unsupported piece of hardware, your
options are to either write a driver yourself (Eric Youngdale and I are
usually willing to answer technical questions concerning the Linux
SCSI drivers) or to commision a driver.
Section 4.1.1 : Multiple host adapters
With some host adapters (see Section 9.7 : Buyers' Guide :
Feature Comparison), you can use multiple host adapters of the
same type in the same system. With multiple adapters of the
same type in the same system, generally the one at the lowest
address will be scsi0, the one at the next address scsi1, etc.
In all cases, it is possible to use multiple host adapters of
different types, provided that none of their addresses conflict.
SCSI controllers are scanned in the order specified in the
builtin_scsi_hosts[] array in drivers/scsi/hosts.c, with
the order currently being
Ultrastor 14/34F, Ultrastor 14F,, Adaptec 151x/152x, Buslogic,
Adaptec 154x, Adaptec 174x, AIC7XXX, AM53C974, Future Domain 16x0,
Allways IN2000, Generic NCR5380, QLOGIC, PAS16, Seagate,
Trantor T128/T130, NCR53c8xx, EATA-DMA, WD7000, debugging driver.
In most cases (ie, you aren't trying to use both
Buslogic and Adaptec drivers), this can be changed to suit your
needs (ie, keeping the same devices when new SCSI devices
are added to the system on a new controller) by moving the individual
entries.
FIXME
Section 4.2 : Common Problems
Section 4.2.1 : SCSI timeouts
Make sure interrupts are enabled correctly, and there are no
IRQ, DMA, or address conflicts with other boards.
Section 4.2.2 : Failure of autoprobe routines on boards that rely on
BIOS for autoprobe.
If your SCSI adapter is one of the following :
Adaptec 152x, Adaptec 151x, Adaptec AIC-6260,
Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950,
Future Domain TMC-8xx, Trantor T128, Trantor T128F,
Trantor T228F, Seagate ST01, Seagate ST02, or a
Western Digital 7000
and it is not detected on bootup, ie you get a
scsi : 0 hosts
message or a
scsi%d : type
message is not printed for each supported SCSI adapter installed
in the system, you may have a problem with the autoprobe routine
not knowing about your board.
Autodetection will fail for drivers using the BIOS for autodetection
if the BIOS is disabled. Double check that your BIOS is enabled,
and not conflicting with any other peripherial BIOSes.
Autodetection will also fail if the board's "signature" and/or
BIOS address don't match known ones.
If the BIOS is installed, please use DOS and DEBUG to
find a signature that will detect your board -
Ie, if your board lives at 0xc8000, under DOS do
debug
d c800:0
q
and send a message to the SCSI channel of the mailing list with
the ASCII message, with the length and offset from the base
address (ie, 0xc8000). Note that the EXACT text is required,
and you should provide both the hex and ASCII portions of
the text.
If no BIOS is installed, and you are using an Adaptec 152x,
Trantor T128, or Seagate driver, you can use command line
or compile time overrides to force detection.
Please consult the appropriate subsection for your SCSI board
as well as Section 1.1 :
Section 4.2.3 : Failure of boards using memory mapped I/O
(This include the Trantor T128 and Seagate boards, but not the
Adaptec, Generic NCR5380, PAS16, and Ultrastor drivers)
This is often caused when the memory mapped I/O ports
are incorrectly cached. You should have the board's
address space marked as uncachable in the XCMOS settings.
If this is not possible, you will have to disable cache
entirely.
If you have manually specified the address of the board,
remember that Linux needs the actual address of the board,
and not the 16 byte segment the documentation may refer to.
Ie, 0xc8000 would be correct, 0xc800 would not work
and could cause memory corruption.
Section 4.2.4 : "kernel panic : cannot mount root device" when booting
an ALPHA driver boot floppy
You'll need to edit the binary image of the kernel (before
or after writing it out to disk), and modify a few two byte
fields (little endian) to gurantee that it will work on your
system.
1. default swap device at offset 502, this should be set to 0x00 0x00
2. ram disk size at offset 504, this should be set to the size
of the boot floppy in K - ie, 5.25" = 1200, 3.5" = 1440.
This means the bytes are
3.5" : 0xA0 0x05
5.25" : 0xB0 0x04
3. root device offset at 508, this should be 0x00 0x00, ie the boot
device.
dd or rawrite the file to a disk. Insert the disk in the
first floppy drive, wait until it prompts you to insert
the root disk, and insert the root floppy from your
distribution.
Section 4.2.5 : Installing a device driver not included with the distribution
kernel
You need to start with the version of the kernel used by the
driver author. This revision may be alluded to in the documentation
included with the driver.
Various recent kernel revisions can be found at
nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus
as linux-version.tar.gz
They are also mirrored at tsx-11.mit.edu and various other sites.
cd to /usr/src.
Remove your old Linux sources, if you want to keep a backup copy
of them
mv linux linux-old
Untar the archive
gunzip < linux-0.99.12.tar.gz | tar xvfp -
Apply the patches. The patches will be relative to some directory
in the filesystem. By examining the output file lines in the patch
file (grep for ^---), you can tell where this is - ie patches with
these lines
--- ./kernel/blk_drv/scsi/Makefile
--- ./config.in Wed Sep 1 16:19:33 1993
would have the files relative to /usr/src/linux.
Untar the driver sources at an appropriate place - you
can type
tar tfv patches.tar
to get a listing, and move files as necessary (The SCSI driver files
should live in /usr/src/linux/kernel/drivers/scsi)
Either cd to the directory they are relative to and type
patch -p0 < patch_file
or tell patch to strip off leading path components. Ie,
if the files started with
--- linux-new/kernel/blk_drv/scsi/Makefile
and you wanted to apply them while in /usr/src/linux, you
could cd to /usr/src/linux and type
patch -p1 < patches
to strip off the "linux-new" component.
After you have applied the patches, look for any patch rejects,
which will be the name of the rejected file with a # suffix appended.
find /usr/src/linux/ -name "*#" -print
If any of these exist, look at them. In some cases, the
differences will be in RCS identifiers and will be harmless,
in other cases, you'll have to manually apply important
parts. Documentation on diffs files and patch is beyond the
scope of this document.
See also Section 1.8 : Configuring and building the kernel
3.2.6 : Installing a driver that has no patches
In some cases, a driver author may not offer patches with
the .c and .h files which comprise his driver, or the patches
may be against an older revision of the kernel and not go
in cleanly.
1. Copy the .c and .h files into /usr/src/linux/drivers/scsi
2. Add the configuration option
Edit /usr/src/linux/config.in, and add a line in the
*
* SCSI low-level drivers
*
section, add a boolean configuration variable for your
driver. Ie,
bool 'Allways IN2000 SCSI support' CONFIG_SCSI_IN2000 y
3. Add the makefile entries
Edit /usr/src/linux/drivers/scsi/Makefile, and add
an entry like
ifdef CONFIG_SCSI_IN2000
SCSI_OBS := $(SCSI_OBJS) in2000.o
SCSI_SRCS := $(SCSI_SRCS) in2000.c
endif
before the
scsi.a: $(SCSI_OBJS)
line in the makefile, where the .c file is the .c
file you copied in, and the .o file is the basename
of the .c file with a .o suffixed.
4. Add the entry points
Edit /usr/src/linux/drivers/scsi/hosts.c, and
add a #inlclude for the header file, conditional
on the CONFIG_SCSI preprocessor define you
added to the configuration file. Ie, after
#ifdef CONFIG_SCSI_GENERIC_NCR5380
#include "g_NCR5380.h"
#endif
you might add
#ifdef CONFIG_SCSI_IN2000
#include "in2000.h"
#endif
You will also need to add the Scsi_Host_Template
entry into the scsi_hosts[] array. Take a look
into the .h file, and you should find a #define that
looks something like this :
#define IN2000 {"Always IN2000", in2000_detect, \
in2000_info, in2000_command, \
in2000_queuecommand, \
in2000_abort, \
in2000_reset, \
NULL, \
in2000_biosparam, \
1, 7, IN2000_SG, 1, 0, 0}
the name of the preprocessor define, and add
it into the scsi_hosts[] array, conditional on
definition of the preprocessor symbol you used
in the configuration file.
Ie, after
#ifdef CONFIG_SCSI_GENERIC_NCR5380
GENERIC_NCR5380,
#endif
you might add
#ifdef CONFIG_SCSI_IN2000
IN2000,
#endif
See also Section 1.8 : Configuring and building the kernel
Section 4.2.5 : Failure of a PCI board
Unfortunately, PCI is still in its infancy, and having a few
teething problems.
Section 4.3 : Adaptec 152x, 151x, Sound Blaster 16 SCSI, SCSI Pro,
Gigabyte, and other AIC 6260/6360 based products (Standard)
Supported Configurations :
BIOS addresses : 0xd8000, 0xdc000, 0xd0000, 0xd4000, 0xc8000, 0xcc000, 0xe0000,
0xe4000.
Ports : 0x140, 0x340
IRQs : 9, 10, 11, 12
DMA is not used
IO : port mapped
Autoprobe :
Works with many boards with an installed BIOS. All
other boards, including the Adaptec 1510, and Sound Blaster16 SCSI
must use a kernel command line or compile time override.
Autoprobe Override :
Compile time :
Define PORTBASE, IRQ, SCSI_ID, RECONNECT as appropriate, see Defines
kernel command line : aha152x=<PORTBASE>,<IRQ>,<SCSI-ID>,<RECONNECT>
Usually, SCSI-ID will be 7 and RECONNECT non-zero.
To force detection at 0x340, IRQ 11, at SCSI-ID 7, allowing
disconnect/reconnect, you would use the following command line
option :
aha152x=0x340,11,7,1
Antiquity Problems, fix by upgrading :
1. The driver fails with VLB boards. There was a timing problem
in kernels older than revision 1.0.5.
Defines :
AUTOCONF : use configuration the controller reports (only 152x)
IRQ : override interrupt channel (9,10,11 or 12) (default 11)
SCSI_ID : override SCSI ID of AIC-6260 (0-7) (default 7)
RECONNECT : override target disconnect/reselect (set to non-zero to
allow, zero to disable)
DONT_SNARF : Don't register ports (pl12 and below)
SKIP_BIOSTEST : Don't test for BIOS signature (AHA-1510 or disabled BIOS)
PORTBASE : Force port base. Don't try to probe
Section 4.4 : Adaptec 154x, AMI FastDisk VLB, Buslogic, DTC 329x (Standard)
Supported Configurations :
Ports : 0x330 and 0x334
IRQs : 9, 10, 11, 12, 14, 15
DMA channels : 5, 6, 7
IO : port mapped, bus master
Autoprobe : works with all supported configurations, does not
require an installed BIOS.
Autoprobe override : none
Note: No-suffix boards, and early 'A' suffix boards do not support
scatter/gather, and thus don't work. However, they can be made to
work for some definition of the word works if AHA1542_SCATTER is
changed to 0 in drivers/scsi/aha1542.h.
Note: Buslogic makes a series of boards that are software compatible with
the Adaptec 1542, and these come in ISA, VLB and EISA flavors.
Antiquity Problems, fix by upgrading :
1. Linux kernel revisions prior to .99.10 don't support the 'C'
revision.
2. Linux kernel revisions prior to .99.14k don't support the 'C'
revision options for
- BIOS support for the extended mapping for disks > 1G
- BIOS support for > 2 drives
- BIOS support for autoscanning the SCSI bus
3. Linux kernel revisions prior to .99.15e don't support the 'C'
with the BIOS support for > 2 drives turned on and the
BIOS support for the extended mapping for disks > 1G turned off.
4. Linux kernel revisions prior to .99.14u don't support the 'CF'
revisions of the board.
5. Linux kernel revisions prior to 1.0.5 have a race condition
when multiple devices are accessed at the same time.
Common problems :
1. There are unexpected errors with a 154xC or 154xCF board,
Early examples of the 154xC boards have a high slew rate on
one of the SCSI signals, which results in signal reflections
when cables with the wrong impedance are used.
Newer boards aren't much better, and also suffer from extreme
cabling and termination sensitivity.
See also Common Problems #2 and #3 and Section 1 : Common Problems,
Subsection 1.1 : General Flakiness
2. There are unexpected errors with a 154xC or 154x with
both internal and external devices connected.
This is probably a termination problem. In order to
use the software option to disable host adapter termination,
you must turn switch 1 off.
See also Common Problems #1 and #3 and Section 1 : Common Problems,
Subsection 1.1 : General Flakiness
3. The SCSI subsystem locks up completely.
There are cases where the lockups seem to occur when multiple devices
are in use at the same time. In this case, you can try contacting
the manufacturer of the devices and see if firmware upgrades are
available which would correct the problem. As a last resort, you
can go into aha1542.h and change AHA1542_MAILBOX to 1. This will
effectively limit you to one outstanding command on the scsi bus at
one time, and may help the situation. If you have tape drives or
slow cdrom drives on the bus, this might not be a practical solution.
See also Common Problems #1 and #2 and
Section 1.1 : Common Problems : General Flakiness
Section 1.8 : Common Problems : SCSI Lockups
4. An "Interrupt received, but no mail" message is printed on bootup
and your SCSI devices are not detected.
Disable the BIOS options to support the extended mapping for
disks > 1G, support for > 2 drives, and for autoscanning the
bus. Or, upgrade to Linux .99.14k or newer.
5. If infinite timeout errors occur on 'C' revision boards, you may need
to go into the Adaptec setup program and enable synchronous
negotiation.
Section 4.5 : Adaptec 174x
Supported Configurations :
Slots : 1-8
Ports : EISA board, not applicable
IRQs : 9, 10, 11, 12, 14, 15
DMA Channels : EISA board, not applicable
IO : port mapped, bus master
Autoprobe : works with all supported configurations
Autoprobe override : none
Note: This board has been discontinued by Adaptec.
Common Problems :
1. If the Adaptec 1740 driver prints the message
"aha1740: Board detected, but EBCNTRL = %x, so disabled it."
your board was disabled because it was not running in enhanced
mode. Boards running in standard 1542 mode are not supported.
Section 4.6 : Adaptec 274x, 284x (Standard) 294x (ALPHA)
A newer version which also supports the Adaptec 294x boards
is available at
ftp://remus.nrl.navy.mil/pub/Linux/patches/aic7xxx.patch.gz
Supported Configurations
274x 284x 294x
EISA Slots : 1-12 N/A N/A
Ports : N/A ALL ALL
IRQs : ALL ALL ALL
DMA Channels : N/A ALL N/A
IO : port mapped, bus master
Notes:
1. BIOS MUST be enabled
2. The B channel on 2742AT boards is ignored.
3. CONFIG_PCI must be set if you are using a PCI board.
Section 4.7 : Allways IN2000 (STANDARD)
Ports : 0x100, 0x110, 0x200, 0x220
IRQs : 10, 11, 14, 15
DMA is not used
IO : port mapped
Autoprobe : BIOS not required
Autoprobe override : none
Common Problems :
1. There are known problems in systems with IDE drives and with
swapping.
Section 4.8 : EATA: DPT Smartcache, Smartcache Plus, Smartcache III (Standard)
Supported boards: all, that support the EATA-DMA protocol (no PM2001).
DPT Smartcache: PM2011 PM2012A
PM2012B
Smartcache III: PM2021 PM2022 PM2024
PM2122 PM2124
PM2322
SmartRAID : PM3021 PM3222 PM3224
many of those boards are also available as SKXXXX versions,
which are supported as well.
Supported Configurations :
Slots : ALL
Ports : ALL
IRQs : ALL level & edge triggered
DMA Channels : ISA ALL, EISA/PCI not applicable
IO : port mapped, bus master
SCSI Channels: ALL
Autoprobe : works with all supported configurations
Autoprobe Override :
Compile time : diskgeometry in eata_dma.h for unusual disk geometries
which came from the usage of the old DPTFMT utility.
The latest version of the EATA-DMA driver and a Slackware bootdisk should
be available on:
ftp.uni-mainz.de:/pub/Linux/arch/i386/system/EATA/
Common Problems :
1. The IDE driver detects the ST-506 interface of the EATA board.
1.1 This will look like similar to one of the following 2 examples:
hd.c: ST-506 interface disk with more than 16 heads detected,
probably due to non-standard sector translation. Giving up.
(disk %d: cyl=%d, sect=63, head=64)
hdc: probing with STATUS instead of ALTSTATUS
hdc: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdc: cannot handle disk with 0 physical heads
hdd: probing with STATUS instead of ALTSTATUS
hdd: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdd: cannot handle disk with 0 physical heads
If the IDE driver gets into trouble because of this, ie. you can't
access your (real) IDE hardware, change the IO Port and/or the IRQ of
the EATA board.
1.2 If the IDE driver finds hardware it can handle ie. harddisks with
a capacity <=504MB, it will allocate the IO Port and IRQ, so that
the eata driver can't utilize them. In this case also change IO Port
and IRQ (!= 14,15).
2. Some old SK2011 boards have a broken firmware. Please contact DPT's
customer support for an update.
Notes:
1. CONFIG_PCI must be set if you are using a PCI board.
Section 4.9 : Future Domain 16x0 with TMC-1800, TMC-18C30, TMC-18C50,
or TMC-36C70 chip
Supported Configurations :
BIOSs : 2.0, 3.0, 3.2, 3.4, 3.5
BIOS Addresses : 0xc8000, 0xca000, 0xce000, 0xde000
Ports : 0x140, 0x150, 0x160, 0x170
IRQs : 3, 5, 10, 11, 12, 14, 15
DMA is not used
IO : port mapped
Autoprobe : works with all supported configurations, requires
installed BIOS
Autoprobe Override : none
Antiquity Problems, fix by upgrading :
1. Old versions do not support the TMC-18C50 chip, and will fail with
newer boards.
2. Old versions will not have the most current BIOS signatures for
autodetection.
3. Versions prior to the one included in Linux 1.0.9 and 1.1.6
don't support the new SCSI chip or 3.4 BIOS.
Section 4.10 : Generic NCR5380 / T130B
Supported and Unsupported Configurations :
Ports : all
IRQs : all
DMA channels - DMA is not used
IO : port mapped
Autoprobe : none
Autoprobe Override :
Compile time : Define GENERIC_NCR5380_OVERRIDE to be an array of tupples
with port, irq, dma, board type - ie
#define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}
for a NCR5380 board at port 330, IRQ 5.
#define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}
for a T130B at port 0x350.
Older versions of the code eliminate the BOARD_* entry.
The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.
kernel command line : ncr5380=port,irq
ncr5380=port,irq,dma
ncr53c400=port,irq
255 may be used for no irq, 254 for irq autoprobe.
Common Problems :
1. Using the T130B board with the old (pre public release 6) generic
NCR5380 driver which doesn't support the ncr53c400 command
line option.
The NCR5380 compatable registers are offset eight from
the base address. So, if your address is 0x350, use
ncr5380=0x358,254
on the kernel command line.
Antiquity problems, fix by upgrading :
1. The kernel locks up during disk access with T130B or other
NCR53c400 boards
Pre-public release 6 versions of the Generic NCR5380
driver didn't support interrupts on these boards.
Upgrade.
Notes : the generic driver doesn't support DMA yet, and pseudo-DMA
isn't supported in the generic driver.
Section 4.11 : NCR53c8xx (Standard)
Supported and Unsupported Configurations :
Base addresses : ALL
IRQs : ALL
DMA channels : PCI, not applicable
IO : port mapped, busmastering
Autoprobe : requires PCI BIOS, uses PCI BIOS routines to
search for devices and read configuration space
The driver uses the pre-programmed values in some registers for
initialization, so a BIOS must be installed.
Antiquity Problems, fix by upgrading :
1. Older versions of Linux had a problem with swapping
ny i
See Section 5.2.7 : Disks : System Hangs When Swapping
2. Older versions of Linux didn't recognize '815 and '825
boards.
3. Distribution kernels include release 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
Please see all of the READMEs in that directory. 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.
- --- END Linux SCSI HOWTO part 1/2 ---
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gr...@cc.gatech.edu for public key
iQCVAwUBMHA6tntNTo2suu5NAQHeGgQAgzwxKACshxB2YCExAtSxa8tBG9nqeYq8
91Omy2ocoSjo99D+UGDr1zVOwkFMHDFrk2lGwM0Di6lzliy7qdMo7bE6gaDjHzNN
end03w7layTtgQA+J4spoFvtyi9ND+bE5CufiI9IixeryzeDcR+lSABn5JevPIz6
GUM3xq+rrt0=
=go0A
-----END PGP SIGNATURE-----
Linux SCSI HOWTO (part 1/2)