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

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

---This is part 2/2---

Sector size refers to the number of data bytes allocated per sector 
on a device, ie CDROMs use a 2048 byte sector size.  

Block size refers to the size of the logical blocks used to interface
with the device.  Although this is usually identical to sector size,
some devices map multiple smaller physical sectors (ie, 256 bytes
in the case of 55M Syquest drives) to larger logical blocks or 
vice versa (ie, 512 byte blocks on SUN compatable CDROM drives).

Removeable media devices, including Bernoulis, flopticals, and MO drives 
work.  

Section 4.2 : Common Problems 

Section 4.2.1 : Cylinder > 1024 message.

	When partitioning, you get a warning message about "cylinder > 1024"
	or you are unable to boot from a partition including a logical
	cylinder past logical cylinder 1024.

	This is a BIOS limitation.

	See Section 4.4 Disk Geometry and Partitioning for an explanation.

Section 4.2.2 :  You are unable to partition "/dev/hd*"

	/dev/hd* aren't SCSI devices, /dev/sd* are.  

	See Section 4.3, Device files, and Section 4.4, Disk
	Geometry and Partitioning
	for the correct device names and partitioning procedure.

Section 4.2.3 :   Unable to eject media from a removeable media drive.

	Linux attempts to lock the drive door when a piece of 
	media is mounted to prevent filesystem corruption due to
	an inadvertant media change.

	Please unmount your disks before ejecting them.

Section 4.2.4 : Unable to boot using LILO from a SCSI disk

	In some cases, the SCSI driver and BIOS will disagree
	over the correct BIOS mapping to use, and will result 
	in LILO hanging after 'LI' at boot time and/or 
	other problems.

	To workarround this, you'll have to determine your BIOS 
	geometry mapping used under DOS, and make an entry for 
	your disk in /etc/lilo/disktab.

	Alternatively, you may be able to use the "linear" configuration
	file option.

Section 4.2.5 : Fdisk responds with

	    	You must set heads sectors and cylinders.
    		You can do this from the extra functions menu.
	
    	and disk geometry is not 'remembered' when fdisk is rerun.

	See Section 4.4 : Partitioning

Section 4.2.6 : Only one drive is detected on a bridge board with
	multiple drives connected.

	Linux won't search LUNs past zero on SCSI devices which 
	predate ANSI SCSI revision 1.  If you wish devices on
	alternate LUNs to be recognized, you will have to modify
	drivers/scsi/scsi.c:scan_scsis().

Section 4.2.7 : System hangs when swapping

	We think this has been fixed, try upgrading to 1.1.38. 

Section 4.3 : Device Files

SCSI disks use block device major 8, and there are no "raw" devices
ala BSD.

16 minor numbers are allocated to each SCSI disk, with minor % 16 == 0 
being the whole disk, minors  1 <= (minor % 16) <= 4 the four primary 
partitions, minors 5 <= (minor % 16) <= 15 any extended partitions.

Due to constraints imposed by Linux's use of a sixteen bit dev_t with
only eight bits allocated to the minor number, the SCSI disk minor 
numbers are assigned dynamically starting with the lowest SCSI HOST/ID/LUN.

Ie, a configuration may work out like this (with one host adapter)
Device			Target, Lun		SCSI disk
84M Seagate 		0	0		/dev/sda
SCSI->SMD bridge disk 0	3	0		/dev/sdb 
SCSI->SMD bridge disk 1	3	1		/dev/sdc
Wangtek tape		4	0		none
213M Maxtor		6	0		/dev/sdd

Etc.  

The standard naming convention is 

/dev/sd{letter} for the entire disk device ((minor % 16) == 0)
/dev/sd{letter}{partition} for the partitions on that device 
	(1 <= (minor % 16) <= 15)

Ie

/dev/sda	block device major 8 minor 0
/dev/sda1	block device major 8 minor 1
/dev/sda2	block device major 8 minor 2
/dev/sdb	block device major 8 minor 16

etc.

Section 4.4 : Partitioning

You can partition your SCSI disks using the partitioning program
of your choice, under DOS, OS/2, Linux or any other operating 
system supporting the standard partitioning scheme. 

