Subject: Linux SCSI HOWTO (part 1/2)
From: Drew Eckhardt <[email-masked]>
Date: Thu, 4 Aug 1994 04:10:57 GMT
Newsgroups: comp.os.linux.announce,comp.os.linux.admin

Archive-name: linux/howto/scsi/part1
Version: 2.08
Last-modified: 4 Aug 94

Copyright 1994, Drew Eckhardt

Commercial redistribution is allowed and encouraged, provided that the 
author is notified of any such distributions and given opportunity to
to provide a more up-to-date version.  Failure to comply with this 
will result in the author refusing to answer questions which are answered 
in newer versions, and publically denouncing your distribution as a grave 
disservice to the Linux community.

Noncommercial redistributions  of a verbatim copy in any medium physical or 
electronic are permitted without express permission of the author.  
Translations are similarly permitted without express permission if they
includes a notice on who translated it. 

Short quotes may be used without prior consent by the author. Derivative work
and partial distributions of the SCSI-HOWTO must include either a verbatim
copy of this file or make a verbatim copy of this file available. If the 
latter is the case, a pointer to the verbatim copy must be stated at a 
clearly visible place.

In short, we wish to promote dissemination of this information through as
many channels as possible. However, we do wish to retain copyright on the
HOWTO documents, to be notified of any plans to redistribute the HOWTOs
to insure that outdated versions don't spread too far, and for ALL 
the information provided in the HOWTOS to be disseminated. If you have 
questions, please contact Matt Welsh, the Linux HOWTO coordinator, 
at [email-masked], or +1 607 256 7372.

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.1.38 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 SCSI channel of the
Linux activists list - mail to [email-masked] 
with the line 

X-MN-Admin: join SCSI

in the header.

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 2			Reporting Bugs

Section 3			Hosts
    Section 3.1			Supported and Unsupported Hardware
    Section 3.2			Common Problems
    Section 3.3			Adaptec 152x, 151x, Sound Blaster 16 SCSI,
				    SCSI Pro, Gigabyte, and other AIC 
				    6260/6360 based products (Standard)
    Section 3.4			Adaptec 154x, AMI FastDisk VLB,
				    Buslogic, DTC 329x (Standard)  
    Section 3.5			Adaptec 174x (Standard)
    Section 3.6			Adaptec 274x (pre-ALPHA)
    Section 3.7			Allways IN2000 (ALPHA)
    Section 3.8			DPT (ALPHA)
    Section 3.9			Future Domain 16x0 with TMC-1800, TMC-18C30,
				    or TMC-18C50 chip (Standard)
    Section 3.10		Generic NCR5380 / T130B (Standard)
    Section 3.11		NCR53c810 (Standard)
    Section 3.12		Seagate ST0x/Future Domain TMC-8xx/TMC-9xx 
				    (Standard)
    Section 3.13 		PAS16 (Standard)
    Section 3.14		Trantor T128/T128F/T228 (Standard)
    Section 3.15		Ultrastor 14f, 24f,  34f (Standard)
    Section 3.16		Western Digital 7000 (Standard)

Section 4			Disks
    Section 4.1 		Supported and Unsupported Hardware 
    Section 4.2 		Common Problems 
    Section 4.3			Device Files
    Section 4.4			Partitioning 
    Section 4.5			Disk Geometry

Section 5 			CD ROMs
    Section 5.1			Supported and Unsupported Hardware 
    Section 5.2			Common Problems
    Section 5.3			Device Files 

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

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

Section 8			Buyers Guide

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, 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 who

	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 (typically
	/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 

	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.

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).  Please change the jumper settings.

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

	The device has buggy firmware.  There is a list of buggy devices
	in the kernel sources in drivers/scsi/scsi.c in the variable
	blacklist.  Try adding the device to the list and see if this helps.

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.

	Your SCSI bus must be terminated at both ends (using external
	terminators, or onboard terminators on the host adapter or 
	devices) and not in the middle.

	The SCSI-2 specification recommends active termination at both ends
	of the cable.  For SCSI configurations with just one device and a
	short cable, you can probably get away with passive termination,
	but if you start having SCSI reliability problems when you start
	adding more devices or using a longer cable then you should try
	active termination.  See the Comp.Periphs.Scsi FAQ (available on
	tsx-11 in pub/linux/ALPHA/scsi) for more information about active
	termination.

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 MAKDEV 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 fifteen partition entries for 
	each)

	./MAKEDEV sdc\*

	"should" create entries for /dev/sdc and all fifteen 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 3 : 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 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 more 
revisions 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, and the exact text of 
all of the messages that Linux prints when it boots and when the 
error condition occurs.  Failure to provide the exact text of any and
all messages may result in misdiagnosis of your problem.

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.

Assuming you don't yet have Linux up and running, a good way to provide
the information we need would be to perform the following procedure :

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.

Boot Linux, and login 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

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/dos/log
	cat /proc/kmsg >> /tmp/dos/log

Type CNTRL-C after a second or two.

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 3 : Hosts

This section gives specific information about the various host adapters that
are supported in some way or another under linux.

Section 3.1 : Supported and Unsupported Hardware
Drivers in the distribution kernel :