The correct way to run the Linux fdisk program is by specifying the
device on the command line. Ie, to partition the first SCSI disk,

    fdisk /dev/sda

If you don't explicitly specify the device, the partitioning program
may default to /dev/hda, which isn't a SCSI disk.

In some cases, fdisk will respond with 

	You must set heads sectors and cylinders.
	You can do this from the extra functions menu.

    Command (m for help): 

and/or give a message to the effect that the HDIO_REQ or 
HDIO_GETGEO ioctl failed.  In these cases, you must 
manually specify the disk geometry as outlined in Subsection
4.5 : Disk Geometry when running fdisk, and also in /etc/disktab
if you wish to boot kernels off that disk with LILO.

If you have manually specified the disk geometry, subsequent
attempts to run fdisk will give the same error message.  This 
is normal, since PCs don't store the disk geometry information
in the partition table. In and of itself, will cause _NO PROBLEMS_,
and you will have no problems accessing partitions you created on
the drive with Linux.  Some vendors' poor installation code will 
choke on this, in which case you should contact your vendor
and insist that they fix the code.

In some cases, you will get a warning message about a partition ending
past cylinder 1024.  If you create one of these partitions, you will 
be unable to boot Linux kernels off of that partition using LILO.  Note,
however, that this restriction does not preclude the creation of a 
root partition partially or entirely above the 1024 cylinder mark,
since it is possible to create a small /boot partition below the 
1024 cylinder mark or to boot kernels off existing partitions.

Section 4.5 : Disk Geometry 

Under Linux, each disk is viewed as the SCSI host adapter sees it : 
N blocks, numbered from 0 to N-1, all error free, where as DOS/BIOS
predate intelligent disks and apply an arbitrary head / cylinder / 
sector mapping to this linear addressing.

This can pose a problem when you partition the drives under Linux,
since there is no portable way to get DOS/BIOS's idea of the mapped 
geometry.  In most cases, a HDIO_GETGEO ioctl() can be implemented 
to return this mapping.  Unfortunately, when the vendor (ie Seagate)
has chosen a perverse, non-standard, and undocumented mapping, this 
is not possible and geometry must be manually specified

If manual specification of the is required, you have one of several
options :

1.  If you don't care about using DOS, or booting kernels from the 
    drive with LILO, create a translation such that heads * cylinders * 
    sectors * 512 < size of your drive in bytes (a megabyte is defined 
    as 2^20 bytes).

    1 <= heads <= 256
    1 <= cylinders <= 1024 
    1 <= sectors <= 63

2.  Use the BIOS mapping.  In some cases, this will mean reconfiguring the 
    disk so that it is at SCSI ID 0, and disabling the second IDE drive (if you have one).

    You can either use a program like NU, or you can use the following 
    program :

    When run it prints the sectors, heads, and cylinders of the 
    drive whose BIOS address was specified on the command line (0x80
    is the first disk, 0x81 the second).

    Ie, dparam 0x80
    60	17	1007

Would mean that C: had 60 sectors, 17 heads, and 1007 cylinders.

Section 5 : CD ROMs

This section gives information that is specific to cdrom drives.

Section 5.1 : Supported and Unsupported Hardware

SCSI CDs with a block size of 512 or 2048 bytes should work.  Other
block sizes will not work.

Section 5.2 : Common Problems

Section 5.2.1 : Unable to mount cdrom.

        The correct syntax to mount an ISO-9660 CDROM is

        mount -t iso9660 /dev/sr0 /mount_point -o ro

        Note that for this to work, you must have the kernel
        configured with support for SCSI, your host adapter,
        the SCSI CDROM driver, and the iso9660 filesystem.

Section 5.2.2 : Unable to eject cdrom.

	Linux attempts to lock the drive door when a piece of 
	media is mounted to prevent filesystem corruption due to
	an inadvertant media change.

Section 5.2.3 : Unable to play audio.

	The programs Workman or xcdplayer will do this for you.

Section 5.2.4 :  Workman or Xcdplayer do not work.

	The functions to control audio functions are part of the
SCSI-II command set, so any drive that is not SCSI-II will probably
not work here.  Also, many SCSI-I and some SCSI-II CDROM drives use a
proprietary command set for accessing audio functions instead of the
SCSI-II command set.  For NEC drives, there is a version of xcdplayer
specially adapted to use this command set floating around - try
looking on tsx-11.mit.edu in pub/linux/BETA/cdrom.

	These programs may work with some of the non-SCSI cdrom drives
if the driver implements the same ioctls as the scsi drivers.

Section 5.3 : Device Files

SCSI CD ROMs use major 11.

Minors are allocated dynamically (See Section 4 : Disks, Subsection 4.3 :
Device Files for an example) with the first CDROM found being minor 0,
the second minor 1, etc.

The standard naming convention is 

/dev/sr{digit} ie 

/dev/sr0
/dev/sr1

etc.

Section 6 : Tapes

This setion gives information that is specific to scsi tape drives.

Section 6.1 : Supported and Unsupported Hardware

Drives using both fixed and variable length blocks smaller than the
the driver buffer length (set to 32K in the distribution sources) are
supported.

Parameters (block size, buffering, density) are set with ioctls
(usually with the mt program), and remain in effect after the 
device is closed and reopened.

Virtually all drives should work, including :
	Archive Viper QIC drives, including the 150M and 525M models
	Exabyte 8mm drives
	Wangtek 5150S drives
	Wangdat DAT drives

Section 6.2 : Common Problems

Section 6.2.1 : Tape drive not recognized at boot time.

	Try booting with a tape in the drive.

Section 6.2.2 :  Tapes with multiple files cannot be read properly.

	When reading a tape with multiple files, the first tar 
	is successful, a second tar fails silently, and retrying 
	the second tar is successful.

	User level programs, such as tar, don't understand file marks.
	The first tar reads up until the end of the file.  The second 
	tar attempts to read at the file mark, gets nothing, but the 
	tape spaces over the file mark.  The third tar is successful
	since the tape is at the start of the next file.

	Use mt on the no-rewind device to space forward to the next file.

Section 6.2.3 :  Decompression fails.

	Decompressing programs cannot handle the zeros padding the 
	last block of the file. 

	To prevent warnings and errors, wrap your compressed files 
	in a .tar file - ie, rather than doing 

	tar cfvz /dev/nrst0 file.1 file.2 ...

	do 

	tar cfvz tmp.tar.z file.1 file.2 ...

	tar cf /dev/nrst0 tmp.tar.z

Section 6.2.4 :  Problems taking tapes to/from other systems.

	You can't read a tape made with another operating system or
	another operating system can't read a tape written in Linux.

	Different systems often use different block sizes.  On a
	tape device using a fixed blocksize, you will get errors 
	when reading blocks written using a different block size.

	To read these tapes, you must set the blocksize of 
	the tape driver to match the blocksize used when
	the tape was written, or to variable.

	NOTE : this is the hardware block size, not the blocking
	factor used with tar, dump, etc.

	You can do this with the mt command - 

		mt setblk <size>

	or 
	
		mt setblk 0

	to get variable block length support.

	Note that these mt flags are NOT supported under the GNU version
	of mt which is included with some Linux distributions.  Instead,
	you must use the BSD derrived Linux SCSI mt command.  Source
	should be available from

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

Section 6.2.5 :  "No such device" error message.

	All attempts to access the tape result in a 

	"No such device"

	or similar error message.  Check the type of 
	your tape device - it MUST be a character device with 
	major and minor numbers matching those specified in subsection
	C, Device Files.

Section 6.2.6 : Tape reads at a given density work, writes fail

	Many tape drives support reading at lower densities
	for compatability with older harware, but will not 
	write at those same densities.  

	This is especially the case with QIC drives, which
	will read old 60M tapes but only write new 120, 150,
	250, and 525M formats.

Section 6.3 : Device Files

SCSI tapes use character device major 9.  

Due to constraints imposed by Linux's use of a sixteen bit dev_t with
only eight bits allocated to the minor number, the SCSI tape minor 
numbers are assigned dynamically starting with the lowest SCSI HOST/ID/LUN.