Adaptec 152x, Adaptec 154x (including clones from Bustek and DTC 329x 
boards), Adaptec 174x, Future Domain 850, 885, 950, and other boards 
in that series (but not the 880 board unless you make the appropriate 
patch), Future Domain 16x0 with TMC-1800 or TMC-18C50 chip, PAS16 
SCSI ports, Seagate ST0x, Trantor T128 boards, Ultrastor 14F, 24F, and 34F, 
and Western Digital 7000. 

Alpha drivers :
Adaptec 2742
DPT
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 :

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.

Adaptec 2842, 2940, various AIC 7770/7870 implementations

    An Adaptec 2742 driver for the EISA AIC-7770 board has 
    been developed, and with some modifications (perhaps 
    limited to detection) should support these boards.
    
NCR53c8x0/7x0

    A NCR53c810 drviver has been developed, and with modifications
    ranging from minor to severe should support these chips

    NCR53c815 - detection changes

    NCR53c820, NCR53c825 - detection changes, possible initialization
	changes, ultimately support for WDTR messages.

    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, elimination of add with carry
	instructions through DSA alignment modification.

    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 

Trantor T130B / generic NCR53c400 using pseudo DMA

    The Trantor T130B uses an NCR53c400 chip, essentially a more 
    integrated, low-performance ISA SCSI solution adding a pair of 
    128 byte buffers and on-chip "pseudo-DMA" hardware to 
    a NCR5380 ASIC core 

    Kevin's patches to support the on-chip buffers and interrupts
    on the board work, and an effort to integrate them into an
    ALPHA kernel is being made.

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

Aquiring programming information requires a non-disclosure agreement
with DTC.  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 3.2 : Common Problems 
Section 3.2.1 : SCSI timeouts 
	Make sure interrupts are enabled correctly, and there are no 
	IRQ, DMA, or address conflicts with other boards.

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

Section 3.2.4 : Failure of bootable kernels for a ALPHA drivers

        This You get resulting in a "kernel panic : cannot mount root device"
	message, or it does not work with your Linux distribution.

	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 0

	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 0, 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 3.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 3.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 scsiid of AIC-6260 (0-7) (default 7)
RECONNECT     : override target dis-/reconnection/multiple 
	outstanding command - set to non-zero to enable, 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 3.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: 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.

Section 3.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 3.6 : Adaptec 274x (Pre-ALPHA)
	available via anonymous FTP from ftp.cpsc.ucalgary.ca
	/pub/systems/linux/aha274x.
Supported Configurations : 
Slots : 1-12
Ports : EISA board, not applicable
IRQs : ALL
DMA Channels : EISA board, not applicable
IO : port mapped, bus master

BIOS MUST be enabled

Section 3.7 : Allways IN2000  (ALPHA)
ALPHA available via ftp tsx-11.mit.edu/pub/linux/ALPHA/SCSI/in2000
	driver is in2000.tar.z, bootable kernel zImage
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 3.8 : DPT
ALPHA available via ftp ftp.ibp.fr in directory /pub/linux/ALPHA/scsi

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

	ncr53480=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 3.11 : NCR53c810 (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

	See Section 4.2.7 : Disks :  System Hangs When Swapping

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.

	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.

	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 occur when using an S3928P, X11, and the NCR
	chip at the same time.

	There are hardware bugs in at least some S3928P chip.  Don't
	do this.

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

	- Intel P90 boards require revision 1.00.04.AX1

Section 3.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.
A
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 4.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 4.4 : Disks : Partitioning

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

    The code in seagate.c looks like this now : 

    cli();
    DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
    CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | 
	    (reselect ? CMD_ATTN : 0);
    sti();

    Changing this to 

    cli();
    CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | 
	    (reselect ? CMD_ATTN : 0);
    DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
    sti()

    may fix your problem.

Defines : 

FAST or FAST32 will use blind transfers where possible

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

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

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

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

Autoprobe : does not require BIOS

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

#define PAS16_OVERRIDE {{0x388, 10}} 

for a board at port 0x388, IRQ 10.

kernel command line : 
pas16=port,irq 

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

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

PARITY - enable parity checking.  Not supported

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

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

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

Common problems : 

1.  Command timeouts, aborts, etc.

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

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

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

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

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

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

#define T128_OVERRIDE {{0xcc000, 5}} 

for a board at address 0xcc000, IRQ 5.

The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used.

kernel command line : t128=address,irq

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

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

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

PARITY - enable parity checking.  Not supported

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

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

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

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

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

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

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

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

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

Autoprobe override : compile time only, define PORT_OVERRIDE

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

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

        Please use a different address.

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

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

4.  Linux detects no SCSI devices, but detects your SCSI hard disk
	on an Ultrastor SCSI board as a normal hard disk, and the
	hard disk driver refuses to support it.  Note that when this 
	occurs, you will probably also get a message
	
	hd.c: ST-506 interface disk with more than 16 heads detected,
	  probably due to non-standard sector translation.  Giving up.
	  (disk %d: cyl=%d, sect=63, head=64)

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

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

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

	2.  Use the kernel command line switch 

	    hd=cylinders,heads,sectors

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

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

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

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

Autoprobe :  requires installed BIOS 

Common Problems : 

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

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

Section 4 : Disks 

This section gives information that is specific to disk drives.

Section 4.1 : Supported and Unsupported Hardware

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

---End of part 1/2---