Rewinding devices are numbered from 0 - with the first 
SCSI tape, /dev/rst0 being c 9 0, the second /dev/rst1 c 9 1, etc.  
Non-rewinding devices have the high bit set in the minor number, 
ie /dev/nrst0 is c 9 128.

The standard naming convention is 
/dev/nrst{digit} 	for non-rewinding devices
/dev/rst{digit}		for rewinding devices

Section 7 : Generic 

This information gives information that is specific to the generic
scsi driver.

Section 7.1 : Supported Hardware 

The Generic SCSI device driver provides an interface for sending 
SCSI commands to all SCSI devices - disks, tapes, CDROMs, media
changer robots, etc. 

Everything electrically compatable with your SCSI board should work.

Section 7.2 : Common Problems

None :-).

Section 7.3 : Device Files

SCSI generic devices use character major 21.  Due to constraints 
imposed by Linux's use of a 16 bit dev_t, minor numbers are dynamically
assigned from 0, one per device, with

/dev/sg0 

corresponding to the lowest numerical target/lun on the first 
SCSI board.

Section 8 : Buyers Guide

	A frequent question is:

	"Linux supports quite a number of different boards, so which
scsi host adapter should I get."

	The answer depends upon how much performance you expect or need, 
motherboard, and the scsi peripherals that you plan on attaching to 
your machine.

	The biggest factor affecting performance (in terms of throughput
and interactive response time during SCSI I/O) is going to be the transfer
type used.

Transfer type	Description / Performance / Recomendedations
Pure		A pure polled I/O board will use the CPU to handle 
Polled		all of the SCSI processing, including the REQ/ACK
		handshaking.

		Even a fast CPU will be slower handling the REQ/ACK
		handshake sequence than a simple finite state machine,
		resulting in peak transfer rates of about 150K/sec on
		a fast machine, perhaps 60K/sec on a slow machine 
		(through the filesystem).

		The driver also must sit in a tight loop as long as the 
		SCSI bus is busy, resulting in near 100% CPU utilitization
		and extremely poor responsiveness during SCSI/IO.
		Slow CDROMs which don't disconnect/reconnect will kill 
		interactive performance with these boards.

		Not recommended.

Interlocked	Boards using interlocked polled I/O are essentially
Polled		the same as pure polled I/O boards, only the SCSI REQ/ACK 
		handshaking signals are interlocked with the PC bus 
		handshaking signals.  All SCSI processing beyond 
		the handshaking is handled by the CPU.

		Peak transfer rates of 500-600K/sec through the 
		filesystem are possible on these boards.

		As with pure polled I/O boards, the driver must sit 
		in a tight loop as long as the SCSI bus is busy, 
		resulting in CPU utilization dependant on the 
		transfer rates of the devices, and when they 
		disconnect/reconnect.  CPU utilization may vary 
		between 25% for single speed CDs which handle
		disconnect/reconnect properly to 100% for faster
		drives or broken CD ROMs which fail to disconnect/reconnect.

		On my 486-66, with a T128, I use 90% of my CPU time to 
		sustain a throughput of 547K/sec on a drive 
		with a headrate of 1080K/sec with a T128 board.

		Sometimes acceptable for slow tapes and CDROMs when 
		low cost is essential.

FIFO 		Boards using FIFO polled I/O put a small (typically 8K)
Polled		buffer between the CPU and the SCSI bus, and often implement
		some amount of intelligence.  The net effect is that 
		the CPU is only tied up when it is transfering data
		at top speed to the FIFO and when it's handling the 
		rest of the interrupt processing for FIFO empty conditions,
		disconnect/reconnect, etc.

		Peak transfer rates should be sufficient to handle
		most SCSI devices, and have been measured at up 
		to 4M/sec using raw SCSI commands to read 64K 
		blocks on a fast Seagate Barcuda with an Adaptec 
		1520.

		CPU utilization is dependant on the transfer
		rates of the  devices, with faster devices generating
		more interrupts per unit time which require more CPU 
		processing time.   Although CPU usage may be high
		(perhaps 75%) with fast devices, the system usually 
		remains usable.  These boards will provide excellent
		interactive performance with broken devices which 
		don't disconnect/reconnect (typically cheap CDROM 
		drives)

		Recommended for persons on a budget.

Slave  		Drivers for boards using slave DMA program the PC's 
DMA		DMA controller for a channel when they do a data transfer,
		and return control to the CPU.

		Peak transfer rates are usually handicapped 
		by the poor DMA controller used on PCs, 
		with one such 8-bit board having problems
		going faster than 140-150K/sec with one mainboard.

		CPU utilization is very reasonable, slightly 
		less than what is seen with FIFO polled I/O boards.
		These boards are very tollerant of broken devices 
		which don't disconnect/reconnect (typically cheap
		CSG limitDROM drives).

		Acceptable for slow CDROM drives, tapes, etc.

Busmastering	These boards are intelligent.  Drivers 
DMA 		for these boards throw a SCSI command, the destination
		target and lun, and where the data should end up
		in a structure, and tell the board "Hey, I have 
		a command for you."  The driver returns control
		to various running programs, and eventually the 
		SCSI board gets back and says that it's done.

		Since the intelligence is in the host adapter
		firmware and not the driver, drivers for these
		boards typically support more features - synchronous
		transfers, tagged queing, etc.

		With the clustered read/write patches, peak transfer
		rates through the file system approach 100% of head rate 
		writing, 75% reading.  

		CPU utilization is minimal, irregardless of 
		I/O load, with a measured 5% CPU usage while 
		accessing a double speed CDROM on an Adaptec 1540 
		and 20% while sustaining a 1.2M/sec transfer rate
		on a SCSI disk. 

		Recommended in all cases where money is not extremely
		tight, the main board is not broken (some broken main boards
		do not work with bus masters), and applications where time 
		to data is more important than throughput are not being run 
		(bus master overhead may hit 3-4ms per command).

    The second most important driver/hardware feature with respect 
to performance is support for scatter/gather I/O.  The overhead of executing 
a SCSI command is significant - on the order of milliseconds. Intelligent bus 
masters like the Adaptec 1540 may take 3-4ms to process a SCSI command before 
the target even sees it.  On unbuffered devices, this overhead is allways enough 
to slip a revolution, resulting in a transfer rate of about 60K/sec 
(assuming a 3600RPM drive) per block transfered at a time.  So, to maximize 
performance, it is necessary to minimize the number of SCSI commands needed 
to transfer a given amount of data by transfering more data per command.  Due 
to the design of the Linux buffer cache, contiguous disk blocks are not 
contiguous in memory. With the clustered read/write patches, 4K worth of 
buffers are contiguous.  So, the maximum amount of data which can 
be transfered per SCSI command is going to be 1K * # of scatter/gather
regions without the clustered read/write patches, 4K * # of regions
with.  Experimentally, we've determined that 64K is a reasonable 
a55mount to transfer with a single SCSI command - meaning 64 scatter/gather
buffers without clustered read/write patches, 16 without.  With the 
change from 16K to 64K transfers, we saw an improvement from 
50% of headreate, through the filesystem, reading and writing,
to 75% and 100% respectively using an Adaptec 1540 series board.

    Bus type is the next thing to consider, with choices including ISA,
EISA, VESA, and PCI.  Marketing types often spout of absurd bandwidth
numbers based on burst transfer rates and fiction, which isn't very 
useful.  Instead, I've chosen to state "real-world" numbers based on 
measured performance with various peripherials.

Bus	Bandwidth, description, 
ISA	Bandwidth is slightly better than 5M/sec for  busmastering 
	devices.  With an ISA bus, arbitration for busmasters is performed 
	by the venerable 8237 third party DMA controller, resulting in 
	relatively high bus aquisition times.  Interrupt drivers are
	tri-state and edge triggered, meaning interrupts cannot be 
	shared. Generally, ISA is unbuffered, meaning the host/memory
	bus is tied up whenever a transfer is occuring. No mechanism
	is provided to prevent bus-hogging.

VESA	Bandwidth is about 30M/sec.  Some VESA systems run the bus out 
	of spec, rendering them incompatable with some boards, so this
	should be taken into consideration before purchasing hardware
	without a return guarantee.  Generally, VESA is unbuffered, meaning
	meaning the host/memory bus is tied up whenever a transfer is 
	occuring.

EISA	Bandwidth is about 30M/sec, with busmastering operations generally
	being faster than VESA.  Some EISA systems buffer the bus, allowing
	burst transfers to the faster host/memory bus and minimizing impact
	on CPU performance.  EISA interrupt drivers may be either tri-state
	edge-triggered or open collector level-active, allowing interrupt
	sharing with drivers that support it.  Since EISA allocates a 
	separate address space for each board, it is usually less prone to 
	resource conflicts than ISA or VESA.

PCI	Bandwidth is about 60M/sec.  Most PCI systems implement write
	posting buffers on the host bridge, allowing speed mismatches
	on either side to have a minimum impact on bus/CPU performance.  
	PCI interrupt drivers are open collector level-active, allowing
	interrupt sharing with drivers that support it. Mechanisms
	are provided to prevent bus hogging, and for both master and 
	slave to suspend a bus-mastering operation. 

	Since PCI provides a plug-n-play mechanism with writeable 
	configuration registers on every board, in a separate address space, 
	a propperly implemented PCI system is plug-and play.  

	PCI is extremely strict as to trace length, loading, mechanical
	specifications, etc. and ultimately should be more reliable than
	VESA or ISA.

	In summary, PCI is the best PC bus, although it does
	have its dark side.  PCI is still in its infancy, and although
	most manufacturers have ironed out the problems, there is 
	still stock of older, buggy PCI hardware and broken main 
	BIOSes.  For this reason, I _strongly_ recommend a return
	guarantee on the hardware.  While the latest PCI mainboards
	are truly plug-and-play, older PCI boards may require the 
	user to set options with both jumpers and in software (ie,
	interrupt assignments).  Although many users have 
	resolved their PCI problems, it has taken time and for this
	reason I cannot recommend a PCI purchase if having the 
	system operational is extremely time critical.

    For many slower SCSI devices, such as disks with head rates 
arround 2M/sec or less, CDROMs, and tapes, there will be little difference
in throughputs with the different PC bus interfaces.  For faster contemporary
SCSI drives (Typical high end multi-gigabyte drives have a head rate of 
4-5M/sec, and at least one company is currently ALPHA testing a parallel
head unit with a 14M/sec head rate), throughput will often be significantly 
better with controllers on faster busses, with one user noting a 2.5 fold 
performance improvement when going from an Adaptec 1542 ISA board to a 
NCR53c810 PCI board. 

    With the exception of situations where PCI write-posting or a 
similar write-buffering mechanism is being used, when one of the busses in 
your system is busy, all of the busses will be unaccessable.  So, although 
bus saturation may not be interfering with SCSI performance, it may have a 
negative effect on interactive performance.  Ie, if you have a 4M/sec SCSI 
disk under ISA, you'll have lost 80% of your bandwidth, and in an 
ISA/VESA system would only be able to bitblt at 6M/sec.  In most cases,
a similar impact on processing jobs in the background would also be felt.

    Note that having over 16M of memory does not preclude using
an ISA busmastering SCSI board.  Unlike various broken operating
systems, Linux will double buffer when using a DMA with an ISA controller
and a transfer is ultimately destined for an area above 16M.  Performance
on these transfers only suffers by about 1.5%, ie not noticably.

    Finally, the price difference between bus masters offered with the 
different bus interfaces is often minimal.  

    With all that in mind, based on your priorities you will have 
certain bus preferences 

	Stability, time critical installations,  	EISA ISA VESA PCI
	    and poor return policies
	Performance, and typical hobbiest		PCI EISA VESA ISA
	    installations

     As I pointed out earlier, bus mastering versus other transfer modes is going to have 
a bigger impact on total system performance, and should be considered
more important than bus type when purchasing a SCSI controller.

    If will you have multiple devices on your SCSI bus, you may
want to see whether the host adapter/driver that you are considering supports
more than one outstanding command at one time.  This is very
important if you are mixing devices of different speeds, like a
tape drive and a disk drive.  If the linux driver only supports one
outstanding command, you may be locked out of your disk drive while 
a tape in the tape drive is rewinding, for example.  With two
disk drives, the problem will not be as noticeable, allthough 
throughput would approach the average of the two transfer rates 
rather than the sum of the two transfer rates.

Driver feature comparison (supported chips are listed in parenthesis)

Driver  				Simultaneous	SG	 	> 1 
		Transfer mode		Commands	limit		Boards
					total/LUN
aha152x	  	FIFO(8k) Polled	   	1s/1s		255s
    (AIC6260,
    AIC6360)
aha1542   	Busmastering DMA 	8s/1s		16		Y
aha1740	  	Busmastering DMA 	32s		16
aha274x		Busmastering DMA	4s/1s		1		Y	
buslogic	Busmastering DMA	Y		64s, 8196h 	
fdomain		FIFO(8k) Polled		1s		64s
    (TMC1800,
    TMC18c30,
    TMC18c50)
in2000*		FIFO(2k) Polled		1s		255s
g_NCR5380	Pure Polled 		16s/2s		255s		Y
    (NCR5380,
    NCR53c80,
    NCR5381, 
    NCR53c400)
gsi8*		Slave DMA		16s/2s		255s
    (NCR5380)
PAS16		Pure Polled		16s/2s		255s		Y
    (NCR5380)	or Interlocked Polled
		(fails on some systems!)
seagate		Interlocked Polled	1s		255s		N
wd7000	  	Busmastering DMA	8s		1
t128		Interlocked Polled	16s		255s		Y
    (NCR5380)
ultrastor 	Busmastering DMA	Y	
53c7,8xx	Busmastering DMA	1s/1s		255s		Y
    (NCR53c810)

Notes : 
1.  drivers flagged with an '*' are not included with the 
    distribution kernel, and binary boot images may be unavailable.

2.  numbers suffixed with an 's' are arbitrary limits set in software 
    which may be changed with a compile time define.  

3.  hardware limits are indicated by an 'h' suffix, and may differ
    from the software limits currently imposed by the Linux drivers.

4.  unsuffixed numbers may indicate either hard or soft limits.

Board comparison : 
Board			Driver		Bus	Price	Notes
Adaptec AIC-6260	aha152x		ISA		chip, not board
Adaptec AIC-6360	aha152x		VLB		chip, not board
    (Used in most 
    VESA/ISA multi-IO
    boards with SCSI,
    Zenon mainboards)
Adaptec 1520		aha152x		ISA		 
Adaptec 1522		aha152x		ISA	$80	1520 w/FDC
Adaptec 1510		aha152x		ISA		1520 w/out boot ROM,
							won't autoprobe.
Adaptec 1540C		aha1542		ISA		
Adaptec 1542C		aha1542		ISA		1540C w/FDC
Adaptec 1540CF		aha1542		ISA		FAST SCSI-II
Adaptec 1542CF		aha1542		ISA	$200	1540CF w/FDC

Adaptec 1740		aha1740		EISA		discontinued
Adaptec 1742		aha1740		EISA		discontinued, 1740 
							w/FDC
Adaptec 2740		aha274x		EISA
Adaptec 2742		aha274x		EISA		
Allways IN2000		in2000		ISA
Buslogic 445S		aha1542, 	VLB	$250	FAST SCSI-II, active
			buslogic			termination, w/FDC
Buslogic 747S		aha1542, 	EISA		FAST SCSI-II, active
			buslogic			termination, w/FDC
Buslogic 946S		buslogic	PCI		FAST SCSI-II, activte
							termination.  
DTC 3290		aha1542		EISA		Although it should work,
							due to documentation
							release polcies, DTC
							hardware is unsupported
DTC 3292		aha1542		EISA		3290 w/FDC
Future Domain 1680	fdomain		ISA		FDC
Future Domain 3260	fdomain		PCI

NCR53c810 (boards sold 53c7,8xx		PCI     $70	chip, not board. Boards
    by FIC, Chaintech,				(board)	don't include
    Nextor, Gigabyte, etc.  			        BIOS, although most
    Mainboards with chip by				non-NCR equipped main
    AMI, ASUS, J-Bond,					boards have the SDMS
    etc. Common in DEC					BIOS
    PCI systems)
						    
Pro Audio Spectrum 16	pas16		ISA		Sound board w/SCSI
Seagate ST01		seagate		ISA	$20	BIOS only works with
							some drives
Seagate ST02		seagate		ISA	$40	ST01 w/FDC
Sound Blaster 16 SCSI 	aha152x		ISA		Sound board w/SCSI
Western Digital 7000	wd7000		ISA		w/FDC
Trantor T128		t128		ISA		
Trantor T128F		t128		ISA		T128 w/FDC and 
							support for high IRQs
Trantor T130B		g_NCR5380	ISA		
Ultrastor 14F		ultrastor	ISA		w/FDC
Ultrastor 24F		ultrastor	EISA		w/FDC
Ultrastor 34F		ultrastor	VLB 

Notes : 
1.  Trantor was recently purchased by Adaptec, and some products are being	
    sold under the Adaptec name.

2.  Ultrastor recently filed for Chapter 11 Bankruptcy, so technical
    support is non-existant at this time.

3.  Various Buslogic boards other than the 545S, 445S, 747S, and
    946S _should_ work,  although to my knowledge have not been
    tried.

4.  The $70 price for the busmastering NCR53c810 boards is not
    a typo, includes the standard ASPI/CAM driver package for 
    DOS, OS/2 and Windows (32 bit access), and other drivers are 
    available for free download. 

    If you can't find one at that price, try Technoland at 
    1-800-292-4500 or 1-408-992-0888 if you live in California.

5.  Adaptec's recent SCSI chips show an unusual sensitivity
    to cabling and termination problems. For this reason,
    I cannot recommend the Adaptec 154x C and CF revisions or the 
    274x series.

    Note that the reliability problems do NOT apply to the 
    older 154x B revision boards, 174x A revision boards,
    or to my knowledge AIC-6360/AIC-6260 based boards.

    Also, the quality of their technical support has slipped markedly, with
    long delays becoming more common, and their employees being ignorant 
    (suggesting there were non-disclosure policies affecting certain
    literature when there were none), and hostile (ie, refusing to pass 
    questions on to some one else when they couldn't answer them).

    If users desire handholding, or wish to make a political statement,
    they should take this point into consideration.  Otherwise, the 
    Adaptec 152x/1510 are nicer than the other ISA boards in the 
    same price range, and there are some excellent deals on used and
    surplus 154x B revision boards and 1742 boards which IMHO outweigh
    the support problems.
    
    Most ISA, EISA, and VESA users will probably be served best by 
a Buslogic board, due to its performance, features such as active termination, 
and Adaptec 1540 compatability.  There are a number of models available with 
EISA, ISA, PCI, and VESA local bus interfaces, in single ended and differential,
and 8/16 bit SCSI bus widths.

    People with PCI systems should seriously consider NCR53c810
based boards.  These are bus mastering SCSI controllers, available in 
Q1 for about $70 (ie, cheaper than the Adaptec 1520) with larger 
quantities being cheaper (I've seen $62 in Q20).  In addition to being
the cheapest PCI SCSI boards, the NCR boards were also benchmarked 
as faster than the Adaptec 2940 and Buslogic BT-946, and demonstrate 
excellent performance under Linux (up to 4M/sec through the file system )
inspite of the performance optomizations being disabled in the current
driver.  The disadvantages of these boards versus the Buslogics are that 
they aren't Adaptec 1540 compatable, don't come with active termination, 
and to my knowledge are only supported under DOS+Windows, OS/2, Windows NT, 
SCO, NeXTstep, and Free BSD.  Currently, the driver is somewhat 
limited, but appears quite stable (We've moved several gigabytes of data to NCR based 
devices with no problems), surprisingly fast (I've seen 4M/sec through
the filesystem) and will rapidly become more featureful.
	
	People wanting non-PCI SCSI on a limited budget will probably be 
happiest finding a surplus or used Adaptec 154x B revision or 174x A 
revision, or an Adaptec 1520 clone of some sort (about $80) if they want
new.  These boards offer reasonable throughput and interactive performance at a 
modest price.

EOF