General Description
===================

This driver supports the 53c700 and 53c700-66 chips.  It also supports
the 53c710 but only in 53c700 emulation mode.  It is full featured and
does sync (-66 and 710 only), disconnects and tag command queueing.

Since the 53c700 must be interfaced to a bus, you need to wrapper the
card detector around this driver.  For an example, see the
NCR_D700.[ch] or lasi700.[ch] files.

The comments in the 53c700.[ch] files tell you which parts you need to
fill in to get the driver working.


Compile Time Flags
==================

The driver may be either io mapped or memory mapped.  This is
selectable by configuration flags:

CONFIG_53C700_MEM_MAPPED

define if the driver is memory mapped.

CONFIG_53C700_IO_MAPPED

define if the driver is to be io mapped.

One or other of the above flags *must* be defined.

Other flags are:

CONFIG_53C700_LE_ON_BE

define if the chipset must be supported in little endian mode on a big
endian architecture (used for the 700 on parisc).

CONFIG_53C700_USE_CONSISTENT

allocate consistent memory (should only be used if your architecture
has a mixture of consistent and inconsistent memory).  Fully
consistent or fully inconsistent architectures should not define this.


Using the Chip Core Driver
==========================

In order to plumb the 53c700 chip core driver into a working SCSI
driver, you need to know three things about the way the chip is wired
into your system (or expansion card).

1. The clock speed of the SCSI core
2. The interrupt line used
3. The memory (or io space) location of the 53c700 registers.

Optionally, you may also need to know other things, like how to read
the SCSI Id from the card bios or whether the chip is wired for
differential operation.

Usually you can find items 2. and 3. from general spec. documents or
even by examining the configuration of a working driver under another
operating system.

The clock speed is usually buried deep in the technical literature.
It is required because it is used to set up both the synchronous and
asynchronous dividers for the chip.  As a general rule of thumb,
manufacturers set the clock speed at the lowest possible setting
consistent with the best operation of the chip (although some choose
to drive it off the CPU or bus clock rather than going to the expense
of an extra clock chip).  The best operation clock speeds are:

53c700 - 25MHz
53c700-66 - 50MHz
53c710 - 40Mhz

Writing Your Glue Driver
========================

This will be a standard SCSI driver (I don't know of a good document
describing this, just copy from some other driver) with at least a
detect and release entry.

In the detect routine, you need to allocate a struct
NCR_700_Host_Parameters sized memory area and clear it (so that the
default values for everything are 0).  Then you must fill in the
parameters that matter to you (see below), plumb the NCR_700_intr
routine into the interrupt line and call NCR_700_detect with the host
template and the new parameters as arguments.  You should also call
the relevant request_*_region function and place the register base
address into the `base' pointer of the host parameters.

In the release routine, you must free the NCR_700_Host_Parameters that
you allocated, call the corresponding release_*_region and free the
interrupt.

Handling Interrupts
-------------------

In general, you should just plumb the card's interrupt line in with

request_irq(irq, NCR_700_intr, <irq flags>, <driver name>, host);

where host is the return from the relevant NCR_700_detect() routine.

You may also write your own interrupt handling routine which calls
NCR_700_intr() directly.  However, you should only really do this if
you have a card with more than one chip on it and you can read a
register to tell which set of chips wants the interrupt.

Settable NCR_700_Host_Parameters
--------------------------------

The following are a list of the user settable parameters:

clock: (MANDATORY)

Set to the clock speed of the chip in MHz.

base: (MANDATORY)

set to the base of the io or mem region for the register set. On 64
bit architectures this is only 32 bits wide, so the registers must be
mapped into the low 32 bits of memory.

pci_dev: (OPTIONAL)

set to the PCI board device.  Leave NULL for a non-pci board.  This is
used for the pci_alloc_consistent() and pci_map_*() functions.

dmode_extra: (OPTIONAL, 53c710 only)

extra flags for the DMODE register.  These are used to control bus
output pins on the 710.  The settings should be a combination of
DMODE_FC1 and DMODE_FC2.  What these pins actually do is entirely up
to the board designer.  Usually it is safe to ignore this setting.

differential: (OPTIONAL)

set to 1 if the chip drives a differential bus.

force_le_on_be: (OPTIONAL, only if CONFIG_53C700_LE_ON_BE is set)

set to 1 if the chip is operating in little endian mode on a big
endian architecture.

chip710: (OPTIONAL)

set to 1 if the chip is a 53c710.

burst_disable: (OPTIONAL, 53c710 only)

disable 8 byte bursting for DMA transfers.

SUBJECT
-------
AM53/79C974 PC-SCSI Driver


DISCLAIMER
----------
***  THIS SHOULD BE CONSIDERED AS BETA SOFTWARE  ***
***  USE AT YOUR OWN RISK!                       ***


Copyright
---------
The architecture and much of the code of this device driver was
originally developed by Drew Eckhardt for the NCR5380. The
following copyrights apply:

For the architecture and all pieces of code which can also be found
in the NCR5380 device driver:
Copyright 1993, Drew Eckhardt
  Visionary Computing
  (Unix and Linux consulting and custom programming)
  drew@colorado.edu
  +1 (303) 666-5836

The AM53C974_nobios_detect code was originally developed by
Robin Cutshaw (robin@xfree86.org) and is used here in a
slightly modified form.

For the remaining code:
  Copyright 1994, D. Frieauff
  EMail: fri@rsx42sun0.dofn.de
  Phone: x49-7545-8-2256 , x49-7541-42305


Version
-------
AM53/79C974 (PC-SCSI) Linux driver ALPHA release 0.5, 19 November 1995


Changelog
---------
0.1 -> 0.2:
  - Extended message handling re-written to eliminate 'invalid message 17' bug
  - Parameters of AM53C974_intr adapted
  - Debug messages structured
  - Spelling improved
0.2 -> 0.3:
  - README file updated -- please read this file up to the end!
  - Automatic scanning of io_port and irq implemented; no need for BIOS32
    anymore
  - Improved configuration (now via LILO parameter string)
  - Cleanup of probing and initialization code
  - Improved sync. negotiation (can be setup individually for every device)
  - Improved/ debugged code for reception of ext. messages
0.3 -> 0.4:
  - Improved PCI probing and initialization code
  - Compatibility changes for Linux 1.3.x
0.4 -> 0.5:
  - Compatibility changes for Linux 1.3.42


Bugs & Todo
-----------
 - Add proc info function
 - Support SCSI-2 tagged queuing
 - Finalize abort code


Features
--------
This driver supports asynchronous and synchronous SCSI-I and SCSI-II
devices.  It is capable of transfer rate and synchronous negotiation
(see below).  The driver supports scatter-gather.  Transfers are DMA
based, but do not (yet) make use of the AM53/79C974 MDL mode.
Max. transfer rate is 10MHz (whatever this is in real life).  The
transfer rate is negotiated with each device (see dmesg output).  The
AM53/79C974 has a 96-byte DMA FIFO to the PCI bus and a 16-byte SCSI
FIFO.  It provides active negation and glitch suppression functions.
Burst DMA transfer rate is 132 MBytes/sec.


Configuration
-------------

The following communication characteristics can be set individually
for every SCSI device on the bus:

  - enable/disable sync. negotiation
  - transfer rate
  - asynchronous or synchronous communication
  - in case of sync. communication, the sync. offset

The sync. offset specifies the number of bytes that can be sent or
received from the SCSI bus without ACK resp. REQ signal.
CAUTION: USING SYNCHRONOUS MODE ON LONG SCSI CABLES MAY CAUSE
         COMMUNICATION PROBLEMS LEADING TO LOSS OF DATA.

The default setting of the SCSI communication parameters is as follows:
  - no negotiation
  - 5.0 MHz transfer rate
  - asynchronous mode
  - zero offset

The parameters can be modified by passing a string with the following
syntax to the kernel:

	AM53C974=host-scsi-id,target-scsi-id,max-rate,max-offset

The parameters will be used by the driver as negotiation basis.  The
range of the rate parameter is 3 to 10 MHz.  The range of the
sync. offset parameter is 0 to 15 bytes. A value of 0 denotes
asynchronous comm. mode.  If the target cannot cope with the specified
transfer rate, sync. mode or sync.  offset, the negotiation result
will differ from the specified values.  The negotiation result is
printed out at the end of the negotiation process (to read it, use the
dmesg program or the appropriate syslog).  The parameter strings
(blank separated) can be passed to the kernel at the LILO prompt, or
as part of the LILO configuration file.

For example, the string "AM53C974=7,2,8,15" would be interpreted as
follows:

For communication between the controller with SCSI-ID 7 and the
device with SCSI-ID 2 a transfer rate of 8MHz in synchronous mode with
max. 15 bytes offset should be negotiated.

As an example, here my LILO configuration file:
  boot = /dev/sda
  compact
  #prompt
  delay = 50	# optional, for systems that boot very quickly
  vga = normal	# force sane state
  ramdisk = 0	# paranoia setting
  root = current  # use "current" root
  image = /usr/src/linux/arch/i386/boot/zImage
    label = linux
    append = "AM53C974=7,0,10,0 AM53C974=7,1,10,0 AM53C974=7,2,10,15 AM53C974=7,4,10,0 AM53C974=7,5,10,0"
    read-only
  other = /dev/sda4
    label = os2
  other = /dev/sdb3
    loader = /boot/any_d.b
    table = /dev/sdb
    label = setup

The same parameters at the LILO prompt:

  LILO boot: linux AM53C974=7,0,10,0 AM53C974=7,1,10,0 AM53C974=7,2,10,15 AM53C974=7,4,10,0 AM53C974=7,5,10,0

You can override parameters specified in the LILO configuration file
by parameters specified on the LILO command line.


BIOS usage
----------
Version 0.4 of the driver will use the BIOS, if available. Otherwise
it will try its internal PCI scan and access routines.  The driver
assumes that the controller's SCSI-ID (usually 7) has been correctly
loaded by the BIOS into the controller's register during system
boot. If the driver detects that the controller's SCSI ID is not '7'
it will print out a warning. If this happens to you please correct
setting of the controller's SCSI-ID. If it is wrong, then edit the
AM53C974_SCSI_ID definition in file AM53C974.h accordingly.


Test environment
----------------
This driver was tested on a Compaq XL566 with the following SCSI configuration:
2 x HP C2247 fixed disk (internal, rate=10MHz, async.)
1 x Micropolis 1624 fixed disk (external, rate=8MHz, sync., offset=15 bytes)
1 x Wangtek W5525ES cartridge streamer (internal, rate=5MHz, async.)
1 x Toshiba XM-3301B CD-ROM (external, rate=5MHz, async.)


Known problems
--------------
 - Compaq/Matsushita CD-ROM:
   Use of this device with AM53C974 driver version 0.2 caused the kernel to
   hang during Linux boot. If you encounter the problem, don't enable sync.
   negotiation with the CD-ROM, i.e. simply don't specify comm. parameters
   for this device on the LILO command line or configuration file.
   The driver will thus use its default for the CD-ROM, which is 5MHz
   transfer rate async and no sync. negotiation.
 - Some disks cause problems.


What to do if there is a SCSI problem possibly related to the driver
--------------------------------------------------------------------

Read Klaus Liedl's WWW page (http://www-c724.uibk.ac.at/XL/).  In case
this does not help: Send me a complete description of the problem,
including your SCSI configuration plus as much debugging information
as possible.  Don't wait until I ask you for this information. To
enable the generation of debugging output, remove the comments from
the following definitions in the AM53C974.h file:

    AM53C974_DEBUG
    AM53C974_DEBUG_MSG
    AM53C974_DEBUG_KEYWAIT
    AM53C974_DEBUG_INFO
    AM53C974_DEBUG_INTR

With these definitions enabled, the driver will enter single-step mode
during Linux boot. Use the spacebar for stepping.  Take note of at
least the last 10 printout sections (marked by dashes) before the
crash/hangup or whatever happens and send me all of this information
via email. If the system can boot, use the syslogd daemon to record
the debugging output. Maybe you can use the ramdisk for this purpose
too (if necessary, kindly ask K. Liedl (Klaus.Liedl@uibk.ac.at) for
support, he knows how to do it -- I never tried). Stay in email
contact with me. Be aware that the following weeks/months could be the
worst of your life.  Note: If single-stepping takes up too much time,
you can try to let the driver catch the problem by pressing the 'r'
key. The driver will automatically enter single-step mode if it has
detected something weird.


Author's Contact Address
-----------------------
Email: fri@rsx42sun0.dofn.de
Phone: x49-7545-2256 (office), x49-7541-42305 (home)
Home address: D. Frieauff, Stockerholzstr. 27, 88048 Friedrichshafen, Germany


!!!! Important Notice !!!!
-----------------------------
- Klaus Liedl maintains an excellent WWW page about Linux on Compaq XL.
  It includes an FAQ, lots of tips & tricks as well as downloadable
  boot disk images. The URL is: http://www-c724.uibk.ac.at/XL/
- Volunteer wanted for further maintenance of this driver software. I
  don't have the time anymore to do serious support as some of you will know.


Literature
----------
 - AMD AM53C974 PC-SCSI Technical Manual, publication #18624B
 - Amendment to the AMD AM53C974 PC-SCSI Technical Manual
 - AMD AM79C974 PC-NET Datasheet, publication #18681
 - Amendment to the AMD AM79C974 PC-NET Datasheet


THANKS to
---------
 - Drew Eckhardt, Robin Cutshaw, K. Liedl, Robert J. Pappas, A. Grenier,
   Mark Stockton, David C. Niemi, Ben Craft, and many others who have helped

	   BusLogic MultiMaster and FlashPoint SCSI Driver for Linux

			 Version 2.0.15 for Linux 2.0
			 Version 2.1.15 for Linux 2.1

			      PRODUCTION RELEASE

				17 August 1998

			       Leonard N. Zubkoff
			       Dandelion Digital
			       lnz@dandelion.com

	 Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>


				 INTRODUCTION

BusLogic, Inc. designed and manufactured a variety of high performance SCSI
host adapters which share a common programming interface across a diverse
collection of bus architectures by virtue of their MultiMaster ASIC technology.
BusLogic was acquired by Mylex Corporation in February 1996, but the products
supported by this driver originated under the BusLogic name and so that name is
retained in the source code and documentation.

This driver supports all present BusLogic MultiMaster Host Adapters, and should
support any future MultiMaster designs with little or no modification.  More
recently, BusLogic introduced the FlashPoint Host Adapters, which are less
costly and rely on the host CPU, rather than including an onboard processor.
Despite not having an onboard CPU, the FlashPoint Host Adapters perform very
well and have very low command latency.  BusLogic has recently provided me with
the FlashPoint Driver Developer's Kit, which comprises documentation and freely
redistributable source code for the FlashPoint SCCB Manager.  The SCCB Manager
is the library of code that runs on the host CPU and performs functions
analogous to the firmware on the MultiMaster Host Adapters.  Thanks to their
having provided the SCCB Manager, this driver now supports the FlashPoint Host
Adapters as well.

My primary goals in writing this completely new BusLogic driver for Linux are
to achieve the full performance that BusLogic SCSI Host Adapters and modern
SCSI peripherals are capable of, and to provide a highly robust driver that can
be depended upon for high performance mission critical applications.  All of
the major performance and error recovery features can be configured from the
Linux kernel command line or at module initialization time, allowing individual
installations to tune driver performance and error recovery to their particular
needs.

The latest information on Linux support for BusLogic SCSI Host Adapters, as
well as the most recent release of this driver and the latest firmware for the
BT-948/958/958D, will always be available from my Linux Home Page at URL
"http://www.dandelion.com/Linux/".

Bug reports should be sent via electronic mail to "lnz@dandelion.com".  Please
include with the bug report the complete configuration messages reported by the
driver and SCSI subsystem at startup, along with any subsequent system messages
relevant to SCSI operations, and a detailed description of your system's
hardware configuration.

Mylex has been an excellent company to work with and I highly recommend their
products to the Linux community.  In November 1995, I was offered the
opportunity to become a beta test site for their latest MultiMaster product,
the BT-948 PCI Ultra SCSI Host Adapter, and then again for the BT-958 PCI Wide
Ultra SCSI Host Adapter in January 1996.  This was mutually beneficial since
Mylex received a degree and kind of testing that their own testing group cannot
readily achieve, and the Linux community has available high performance host
adapters that have been well tested with Linux even before being brought to
market.  This relationship has also given me the opportunity to interact
directly with their technical staff, to understand more about the internal
workings of their products, and in turn to educate them about the needs and
potential of the Linux community.

More recently, Mylex has reaffirmed the company's interest in supporting the
Linux community, and I am now working on a Linux driver for the DAC960 PCI RAID
Controllers.  Mylex's interest and support is greatly appreciated.

Unlike some other vendors, if you contact Mylex Technical Support with a
problem and are running Linux, they will not tell you that your use of their
products is unsupported.  Their latest product marketing literature even states
"Mylex SCSI host adapters are compatible with all major operating systems
including: ... Linux ...".

Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont, California
94555, USA and can be reached at 510/796-6100 or on the World Wide Web at
http://www.mylex.com.  Mylex HBA Technical Support can be reached by electronic
mail at techsup@mylex.com, by Voice at 510/608-2400, or by FAX at 510/745-7715.
Contact information for offices in Europe and Japan is available on the Web
site.


				DRIVER FEATURES

o Configuration Reporting and Testing

  During system initialization, the driver reports extensively on the host
  adapter hardware configuration, including the synchronous transfer parameters
  requested and negotiated with each target device.  AutoSCSI settings for
  Synchronous Negotiation, Wide Negotiation, and Disconnect/Reconnect are
  reported for each target device, as well as the status of Tagged Queuing and
  Error Recovery.  If the same setting is in effect for all target devices,
  then a single word or phrase is used; otherwise, a letter is provided for
  each target device to indicate the individual status.  The following examples
  should clarify this reporting format:

    Synchronous Negotiation: Ultra

      Synchronous negotiation is enabled for all target devices and the host
      adapter will attempt to negotiate for 20.0 mega-transfers/second.

    Synchronous Negotiation: Fast

      Synchronous negotiation is enabled for all target devices and the host
      adapter will attempt to negotiate for 10.0 mega-transfers/second.

    Synchronous Negotiation: Slow

      Synchronous negotiation is enabled for all target devices and the host
      adapter will attempt to negotiate for 5.0 mega-transfers/second.

    Synchronous Negotiation: Disabled

      Synchronous negotiation is disabled and all target devices are limited to
      asynchronous operation.

    Synchronous Negotiation: UFSNUUU#UUUUUUUU

      Synchronous negotiation to Ultra speed is enabled for target devices 0
      and 4 through 15, to Fast speed for target device 1, to Slow speed for
      target device 2, and is not permitted to target device 3.  The host
      adapter's SCSI ID is represented by the "#".

    The status of Wide Negotiation, Disconnect/Reconnect, and Tagged Queuing
    are reported as "Enabled", Disabled", or a sequence of "Y" and "N" letters.

    The Error Recovery option is reported as "Default", "Hard Reset",
    "Bus Device Reset", "None" or a sequence of "D", "H", "B", and "N" letters.

o Performance Features

  BusLogic SCSI Host Adapters directly implement SCSI-2 Tagged Queuing, and so
  support has been included in the driver to utilize tagged queuing with any
  target devices that report having the tagged queuing capability.  Tagged
  queuing allows for multiple outstanding commands to be issued to each target
  device or logical unit, and can improve I/O performance substantially.  In
  addition, BusLogic's Strict Round Robin Mode is used to optimize host adapter
  performance, and scatter/gather I/O can support as many segments as can be
  effectively utilized by the Linux I/O subsystem.  Control over the use of
  tagged queuing for each target device as well as individual selection of the
  tagged queue depth is available through driver options provided on the kernel
  command line or at module initialization time.  By default, the queue depth
  is determined automatically based on the host adapter's total queue depth and
  the number, type, speed, and capabilities of the target devices found.  In
  addition, tagged queuing is automatically disabled whenever the host adapter
  firmware version is known not to implement it correctly, or whenever a tagged
  queue depth of 1 is selected.  Tagged queuing is also disabled for individual
  target devices if disconnect/reconnect is disabled for that device.

o Robustness Features

  The driver implements extensive error recovery procedures.  When the higher
  level parts of the SCSI subsystem request that a timed out command be reset,
  a selection is made between a full host adapter hard reset and SCSI bus reset
  versus sending a bus device reset message to the individual target device
  based on the recommendation of the SCSI subsystem.  Error recovery strategies
  are selectable through driver options individually for each target device,
  and also include sending a bus device reset to the specific target device
  associated with the command being reset, as well as suppressing error
  recovery entirely to avoid perturbing an improperly functioning device.  If
  the bus device reset error recovery strategy is selected and sending a bus
  device reset does not restore correct operation, the next command that is
  reset will force a full host adapter hard reset and SCSI bus reset.  SCSI bus
  resets caused by other devices and detected by the host adapter are also
  handled by issuing a soft reset to the host adapter and re-initialization.
  Finally, if tagged queuing is active and more than one command reset occurs
  in a 10 minute interval, or if a command reset occurs within the first 10
  minutes of operation, then tagged queuing will be disabled for that target
  device.  These error recovery options improve overall system robustness by
  preventing individual errant devices from causing the system as a whole to
  lock up or crash, and thereby allowing a clean shutdown and restart after the
  offending component is removed.

o PCI Configuration Support

  On PCI systems running kernels compiled with PCI BIOS support enabled, this
  driver will interrogate the PCI configuration space and use the I/O port
  addresses assigned by the system BIOS, rather than the ISA compatible I/O
  port addresses.  The ISA compatible I/O port address is then disabled by the
  driver.  On PCI systems it is also recommended that the AutoSCSI utility be
  used to disable the ISA compatible I/O port entirely as it is not necessary.
  The ISA compatible I/O port is disabled by default on the BT-948/958/958D.

o /proc File System Support

  Copies of the host adapter configuration information together with updated
  data transfer and error recovery statistics are available through the
  /proc/scsi/BusLogic/<N> interface.

o Shared Interrupts Support

  On systems that support shared interrupts, any number of BusLogic Host
  Adapters may share the same interrupt request channel.


			    SUPPORTED HOST ADAPTERS

The following list comprises the supported BusLogic SCSI Host Adapters as of
the date of this document.  It is recommended that anyone purchasing a BusLogic
Host Adapter not in the following table contact the author beforehand to verify
that it is or will be supported.

FlashPoint Series PCI Host Adapters:

FlashPoint LT (BT-930)	Ultra SCSI-3
FlashPoint LT (BT-930R)	Ultra SCSI-3 with RAIDPlus
FlashPoint LT (BT-920)	Ultra SCSI-3 (BT-930 without BIOS)
FlashPoint DL (BT-932)	Dual Channel Ultra SCSI-3
FlashPoint DL (BT-932R)	Dual Channel Ultra SCSI-3 with RAIDPlus
FlashPoint LW (BT-950)	Wide Ultra SCSI-3
FlashPoint LW (BT-950R)	Wide Ultra SCSI-3 with RAIDPlus
FlashPoint DW (BT-952)	Dual Channel Wide Ultra SCSI-3
FlashPoint DW (BT-952R)	Dual Channel Wide Ultra SCSI-3 with RAIDPlus

MultiMaster "W" Series Host Adapters:

BT-948	    PCI		Ultra SCSI-3
BT-958	    PCI		Wide Ultra SCSI-3
BT-958D	    PCI		Wide Differential Ultra SCSI-3

MultiMaster "C" Series Host Adapters:

BT-946C	    PCI		Fast SCSI-2
BT-956C	    PCI		Wide Fast SCSI-2
BT-956CD    PCI		Wide Differential Fast SCSI-2
BT-445C	    VLB		Fast SCSI-2
BT-747C	    EISA	Fast SCSI-2
BT-757C	    EISA	Wide Fast SCSI-2
BT-757CD    EISA	Wide Differential Fast SCSI-2
BT-545C	    ISA		Fast SCSI-2
BT-540CF    ISA		Fast SCSI-2

MultiMaster "S" Series Host Adapters:

BT-445S	    VLB		Fast SCSI-2
BT-747S	    EISA	Fast SCSI-2
BT-747D	    EISA	Differential Fast SCSI-2
BT-757S	    EISA	Wide Fast SCSI-2
BT-757D	    EISA	Wide Differential Fast SCSI-2
BT-545S	    ISA		Fast SCSI-2
BT-542D	    ISA		Differential Fast SCSI-2
BT-742A	    EISA	SCSI-2 (742A revision H)
BT-542B	    ISA		SCSI-2 (542B revision H)

MultiMaster "A" Series Host Adapters:

BT-742A	    EISA	SCSI-2 (742A revisions A - G)
BT-542B	    ISA		SCSI-2 (542B revisions A - G)

AMI FastDisk Host Adapters that are true BusLogic MultiMaster clones are also
supported by this driver.

BusLogic SCSI Host Adapters are available packaged both as bare boards and as
retail kits.  The BT- model numbers above refer to the bare board packaging.
The retail kit model numbers are found by replacing BT- with KT- in the above
list.  The retail kit includes the bare board and manual as well as cabling and
driver media and documentation that are not provided with bare boards.


			 FLASHPOINT INSTALLATION NOTES

o RAIDPlus Support

  FlashPoint Host Adapters now include RAIDPlus, Mylex's bootable software
  RAID.  RAIDPlus is not supported on Linux, and there are no plans to support
  it.  The MD driver in Linux 2.0 provides for concatenation (LINEAR) and
  striping (RAID-0), and support for mirroring (RAID-1), fixed parity (RAID-4),
  and distributed parity (RAID-5) is available separately.  The built-in Linux
  RAID support is generally more flexible and is expected to perform better
  than RAIDPlus, so there is little impetus to include RAIDPlus support in the
  BusLogic driver.

o Enabling UltraSCSI Transfers

  FlashPoint Host Adapters ship with their configuration set to "Factory
  Default" settings that are conservative and do not allow for UltraSCSI speed
  to be negotiated.  This results in fewer problems when these host adapters
  are installed in systems with cabling or termination that is not sufficient
  for UltraSCSI operation, or where existing SCSI devices do not properly
  respond to synchronous transfer negotiation for UltraSCSI speed.  AutoSCSI
  may be used to load "Optimum Performance" settings which allow UltraSCSI
  speed to be negotiated with all devices, or UltraSCSI speed can be enabled on
  an individual basis.  It is recommended that SCAM be manually disabled after
  the "Optimum Performance" settings are loaded.


		      BT-948/958/958D INSTALLATION NOTES

The BT-948/958/958D PCI Ultra SCSI Host Adapters have some features which may
require attention in some circumstances when installing Linux.

o PCI I/O Port Assignments

  When configured to factory default settings, the BT-948/958/958D will only
  recognize the PCI I/O port assignments made by the motherboard's PCI BIOS.
  The BT-948/958/958D will not respond to any of the ISA compatible I/O ports
  that previous BusLogic SCSI Host Adapters respond to.  This driver supports
  the PCI I/O port assignments, so this is the preferred configuration.
  However, if the obsolete BusLogic driver must be used for any reason, such as
  a Linux distribution that does not yet use this driver in its boot kernel,
  BusLogic has provided an AutoSCSI configuration option to enable a legacy ISA
  compatible I/O port.

  To enable this backward compatibility option, invoke the AutoSCSI utility via
  Ctrl-B at system startup and select "Adapter Configuration", "View/Modify
  Configuration", and then change the "ISA Compatible Port" setting from
  "Disable" to "Primary" or "Alternate".  Once this driver has been installed,
  the "ISA Compatible Port" option should be set back to "Disable" to avoid
  possible future I/O port conflicts.  The older BT-946C/956C/956CD also have
  this configuration option, but the factory default setting is "Primary".

o PCI Slot Scanning Order

  In systems with multiple BusLogic PCI Host Adapters, the order in which the
  PCI slots are scanned may appear reversed with the BT-948/958/958D as
  compared to the BT-946C/956C/956CD.  For booting from a SCSI disk to work
  correctly, it is necessary that the host adapter's BIOS and the kernel agree
  on which disk is the boot device, which requires that they recognize the PCI
  host adapters in the same order.  The motherboard's PCI BIOS provides a
  standard way of enumerating the PCI host adapters, which is used by the Linux
  kernel.  Some PCI BIOS implementations enumerate the PCI slots in order of
  increasing bus number and device number, while others do so in the opposite
  direction.

  Unfortunately, Microsoft decided that Windows 95 would always enumerate the
  PCI slots in order of increasing bus number and device number regardless of
  the PCI BIOS enumeration, and requires that their scheme be supported by the
  host adapter's BIOS to receive Windows 95 certification.  Therefore, the
  factory default settings of the BT-948/958/958D enumerate the host adapters
  by increasing bus number and device number.  To disable this feature, invoke
  the AutoSCSI utility via Ctrl-B at system startup and select "Adapter
  Configuration", "View/Modify Configuration", press Ctrl-F10, and then change
  the "Use Bus And Device # For PCI Scanning Seq." option to OFF.

  This driver will interrogate the setting of the PCI Scanning Sequence option
  so as to recognize the host adapters in the same order as they are enumerated
  by the host adapter's BIOS.

o Enabling UltraSCSI Transfers

  The BT-948/958/958D ship with their configuration set to "Factory Default"
  settings that are conservative and do not allow for UltraSCSI speed to be
  negotiated.  This results in fewer problems when these host adapters are
  installed in systems with cabling or termination that is not sufficient for
  UltraSCSI operation, or where existing SCSI devices do not properly respond
  to synchronous transfer negotiation for UltraSCSI speed.  AutoSCSI may be
  used to load "Optimum Performance" settings which allow UltraSCSI speed to be
  negotiated with all devices, or UltraSCSI speed can be enabled on an
  individual basis.  It is recommended that SCAM be manually disabled after the
  "Optimum Performance" settings are loaded.


				DRIVER OPTIONS

BusLogic Driver Options may be specified either via the Linux Kernel Command
Line or via the Loadable Kernel Module Installation Facility.  Driver Options
for multiple host adapters may be specified either by separating the option
strings by a semicolon, or by specifying multiple "BusLogic=" strings on the
command line.  Individual option specifications for a single host adapter are
separated by commas.  The Probing and Debugging Options apply to all host
adapters whereas the remaining options apply individually only to the
selected host adapter.

The BusLogic Driver Probing Options comprise the following:

IO:<integer>

  The "IO:" option specifies an ISA I/O Address to be probed for a non-PCI
  MultiMaster Host Adapter.  If neither "IO:" nor "NoProbeISA" options are
  specified, then the standard list of BusLogic MultiMaster ISA I/O Addresses
  will be probed (0x330, 0x334, 0x230, 0x234, 0x130, and 0x134).  Multiple
  "IO:" options may be specified to precisely determine the I/O Addresses to
  be probed, but the probe order will always follow the standard list.

NoProbe

  The "NoProbe" option disables all probing and therefore no BusLogic Host
  Adapters will be detected.

NoProbeISA

  The "NoProbeISA" option disables probing of the standard BusLogic ISA I/O
  Addresses and therefore only PCI MultiMaster and FlashPoint Host Adapters
  will be detected.

NoProbePCI

  The "NoProbePCI" options disables the interrogation of PCI Configuration
  Space and therefore only ISA Multimaster Host Adapters will be detected, as
  well as PCI Multimaster Host Adapters that have their ISA Compatible I/O
  Port set to "Primary" or "Alternate".

NoSortPCI

  The "NoSortPCI" option forces PCI MultiMaster Host Adapters to be
  enumerated in the order provided by the PCI BIOS, ignoring any setting of
  the AutoSCSI "Use Bus And Device # For PCI Scanning Seq." option.

MultiMasterFirst

  The "MultiMasterFirst" option forces MultiMaster Host Adapters to be probed
  before FlashPoint Host Adapters.  By default, if both FlashPoint and PCI
  MultiMaster Host Adapters are present, this driver will probe for
  FlashPoint Host Adapters first unless the BIOS primary disk is controlled
  by the first PCI MultiMaster Host Adapter, in which case MultiMaster Host
  Adapters will be probed first.

FlashPointFirst

  The "FlashPointFirst" option forces FlashPoint Host Adapters to be probed
  before MultiMaster Host Adapters.

The BusLogic Driver Tagged Queuing Options allow for explicitly specifying
the Queue Depth and whether Tagged Queuing is permitted for each Target
Device (assuming that the Target Device supports Tagged Queuing).  The Queue
Depth is the number of SCSI Commands that are allowed to be concurrently
presented for execution (either to the Host Adapter or Target Device).  Note
that explicitly enabling Tagged Queuing may lead to problems; the option to
enable or disable Tagged Queuing is provided primarily to allow disabling
Tagged Queuing on Target Devices that do not implement it correctly.  The
following options are available:

QueueDepth:<integer>

  The "QueueDepth:" or QD:" option specifies the Queue Depth to use for all
  Target Devices that support Tagged Queuing, as well as the maximum Queue
  Depth for devices that do not support Tagged Queuing.  If no Queue Depth
  option is provided, the Queue Depth will be determined automatically based
  on the Host Adapter's Total Queue Depth and the number, type, speed, and
  capabilities of the detected Target Devices.  For Host Adapters that
  require ISA Bounce Buffers, the Queue Depth is automatically set by default
  to BusLogic_TaggedQueueDepthBB or BusLogic_UntaggedQueueDepthBB to avoid
  excessive preallocation of DMA Bounce Buffer memory.  Target Devices that
  do not support Tagged Queuing always have their Queue Depth set to
  BusLogic_UntaggedQueueDepth or BusLogic_UntaggedQueueDepthBB, unless a
  lower Queue Depth option is provided.  A Queue Depth of 1 automatically
  disables Tagged Queuing.

QueueDepth:[<integer>,<integer>...]

  The "QueueDepth:[...]" or "QD:[...]" option specifies the Queue Depth
  individually for each Target Device.  If an <integer> is omitted, the
  associated Target Device will have its Queue Depth selected automatically.

TaggedQueuing:Default

  The "TaggedQueuing:Default" or "TQ:Default" option permits Tagged Queuing
  based on the firmware version of the BusLogic Host Adapter and based on
  whether the Queue Depth allows queuing multiple commands.

TaggedQueuing:Enable

  The "TaggedQueuing:Enable" or "TQ:Enable" option enables Tagged Queuing for
  all Target Devices on this Host Adapter, overriding any limitation that
  would otherwise be imposed based on the Host Adapter firmware version.

TaggedQueuing:Disable

  The "TaggedQueuing:Disable" or "TQ:Disable" option disables Tagged Queuing
  for all Target Devices on this Host Adapter.

TaggedQueuing:<Target-Spec>

  The "TaggedQueuing:<Target-Spec>" or "TQ:<Target-Spec>" option controls
  Tagged Queuing individually for each Target Device.  <Target-Spec> is a
  sequence of "Y", "N", and "X" characters.  "Y" enables Tagged Queuing, "N"
  disables Tagged Queuing, and "X" accepts the default based on the firmware
  version.  The first character refers to Target Device 0, the second to
  Target Device 1, and so on; if the sequence of "Y", "N", and "X" characters
  does not cover all the Target Devices, unspecified characters are assumed
  to be "X".

The BusLogic Driver Error Recovery Option allows for explicitly specifying
the Error Recovery action to be performed when BusLogic_ResetCommand is
called due to a SCSI Command failing to complete successfully.  The following
options are available:

ErrorRecovery:Default

  The "ErrorRecovery:Default" or "ER:Default" option selects between the Hard
  Reset and Bus Device Reset options based on the recommendation of the SCSI
  Subsystem.

ErrorRecovery:HardReset

  The "ErrorRecovery:HardReset" or "ER:HardReset" option will initiate a Host
  Adapter Hard Reset which also causes a SCSI Bus Reset.

ErrorRecovery:BusDeviceReset

  The "ErrorRecovery:BusDeviceReset" or "ER:BusDeviceReset" option will send
  a Bus Device Reset message to the individual Target Device causing the
  error.  If Error Recovery is again initiated for this Target Device and no
  SCSI Command to this Target Device has completed successfully since the Bus
  Device Reset message was sent, then a Hard Reset will be attempted.

ErrorRecovery:None

  The "ErrorRecovery:None" or "ER:None" option suppresses Error Recovery.
  This option should only be selected if a SCSI Bus Reset or Bus Device Reset
  will cause the Target Device or a critical operation to suffer a complete
  and unrecoverable failure.

ErrorRecovery:<Target-Spec>

  The "ErrorRecovery:<Target-Spec>" or "ER:<Target-Spec>" option controls
  Error Recovery individually for each Target Device.  <Target-Spec> is a
  sequence of "D", "H", "B", and "N" characters.  "D" selects Default, "H"
  selects Hard Reset, "B" selects Bus Device Reset, and "N" selects None.
  The first character refers to Target Device 0, the second to Target Device
  1, and so on; if the sequence of "D", "H", "B", and "N" characters does not
  cover all the possible Target Devices, unspecified characters are assumed
  to be "D".

The BusLogic Driver Miscellaneous Options comprise the following:

BusSettleTime:<seconds>

  The "BusSettleTime:" or "BST:" option specifies the Bus Settle Time in
  seconds.  The Bus Settle Time is the amount of time to wait between a Host
  Adapter Hard Reset which initiates a SCSI Bus Reset and issuing any SCSI
  Commands.  If unspecified, it defaults to BusLogic_DefaultBusSettleTime.

InhibitTargetInquiry

  The "InhibitTargetInquiry" option inhibits the execution of an Inquire
  Target Devices or Inquire Installed Devices command on MultiMaster Host
  Adapters.  This may be necessary with some older Target Devices that do not
  respond correctly when Logical Units above 0 are addressed.

The BusLogic Driver Debugging Options comprise the following:

TraceProbe

  The "TraceProbe" option enables tracing of Host Adapter Probing.

TraceHardwareReset

  The "TraceHardwareReset" option enables tracing of Host Adapter Hardware
  Reset.

TraceConfiguration

  The "TraceConfiguration" option enables tracing of Host Adapter
  Configuration.

TraceErrors

  The "TraceErrors" option enables tracing of SCSI Commands that return an
  error from the Target Device.  The CDB and Sense Data will be printed for
  each SCSI Command that fails.

Debug

  The "Debug" option enables all debugging options.

The following examples demonstrate setting the Queue Depth for Target Devices
1 and 2 on the first host adapter to 7 and 15, the Queue Depth for all Target
Devices on the second host adapter to 31, and the Bus Settle Time on the
second host adapter to 30 seconds.

Linux Kernel Command Line:

  linux BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30

LILO Linux Boot Loader (in /etc/lilo.conf):

  append = "BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30"

INSMOD Loadable Kernel Module Installation Facility:

  insmod BusLogic.o \
      'BusLogic_Options="QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30"'

NOTE: Module Utilities 2.1.71 or later is required for correct parsing
      of driver options containing commas.


			      DRIVER INSTALLATION

This distribution was prepared for Linux kernel version 2.0.35, but should be
compatible with 2.0.4 or any later 2.0 series kernel.

To install the new BusLogic SCSI driver, you may use the following commands,
replacing "/usr/src" with wherever you keep your Linux kernel source tree:

  cd /usr/src
  tar -xvzf BusLogic-2.0.15.tar.gz
  mv README.* LICENSE.* BusLogic.[ch] FlashPoint.c linux/drivers/scsi
  patch -p0 < BusLogic.patch (only for 2.0.33 and below)
  cd linux
  make config
  make depend
  make zImage

Then install "arch/i386/boot/zImage" as your standard kernel, run lilo if
appropriate, and reboot.


		      BUSLOGIC ANNOUNCEMENTS MAILING LIST

The BusLogic Announcements Mailing List provides a forum for informing Linux
users of new driver releases and other announcements regarding Linux support
for BusLogic SCSI Host Adapters.  To join the mailing list, send a message to
"buslogic-announce-request@dandelion.com" with the line "subscribe" in the
message body.

The BusLogic FlashPoint SCSI Host Adapters are now fully supported on Linux.
The upgrade program described below has been officially terminated effective
31 March 1997 since it is no longer needed.



	  MYLEX INTRODUCES LINUX OPERATING SYSTEM SUPPORT FOR ITS
	      BUSLOGIC FLASHPOINT LINE OF SCSI HOST ADAPTERS


FREMONT, CA, -- October 8, 1996 -- Mylex Corporation has expanded Linux
operating system support to its BusLogic brand of FlashPoint Ultra SCSI
host adapters.  All of BusLogic's other SCSI host adapters, including the
MultiMaster line, currently support the Linux operating system.  Linux
drivers and information will be available on October 15th at
http://www.dandelion.com/Linux/.

"Mylex is committed to supporting the Linux community," says Peter Shambora,
vice president of marketing for Mylex.  "We have supported Linux driver
development and provided technical support for our host adapters for several
years, and are pleased to now make our FlashPoint products available to this
user base."

The Linux Operating System

Linux is a freely-distributed implementation of UNIX for Intel x86, Sun
SPARC, SGI MIPS, Motorola 68k, Digital Alpha AXP and Motorola PowerPC
machines.  It supports a wide range of software, including the X Window
System, Emacs, and TCP/IP networking.  Further information is available at
http://www.linux.org and http://www.ssc.com/linux.

FlashPoint Host Adapters

The FlashPoint family of Ultra SCSI host adapters, designed for workstation
and file server environments, are available in narrow, wide, dual channel,
and dual channel wide versions.  These adapters feature SeqEngine
automation technology, which minimizes SCSI command overhead and reduces
the number of interrupts generated to the CPU.

About Mylex

Mylex Corporation (NASDAQ/NM SYMBOL: MYLX), founded in 1983, is a leading
producer of RAID technology and network management products.  The company
produces high performance disk array (RAID) controllers, and complementary
computer products for network servers, mass storage systems, workstations
and system boards.  Through its wide range of RAID controllers and its
BusLogic line of Ultra SCSI host adapter products, Mylex provides enabling
intelligent I/O technologies that increase network management control,
enhance CPU utilization, optimize I/O performance, and ensure data security
and availability.  Products are sold globally through a network of OEMs,
major distributors, VARs, and system integrators.  Mylex Corporation is
headquartered at 34551 Ardenwood Blvd., Fremont, CA.

				   ####

Contact:

Peter Shambora
Vice President of Marketing
Mylex Corp.
510/796-6100
peters@mylex.com

			       ANNOUNCEMENT
	       BusLogic FlashPoint LT/BT-948 Upgrade Program
			      1 February 1996

			  ADDITIONAL ANNOUNCEMENT
	       BusLogic FlashPoint LW/BT-958 Upgrade Program
			       14 June 1996

Ever since its introduction last October, the BusLogic FlashPoint LT has
been problematic for members of the Linux community, in that no Linux
drivers have been available for this new Ultra SCSI product.  Despite it's
officially being positioned as a desktop workstation product, and not being
particularly well suited for a high performance multitasking operating
system like Linux, the FlashPoint LT has been touted by computer system
vendors as the latest thing, and has been sold even on many of their high
end systems, to the exclusion of the older MultiMaster products.  This has
caused grief for many people who inadvertently purchased a system expecting
that all BusLogic SCSI Host Adapters were supported by Linux, only to
discover that the FlashPoint was not supported and would not be for quite
some time, if ever.

After this problem was identified, BusLogic contacted its major OEM
customers to make sure the BT-946C/956C MultiMaster cards would still be
made available, and that Linux users who mistakenly ordered systems with
the FlashPoint would be able to upgrade to the BT-946C.  While this helped
many purchasers of new systems, it was only a partial solution to the
overall problem of FlashPoint support for Linux users.  It did nothing to
assist the people who initially purchased a FlashPoint for a supported
operating system and then later decided to run Linux, or those who had
ended up with a FlashPoint LT, believing it was supported, and were unable
to return it.

In the middle of December, I asked to meet with BusLogic's senior
management to discuss the issues related to Linux and free software support
for the FlashPoint.  Rumors of varying accuracy had been circulating
publicly about BusLogic's attitude toward the Linux community, and I felt
it was best that these issues be addressed directly.  I sent an email
message after 11pm one evening, and the meeting took place the next
afternoon.  Unfortunately, corporate wheels sometimes grind slowly,
especially when a company is being acquired, and so it's taken until now
before the details were completely determined and a public statement could
be made.

BusLogic is not prepared at this time to release the information necessary
for third parties to write drivers for the FlashPoint.  The only existing
FlashPoint drivers have been written directly by BusLogic Engineering, and
there is no FlashPoint documentation sufficiently detailed to allow outside
developers to write a driver without substantial assistance.  While there
are people at BusLogic who would rather not release the details of the
FlashPoint architecture at all, that debate has not yet been settled either
way.  In any event, even if documentation were available today it would
take quite a while for a usable driver to be written, especially since I'm
not convinced that the effort required would be worthwhile.

However, BusLogic does remain committed to providing a high performance
SCSI solution for the Linux community, and does not want to see anyone left
unable to run Linux because they have a Flashpoint LT.  Therefore, BusLogic
has put in place a direct upgrade program to allow any Linux user worldwide
to trade in their FlashPoint LT for the new BT-948 MultiMaster PCI Ultra
SCSI Host Adapter.  The BT-948 is the Ultra SCSI successor to the BT-946C
and has all the best features of both the BT-946C and FlashPoint LT,
including smart termination and a flash PROM for easy firmware updates, and
is of course compatible with the present Linux driver.  The price for this
upgrade has been set at US $45 plus shipping and handling, and the upgrade
program will be administered through BusLogic Technical Support, which can
be reached by electronic mail at techsup@buslogic.com, by Voice at +1 408
654-0760, or by FAX at +1 408 492-1542.

As of 14 June 1996, the original BusLogic FlashPoint LT to BT-948 upgrade
program has now been extended to encompass the FlashPoint LW Wide Ultra
SCSI Host Adapter.  Any Linux user worldwide may trade in their FlashPoint
LW (BT-950) for a BT-958 MultiMaster PCI Ultra SCSI Host Adapter.  The
price for this upgrade has been set at US $65 plus shipping and handling.

I was a beta test site for the BT-948/958, and versions 1.2.1 and 1.3.1 of
my BusLogic driver already included latent support for the BT-948/958.
Additional cosmetic support for the Ultra SCSI MultiMaster cards was added
subsequent releases.  As a result of this cooperative testing process,
several firmware bugs were found and corrected.  My heavily loaded Linux
test system provided an ideal environment for testing error recovery
processes that are much more rarely exercised in production systems, but
are crucial to overall system stability.  It was especially convenient
being able to work directly with their firmware engineer in demonstrating
the problems under control of the firmware debugging environment; things
sure have come a long way since the last time I worked on firmware for an
embedded system.  I am presently working on some performance testing and
expect to have some data to report in the not too distant future.

BusLogic asked me to send this announcement since a large percentage of the
questions regarding support for the FlashPoint have either been sent to me
directly via email, or have appeared in the Linux newsgroups in which I
participate.  To summarize, BusLogic is offering Linux users an upgrade
from the unsupported FlashPoint LT (BT-930) to the supported BT-948 for US
$45 plus shipping and handling, or from the unsupported FlashPoint LW
(BT-950) to the supported BT-958 for $65 plus shipping and handling.
Contact BusLogic Technical Support at techsup@buslogic.com or +1 408
654-0760 to take advantage of their offer.

		Leonard N. Zubkoff
		lnz@dandelion.com

Please see the file README.BusLogic for information about Linux support for
Mylex (formerly BusLogic) MultiMaster and FlashPoint SCSI Host Adapters.

The Mylex DAC960 PCI RAID Controllers are now supported.  Please consult
http://www.dandelion.com/Linux/ for further information on the DAC960 driver.

$Id: README.aha152x,v 1.2 1999/12/25 15:32:30 fischer Exp fischer $
Adaptec AHA-1520/1522 SCSI driver for Linux (aha152x)

Copyright 1993-1999 J�rgen Fischer <fischer@norbit.de>
TC1550 patches by Luuk van Dijk (ldz@xs4all.nl)


In Revision 2 the driver was modified a lot (especially the
bottom-half handler complete()).

The driver is much cleaner now, has support for the new
error handling code in 2.3, produced less cpu load (much
less polling loops), has slightly higher throughput (at
least on my ancient test box; a i486/33Mhz/20MB).


CONFIGURATION ARGUMENTS:

IOPORT        base io address                           (0x340/0x140)
IRQ           interrupt level                           (9-12; default 11)
SCSI_ID       scsi id of controller                     (0-7; default 7)
RECONNECT     allow targets to disconnect from the bus  (0/1; default 1 [on])
PARITY        enable parity checking                    (0/1; default 1 [on])
SYNCHRONOUS   enable synchronous transfers              (0/1; default 1 [on])
DELAY:        bus reset delay                           (default 100)
EXT_TRANS:    enable extended translation               (0/1: default 0 [off])
              (see NOTES)

COMPILE TIME CONFIGURATION (go into AHA152X in drivers/scsi/Makefile):

-DAUTOCONF
 use configuration the controller reports (AHA-152x only)

-DSKIP_BIOSTEST
 Don't test for BIOS signature (AHA-1510 or disabled BIOS)

-DSETUP0="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }"
 override for the first controller

-DSETUP1="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }"
 override for the second controller

-DAHA152X_DEBUG
 enable debugging output

-DAHA152X_STAT
 enable some statistics


LILO COMMAND LINE OPTIONS:

aha152x=<IOPORT>[,<IRQ>[,<SCSI-ID>[,<RECONNECT>[,<PARITY>[,<SYNCHRONOUS>[,<DELAY> [,<EXT_TRANS]]]]]]]

 The normal configuration can be overridden by specifying a command line.
 When you do this, the BIOS test is skipped. Entered values have to be
 valid (known).  Don't use values that aren't supported under normal
 operation.  If you think that you need other values: contact me.
 For two controllers use the aha152x statement twice.


SYMBOLS FOR MODULE CONFIGURATION:

Choose from 2 alternatives:

1. specify everything (old)

aha152x=IOPORT,IRQ,SCSI_ID,RECONNECT,PARITY,SYNCHRONOUS,DELAY,EXT_TRANS
  configuration override for first controller


aha152x1=IOPORT,IRQ,SCSI_ID,RECONNECT,PARITY,SYNCHRONOUS,DELAY,EXT_TRANS
  configuration override for second controller

2. specify only what you need to (irq or io is required; new)

io=IOPORT0[,IOPORT1]
  IOPORT for first and second controller

irq=IRQ0[,IRQ1]
  IRQ for first and second controller

scsiid=SCSIID0[,SCSIID1]
  SCSIID for first and second controller

reconnect=RECONNECT0[,RECONNECT1]
  allow targets to disconnect for first and second controller

parity=PAR0[PAR1]
  use parity for first and second controller

sync=SYNCHRONOUS0[,SYNCHRONOUS1]
  enable synchronous transfers for first and second controller

delay=DELAY0[,DELAY1]
  reset DELAY for first and second controller

exttrans=EXTTRANS0[,EXTTRANS1]
  enable extended translation for first and second controller


If you use both alternatives the first will be taken.


NOTES ON EXT_TRANS:

SCSI uses block numbers to address blocks/sectors on a device.
The BIOS uses a cylinder/head/sector addressing scheme (C/H/S)
scheme instead.  DOS expects a BIOS or driver that understands this
C/H/S addressing.

The number of cylinders/heads/sectors is called geometry and is required
as base for requests in C/H/S addressing.  SCSI only knows about the
total capacity of disks in blocks (sectors).

Therefore the SCSI BIOS/DOS driver has to calculate a logical/virtual
geometry just to be able to support that addressing scheme.  The geometry
returned by the SCSI BIOS is a pure calculation and has nothing to
do with the real/physical geometry of the disk (which is usually
irrelevant anyway).

Basically this has no impact at all on Linux, because it also uses block
instead of C/H/S addressing.  Unfortunately C/H/S addressing is also used
in the partition table and therefore every operating system has to know
the right geometry to be able to interpret it.

Moreover there are certain limitations to the C/H/S addressing scheme,
namely the address space is limited to upto 255 heads, upto 63 sectors
and a maximum of 1023 cylinders.

The AHA-1522 BIOS calculates the geometry by fixing the number of heads
to 64, the number of sectors to 32 and by calculating the number of
cylinders by dividing the capacity reported by the disk by 64*32 (1 MB).
This is considered to be the default translation.

With respect to the limit of 1023 cylinders using C/H/S you can only
address the first GB of your disk in the partition table.  Therefore
BIOSes of some newer controllers based on the AIC-6260/6360 support
extended translation.  This means that the BIOS uses 255 for heads,
63 for sectors and then divides the capacity of the disk by 255*63
(about 8 MB), as soon it sees a disk greater than 1 GB.  That results
in a maximum of about 8 GB addressable diskspace in the partition table
(but there are already bigger disks out there today).

To make it even more complicated the translation mode might/might
not be configurable in certain BIOS setups.

This driver does some more or less failsafe guessing to get the
geometry right in most cases:

- for disks<1GB: use default translation (C/32/64)

- for disks>1GB:
  - take current geometry from the partition table
    (using scsicam_bios_param and accept only `valid' geometries,
    ie. either (C/32/64) or (C/63/255)).  This can be extended translation
    even if it's not enabled in the driver.

  - if that fails, take extended translation if enabled by override,
    kernel or module parameter, otherwise take default translation and
    ask the user for verification.  This might on not yet partitioned
    disks.


REFERENCES USED:

 "AIC-6260 SCSI Chip Specification", Adaptec Corporation.

 "SCSI COMPUTER SYSTEM INTERFACE - 2 (SCSI-2)", X3T9.2/86-109 rev. 10h

 "Writing a SCSI device driver for Linux", Rik Faith (faith@cs.unc.edu)

 "Kernel Hacker's Guide", Michael K. Johnson (johnsonm@sunsite.unc.edu)

 "Adaptec 1520/1522 User's Guide", Adaptec Corporation.

 Michael K. Johnson (johnsonm@sunsite.unc.edu)

 Drew Eckhardt (drew@cs.colorado.edu)

 Eric Youngdale (eric@andante.org)

 special thanks to Eric Youngdale for the free(!) supplying the
 documentation on the chip.

			    AIC7xxx Driver for Linux

Introduction
----------------------------
The AIC7xxx SCSI driver adds support for Adaptec (http://www.adaptec.com)
SCSI controllers and chipsets. Major portions of the driver and driver
development are shared between both Linux and FreeBSD. Support for the
AIC-7xxx chipsets have been in the default Linux kernel since approximately
linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
2.1.0 or later.

  Supported cards/chipsets
  ----------------------------
    Adaptec Cards
    ----------------------------
    AHA-274x
    AHA-274xT
    AHA-274xW
    AHA-284x
    AHA-284xW
    All PCI based cards using any of the chipsets listed under motherboard
    chipsets.  In general, this means *all* of the Adaptec SCSI controllers
    except the ones specifically excluded later on in this document.

    Motherboard Chipsets
    ----------------------------
    AIC-777x
    AIC-785x
    AIC-786x
    AIC-787x
    AIC-788x
    AIC-789x
    AIC-3860

    Bus Types
    ----------------------------
    W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support
        SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s.
    U - Ultra SCSI, transfer rates up to 40MB/s.
    U2- Ultra 2 SCSI, transfer rates up to 80MB/s.
    U3- Ultra 3 SCSI, transfer rates up to 160MB/s.
    D - Differential SCSI.
    T - Twin Channel SCSI. Up to 14 SCSI devices.

    AHA-274x - EISA SCSI controller
    AHA-284x - VLB SCSI controller
    AHA-29xx - PCI SCSI controller
    AHA-39xx - PCI controllers with multiple separate SCSI channels on-board.

  Not Supported Devices
  ------------------------------
    Adaptec Cards
    ----------------------------
    AHA-2920 (Only the cards that use the Future Domain chipset are not
              supported, any 2920 cards based on Adaptec AIC chipsets,
	      such as the 2920C, are supported)
    AAA-13x Raid Adapters
    AAA-113x Raid Port Card

    Motherboard Chipsets
    ----------------------------
    AIC-781x

    Bus Types
    ----------------------------
    R - Raid Port busses are not supported.

    The hardware RAID devices sold by Adaptec are *NOT* supported by this
    driver (and will people please stop emailing me about them, they are
    a totally separate beast from the bare SCSI controllers and this driver
    can not be retrofitted in any sane manner to support the hardware RAID
    features on those cards - Doug Ledford).


  People
  ------------------------------
    Justin T Gibbs  gibbs@plutotech.com
      (BSD Driver Author)
    Dan Eischen     deischen@iworks.InterWorks.org
      (Original Linux Driver Co-maintainer)
    Dean Gehnert    deang@teleport.com
      (Original Linux FTP/patch maintainer)
    Jess Johnson    jester@frenzy.com
      (AIC7xxx FAQ author)
    Doug Ledford    dledford@redhat.com
      (Current Linux aic7xxx-5.x.x Driver/Patch/FTP maintainer)

    Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original
    author of the driver. John has since retired from the project. Thanks
    again for all his work!

  Mailing list
  ------------------------------
    There is a mailing list available for users who want to track development
    and converse with other users and developers. This list is for both
    FreeBSD and Linux support of the AIC7xxx chipsets.

    To subscribe to the AIC7xxx mailing list send mail to the list server,
    with "subscribe AIC7xxx" in the body (no Subject: required):
        To: majordomo@FreeBSD.ORG
        ---
        subscribe AIC7xxx

    To unsubscribe from the list, send mail to the list server with:
        To: majordomo@FreeBSD.ORG
        ---
        unsubscribe AIC7xxx

    Send regular messages and replies to: AIC7xxx@FreeBSD.ORG

  Boot Command line options
  ------------------------------
    "aic7xxx=no_reset" -  Eliminate the SCSI bus reset during startup.
        Some SCSI devices need the initial reset that this option disables
	in order to work.  If you have problems at bootup, please make sure
	you aren't using this option.

    "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at
        bootup by scanning from the highest numbered PCI device to the
	lowest numbered PCI device, others do just the opposite and scan
	from lowest to highest numbered PCI device.  There is no reliable
	way to autodetect this ordering.  So, we default to the most common
	order, which is lowest to highest.  Then, in case your motherboard
	scans from highest to lowest, we have this option.  If your BIOS
	finds the drives on controller A before controller B but the linux
	kernel finds your drives on controller B before A, then you should
	use this option.

    "aic7xxx=extended" - Force the driver to detect extended drive translation
        on your controller.  This helps those people who have cards without
        a SEEPROM make sure that linux and all other operating systems think
        the same way about your hard drives.

    "aic7xxx=scbram" - Some cards have external SCB RAM that can be used to
        give the card more hardware SCB slots.  This allows the driver to use
	that SCB RAM.  Without this option, the driver won't touch the SCB
	RAM because it is known to cause problems on a few cards out there
	(such as 3985 class cards).

    "aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel
        to use the correct IRQ type for your card.  This only applies to EISA
        based controllers.  On these controllers, 0 is for Edge triggered
        interrupts, and 1 is for Level triggered interrupts.  If you aren't
        sure or don't know which IRQ trigger type your EISA card uses, then
        let the kernel autodetect the trigger type.

    "aic7xxx=verbose" - This option can be used in one of two ways.  If you
        simply specify aic7xxx=verbose, then the kernel will automatically
	pick the default set of verbose messages for you to see.
	Alternatively, you can specify the command as
	"aic7xxx=verbose:0xXXXX" where the X entries are replaced with
	hexadecimal digits.  This option is a bit field type option.  For
	a full listing of the available options, search for the
	#define VERBOSE_xxxxxx lines in the aic7xxx.c file.  If you want
	verbose messages, then it is recommended that you simply use the
	aic7xxx=verbose variant of this command.

    "aic7xxx=pci_parity:x" - This option controls whether or not the driver
        enables PCI parity error checking on the PCI bus.  By default, this
        checking is disabled.  To enable the checks, simply specify pci_parity
        with no value afterwords.  To reverse the parity from even to odd,
        supply any number other than 0 or 255.  In short:
          pci_parity     - Even parity checking (even is the normal PCI parity)
          pci_parity:x   - Where x > 0, Odd parity checking
          pci_parity:0   - No check (default)
        NOTE: In order to get Even PCI parity checking, you must use the
        version of the option that does not include the : and a number at
        the end (unless you want to enter exactly 2^32 - 1 as the number).

    "aic7xxx=no_probe" - This option will disable the probing for any VLB
        based 2842 controllers and any EISA based controllers.  This is
	needed on certain newer motherboards where the normal EISA I/O ranges
	have been claimed by other PCI devices.  Probing on those machines
	will often result in the machine crashing or spontaneously rebooting
	during startup.  Examples of machines that need this are the
	Dell PowerEdge 6300 machines.

    "aic7xxx=seltime:2" - This option controls how long the card waits
        during a device selection sequence for the device to respond.
	The original SCSI spec says that this "should be" 256ms.  This
	is generally not required with modern devices.  However, some
	very old SCSI I devices need the full 256ms.  Most modern devices
	can run fine with only 64ms.  The default for this option is
	64ms.  If you need to change this option, then use the following
	table to set the proper value in the example above:
	  0  -  256ms
	  1  -  128ms
	  2  -   64ms
	  3  -   32ms

    "aic7xxx=panic_on_abort" - This option is for debugging and will cause
        the driver to panic the linux kernel and freeze the system the first
	time the drivers abort or reset routines are called.  This is most
	helpful when some problem causes infinite reset loops that scroll too
	fast to see.  By using this option, you can write down what the errors
	actually are and send that information to me so it can be fixed.

    "aic7xxx=dump_card" - This option will print out the *entire* set of
        configuration registers on the card during the init sequence.  This
	is a debugging aid used to see exactly what state the card is in
	when we finally finish our initialization routines.  If you don't
	have documentation on the chipsets, this will do you absolutely
	no good unless you are simply trying to write all the information
	down in order to send it to me.

    "aic7xxx=dump_sequencer" - This is the same as the above options except
        that instead of dumping the register contents on the card, this
	option dumps the contents of the sequencer program RAM.  This gives
	the ability to verify that the instructions downloaded to the
	card's sequencer are indeed what they are suppossed to be.  Again,
	unless you have documentation to tell you how to interpret these
	numbers, then it is totally useless.

    "aic7xxx=override_term:0xffffffff" - This option is used to force the
    	termination on your SCSI controllers to a particular setting.  This
	is a bit mask variable that applies for up to 8 aic7xxx SCSI channels.
	Each channel gets 4 bits, divided as follows:
	bit   3   2   1   0
	      |   |   |   Enable/Disable Single Ended Low Byte Termination
	      |   |   En/Disable Single Ended High Byte Termination
	      |   En/Disable Low Byte LVD Termination
	      En/Disable High Byte LVD Termination

	The upper 2 bits that deal with LVD termination only apply to Ultra2
	controllers.  Futhermore, due to the current Ultra2 controller
	designs, these bits are tied together such that setting either bit
	enables both low and high byte LVD termination.  It is not possible
	to only set high or low byte LVD termination in this manner.  This is
	an artifact of the BIOS definition on Ultra2 controllers.  For other
	controllers, the only important bits are the two lowest bits.  Setting
	the higher bits on non-Ultra2 controllers has no effect.  A few
	examples of how to use this option:

	Enable low and high byte termination on a non-ultra2 controller that
	is the first aic7xxx controller (the correct bits are 0011),
	aic7xxx=override_term:0x3

	Enable all termination on the third aic7xxx controller, high byte
	termination on the second aic7xxx controller, and low and high byte
	SE termination on the first aic7xxx controller
	(bits are 1111 0010 0011),
	aic7xxx=override_term:0xf23

	No attempt has been made to make this option non-cryptic.  It really
	shouldn't be used except in dire circumstances, and if that happens,
	I'm probably going to be telling you what to set this to anyway :)

    "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV
        bit in the DEVCONFIG PCI register.  Currently, this is one of the
	very few registers that we have absolutely *no* way of detecting
	what the variable should be.  It depends entirely on how the chipset
	and external terminators were coupled by the card/motherboard maker.
	Further, a chip reset (at power up) always sets this bit to 0.  If
	there is no BIOS to run on the chipset/card (such as with a 2910C
	or a motherboard controller with the BIOS totally disabled) then
	the variable may not get set properly.  Of course, if the proper
	setting was 0, then that's what it would be after the reset, but if
	the proper setting is actually 1.....you get the picture.  Now, since
	we can't detect this at all, I've added this option to force the
	setting.  If you have a BIOS on your controller then you should never
	need to use this option.  However, if you are having lots of SCSI
	reset problems and can't seem to get them knocked out, this may help.

	Here's a test to know for certain if you need this option.  Make
	a boot floppy that you can use to boot your computer up and that
	will detect the aic7xxx controller.  Next, power down your computer.
	While it's down, unplug all SCSI cables from your Adaptec SCSI
	controller.  Boot the system back up to the Adaptec EZ-SCSI BIOS
	and then make sure that termination is enabled on your adapter (if
	you have an Adaptec BIOS of course).  Next, boot up the floppy you
	made and wait for it to detect the aic7xxx controller.  If the kernel
	finds the controller fine, says scsi : x hosts and then tries to
	detect your devices like normal, up to the point where it fails to
	mount your root file system and panics, then you're fine.  If, on
	the other hand, the system goes into an infinite reset loop, then
	you need to use this option and/or the previous option to force the
	proper termination settings on your controller.   If this happens,
	then you next need to figure out what your settings should be.

	To find the correct settings, power your machine back down, connect
	back up the SCSI cables, and boot back into your machine like normal.
	However, boot with the aic7xxx=verbose:0x39 option.  Record the
	initial DEVCONFIG values for each of your aic7xxx controllers as
	they are listed, and also record what the machine is detecting as
	the proper termination on your controllers.  NOTE: the order in
	which the initial DEVCONFIG values are printed out is not gauranteed
	to be the same order as the SCSI controllers are registered.  The
	above option and this option both work on the order of the SCSI
	controllers as they are registered, so make sure you match the right
	DEVCONFIG values with the right controllers if you have more than
	one aic7xxx controller.

	Once you have the detected termination settings and the initial
	DEVCONFIG values for each controller, then figure out what the
	termination on each of the controllers *should* be.  Hopefully, that
	part is correct, but it could possibly be wrong if there is
	bogus cable detection logic on your controller or something similar.
	If all the controllers have the correct termination settings, then
	don't set the aic7xxx=override_term variable at all, leave it alone.
	Next, on any controllers that go into an infinite reset loop when
	you unplug all the SCSI cables, get the starting DEVCONFIG value.
	If the initial DEVCONFIG value is divisible by 2, then the correct
	setting for that controller is 0.  If it's an odd number, then
	the correct setting for that controller is 1.  For any other
	controllers that didn't have an infinite reset problem, then reverse
	the above options.  If DEVCONFIG was even, then the correct setting
	is 1, if not then the correct setting is 0.

	Now that you know what the correct setting was for each controller,
	we need to encode that into the aic7xxx=stpwlev:0x... variable.
	This variable is a bit field encoded variable.  Bit 0 is for the first
	aic7xxx controller, bit 1 for the next, etc.  Put all these bits
	together and you get a number.  For example, if the third aic7xxx
	needed a 1, but the second and first both needed a 0, then the bits
	would be 100 in binary.  This then translates to 0x04.  You would
	therefore set aic7xxx=stpwlev:0x04.  This is fairly standard binary
	to hexadecimal conversions here.  If you aren't up to speed on the
	binary->hex conversion then send an email to the aic7xxx mailing
	list and someone can help you out.

    "aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to disable
        or enable Tagged Command Queueing (TCQ) on specific devices.  As of
	driver version 5.1.11, TCQ is now either on or off by default
	according to the setting you choose during the make config process.
	In order to en/disable TCQ for certian devices at boot time, a user
	may use this boot param.  The driver will then parse this message out
        and en/disable the specific device entries that are present based upon
        the value given.  The param line is parsed in the following manner:

          { - first instance indicates the start of this parameter values
              second instance is the start of entries for a particular
              device entry
          } - end the entries for a particular host adapter, or end the entire
              set of parameter entries
          , - move to next entry.  Inside of a set of device entries, this
              moves us to the next device on the list.  Outside of device
              entries, this moves us to the next host adapter
          . - Same effect as , but is safe to use with insmod.
          x - the number to enter into the array at this position.
              0 = Enable tagged queueing on this device and use the default
                  queue depth
              1-254 = Enable tagged queueing on this device and use this
                      number as the queue depth
              255 = Disable tagged queueing on this device.
              Note: anything above 32 for an actual queue depth is wasteful
                    and not recommended.

        A few examples of how this can be used:

        tag_info:{{8,12,,0,,255,4}}
          This line will only effect the first aic7xxx card registered.  It
          will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2
          at the default, set id 3 to tagged queueing enabled and use the
          default queue depth, id 4 default, id 5 disabled, and id 6 to 4.
          Any not specified entries stay at the default value, repeated
          commas with no value specified will simply increment to the next id
          without changing anything for the missing values.

        tag_info:{,,,{,,,255}}
          First, second, and third adapters at default values.  Fourth
          adapter, id 3 is disabled.  Notice that leading commas simply
	  increment what the first number effects, and there are no need
	  for trailing commas.  When you close out an adapter, or the
	  entire entry, anything not explicitly set stays at the default
	  value.

        A final note on this option.  The scanner I used for this isn't
        perfect or highly robust.  If you mess the line up, the worst that
        should happen is that the line will get ignored.  If you don't
        close out the entire entry with the final bracket, then any other
        aic7xxx options after this will get ignored.  So, in general, be
        sure of what you are entering, and after you have it right, just
        add it to the lilo.conf file so there won't be any mistakes.  As
        a means of checking this parser, the entire tag_info array for
        each card is now printed out in the /proc/scsi/aic7xxx/x file.  You
        can use that to verify that your options were parsed correctly.

    Boot command line options may be combined to form the proper set of options
    a user might need.  For example, the following is valid:

    aic7xxx=verbose,extended,irq_trigger:1

    The only requirement is that individual options be separated by a comma or
    a period on the command line.

  Module Loading command options
  ------------------------------
    When loading the aic7xxx driver as a module, the exact same options are
    available to the user.  However, the syntax to specify the options changes
    slightly.  For insmod, you need to wrap the aic7xxx= argument in quotes
    and replace all ',' with '.'.  So, for example, a valid insmod line
    would be:

    insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended'

    This line should result in the *exact* same behaviour as if you typed
    it in at the lilo prompt and the driver was compiled into the kernel
    instead of being a module.  The reason for the single quote is so that
    the shell won't try to interpret anything in the line, such as {.
    Insmod assumes any options starting with a letter instead of a number
    is a character string (which is what we want) and by switching all of
    the commas to periods, insmod won't interpret this as more than one
    string and write junk into our binary image.  I consider it a bug in
    the insmod program that even if you wrap your string in quotes (quotes
    that pass the shell mind you and that insmod sees) it still treates
    a comma inside of those quotes as starting a new variable, resulting
    in memory scribbles if you don't switch the commas to periods.


  Kernel Compile options
  ------------------------------
    The various kernel compile time options for this driver are now fairly
    well documented in the file Documentation/Configure.help.  In order to
    see this documentation, you need to use one of the advanced configuration
    programs (menuconfig and xconfig).  If you are using the "make menuconfig"
    method of configuring your kernel, then you would simply highlight the
    option in question and hit the ? key.  If you are using the "make xconfig"
    method of configuring your kernel, then simply click on the help button
    next to the option you have questions about.  The help information from
    the Configure.help file will then get automatically displayed.

  /proc support
  ------------------------------
    The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/
    directory. That directory contains a file for each SCSI controller in
    the system. Each file presents the current configuration and transfer
    statistics (enabled with #define in aic7xxx.c) for each controller.

    Thanks to Michael Neuffer for his upper-level SCSI help, and
    Matthew Jacob for statistics support.

  Debugging the driver
  ------------------------------
    Should you have problems with this driver, and would like some help in
    getting them solved, there are a couple debugging items built into
    the driver to facilitate getting the needed information from the system.
    In general, I need a complete description of the problem, with as many
    logs as possible concerning what happens.  To help with this, there is
    a command option aic7xxx=panic_on_abort.  This option, when set, forces
    the driver to panic the kernel on the first SCSI abort issued by the
    mid level SCSI code.  If your system is going to reset loops and you
    can't read the screen, then this is what you need.  Not only will it
    stop the system, but it also prints out a large amount of state
    information in the process.  Second, if you specify the option
    "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much
    information as it runs that you won't be able to see anything.
    However, this can actually be very useful if your machine simply
    locks up when trying to boot, since it will pin-point what was last
    happening (in regards to the aic7xxx driver) immediately prior to
    the lockup.  This is really only useful if your machine simply can
    not boot up successfully.  If you can get your machine to run, then
    this will produce far too much information.

  FTP sites
  ------------------------------
    ftp://ftp.redhat.com/pub/aic/
      - Out of date.  I used to keep stuff here, but too many people
        complained about having a hard time getting into Red Hat's ftp
	server.  So use the web site below instead.
    ftp://ftp.pcnet.com/users/eischen/Linux/
      - Dan Eischen's driver distribution area
    ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/
      - European Linux mirror of Teleport site

  Web sites
  ------------------------------
    http://people.redhat.com/dledford/
      - My web site, also the primary aic7xxx site with several related
        pages.

Dean W. Gehnert
deang@teleport.com

$Revision: 3.0 $

Modified by Doug Ledford 1998-2000

 /* TERMS AND CONDITIONS OF USE
 *
 * Redistribution and use in source form, with or without modification, are
 * permitted provided that redistributions of source code must retain the
 * above copyright notice, this list of conditions and the following disclaimer.
 *
 * This software is provided `as is' by Adaptec and
 * any express or implied warranties, including, but not limited to, the
 * implied warranties of merchantability and fitness for a particular purpose,
 * are disclaimed. In no event shall Adaptec be
 * liable for any direct, indirect, incidental, special, exemplary or
 * consequential damages (including, but not limited to, procurement of
 * substitute goods or services; loss of use, data, or profits; or business
 * interruptions) however caused and on any theory of liability, whether in
 * contract, strict liability, or tort (including negligence or otherwise)
 * arising in any way out of the use of this driver software, even if advised
 * of the possibility of such damage.
 *
 ****************************************************************
 * This driver supports the Adaptec I2O RAID and DPT SmartRAID V I2O boards.
 *
 * CREDITS:
 * The original linux driver was ported to Linux by Karen White while at
 * Dell Computer.  It was ported from Bob Pasteur's (of DPT) original
 * non-Linux driver.  Mark Salyzyn and Bob Pasteur consulted on the original
 * driver.
 *
 * 2.0 version of the driver by Deanna Bonds and Mark Salyzyn.
 *
 * HISTORY:
 * The driver was originally ported to linux version 2.0.34
 *
 * V2.0 Rewrite of driver.  Re-architectured based on i2o subsystem.
 *   This was the first full GPL version since the last version used
 *   i2osig headers which were not GPL.  Developer Testing version.
 * V2.1 Internal testing
 * V2.2 First released version
 *
 * V2.3
 *   Changes:
 *      Added Raptor Support
 *      Fixed bug causing system to hang under extreme load with
 *         management utilities running (removed GFP_DMA from kmalloc flags)
 *
 *
 * V2.4 First version ready to be submitted to be embedded in the kernel
 *   Changes:
 *      Implemented suggestions from Alan Cox
 *      Added calculation of resid for sg layer
 *      Better error handling
 *         Added checking underflow condtions
 *         Added DATAPROTECT checking
 *         Changed error return codes
 *         Fixed pointer bug in bus reset routine
 *      Enabled hba reset from ioctls (allows a FW flash to reboot and use the new
 *         FW without having to reboot)
 *      Changed proc output
 *
 * TODO:
 *      Add 64 bit Scatter Gather when compiled on 64 bit architectures
 *      Add sparse lun scanning
 *      Add code that checks if a device that had been taken offline is
 *         now online (at the FW level) when test unit ready or inquiry
 *         command from scsi-core
 *      Add proc read interface
 *         busrescan command
 *         rescan command
 *      Add code to rescan routine that notifies scsi-core about new devices
 *      Add support for C-PCI (hotplug stuff)
 *      Add ioctl passthru error recovery
 *
 * NOTES:
 * The DPT card optimizes the order of processing commands.  Consequently,
 * a command may take up to 6 minutes to complete after it has been sent
 * to the board.
 *
 * The files dpti_ioctl.h dptsig.h osd_defs.h osd_util.h sys_info.h are part of the
 * interface files for Adaptecs managment routines.  These define the structures used
 * in the ioctls.  They are written to be portable.  They are hard to read, but I need
 * to use them 'as is' or I can miss changes in the interface.
 *
 */

README file for the Linux DTC3180/3280 scsi driver.
by Ray Van Tassle (rayvt@comm.mot.com)  March 1996
Based on the generic & core NCR5380 code by Drew Eckhard

SCSI device driver for the DTC 3180/3280.
Data Technology Corp---a division of Qume.

The 3280 has a standard floppy interface.

The 3180 does not.  Otherwise, they are identical.

The DTC3x80 does not support DMA but it does have Pseudo-DMA which is
supported by the driver.

It's DTC406 scsi chip is supposedly compatible with the NCR 53C400.
It is memory mapped, uses an IRQ, but no dma or io-port.  There is
internal DMA, between SCSI bus and an on-chip 128-byte buffer.  Double
buffering is done automagically by the chip.  Data is transferred
between the on-chip buffer and CPU/RAM via memory moves.

The driver detects the possible memory addresses (jumper selectable):
	CC00, DC00, C800, and D800
The possible IRQ's (jumper selectable) are:
	IRQ 10, 11, 12, 15
Parity is supported by the chip, but not by this driver.
Information can be obtained from /proc/scsi/dtc3c80/N.

Note on interrupts:

The documentation says that it can be set to interrupt whenever the
on-chip buffer needs CPU attention.  I couldn't get this to work.  So
the driver polls for data-ready in the pseudo-DMA transfer routine.
The interrupt support routines in the NCR3280.c core modules handle
scsi disconnect/reconnect, and this (mostly) works.  However.....  I
have tested it with 4 totally different hard drives (both SCSI-1 and
SCSI-2), and one CDROM drive.  Interrupts works great for all but one
specific hard drive.  For this one, the driver will eventually hang in
the transfer state.  I have tested with: "dd bs=4k count=2k
of=/dev/null if=/dev/sdb".  It reads ok for a while, then hangs.
After beating my head against this for a couple of weeks, getting
nowhere, I give up.  So.....This driver does NOT use interrupts, even
if you have the card jumpered to an IRQ.  Probably nobody will ever
care.

README file for the Linux g_NCR5380 driver.

(c) 1993 Drew Eckhard
NCR53c400 extensions (c) 1994,1995,1996 Kevin Lentin

This file documents the NCR53c400 extensions by Kevin Lentin and some
enhancements to the NCR5380 core.

This driver supports both NCR5380 and NCR53c400 cards in port or memory
mapped modes. Currently this driver can only support one of those mapping
modes at a time but it does support both of these chips at the same time.
The next release of this driver will support port & memory mapped cards at
the same time. It should be able to handle multiple different cards in the
same machine.

The drivers/scsi/Makefile has an override in it for the most common
NCR53c400 card, the Trantor T130B in its default configuration:
	Port: 0x350
	IRQ : 5

The NCR53c400 does not support DMA but it does have Pseudo-DMA which is
supported by the driver.

If the default configuration does not work for you, you can use the kernel
command lines (eg using the lilo append command):
	ncr5380=port,irq,dma
	ncr53c400=port,irq
or
	ncr5380=base,irq,dma
	ncr53c400=base,irq

The driver does not probe for any addresses or ports other than those in
the OVERRIDE or given to the kernel as above.

This driver provides some information on what it has detected in
/proc/scsi/g_NCR5380/x where x is the scsi card number as detected at boot
time. More info to come in the future.

When NCR53c400 support is compiled in, BIOS parameters will be returned by
the driver (the raw 5380 driver does not and I don't plan to fiddle with
it!).

This driver works as a module.
When included as a module, parameters can be passed on the insmod/modprobe
command line:
  ncr_irq=xx   the interrupt
  ncr_addr=xx  the port or base address (for port or memory
               mapped, resp.)
  ncr_dma=xx   the DMA
  ncr_5380=1   to set up for a NCR5380 board
  ncr_53c400=1 to set up for a NCR53C400 board
e.g.
modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_5380=1
  for a port mapped NCR5380 board or
modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1
  for a memory mapped NCR53C400 board with interrupts disabled.

(255 should be specified for no or DMA interrupt, 254 to autoprobe for an
     IRQ line if overridden on the command line.)


Kevin Lentin
K.Lentin@cs.monash.edu.au

               -=< The IBM Microchannel SCSI-Subsystem >=-

	                 for the IBM PS/2 series

	  	   Low Level Software-Driver for Linux

     Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU
  General Public License. Originally written by Martin Kolinek, December 1995.
   Officially modified and maintained by Michael Lang since January 1999.

 	                       Version 4.0a

   Last update: January 3, 2001

   Before you Start
   ----------------
   This is the common README.ibmmca file for all driver releases of the
   IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0
   or newer do not work with kernel versions older than 2.4.0, while driver
   versions older than 4.0 do not work with kernels 2.4.0 or later! If you
   try to compile your kernel with the wrong driver source, the
   compilation is aborted and you get a corresponding error message. This is
   no bug in the driver. It prevents you from using the wrong sourcecode
   with the wrong kernel version.

   Authors of this Driver
   ----------------------
    - Chris Beauregard (improvement of the SCSI-device mapping by the driver)
    - Martin Kolinek (origin, first release of this driver)
    - Klaus Kudielka (multiple SCSI-host management/detection, adaption to
                      Linux Kernel 2.1.x, module support)
    - Michael Lang (assigning original pun/lun mapping, dynamical ldn
                    assignment, rewritten adapter detection, this file,
		    patches, official driver maintenance and subsequent
		    debugging, related with the driver)

   Table of Contents
   -----------------
   1 Abstract
   2 Driver Description
     2.1  IBM SCSI-Subsystem Detection
     2.2  Physical Units, Logical Units, and Logical Devices
     2.3  SCSI-Device Recognition and dynamical ldn Assignment
     2.4  SCSI-Device Order
     2.5  Regular SCSI-Command-Processing
     2.6  Abort & Reset Commands
     2.7  Disk Geometry
     2.8  Kernel Boot Option
     2.9  Driver Module Support
     2.10 Multiple Hostadapter Support
     2.11 /proc/scsi-Filesystem Information
     2.12 /proc/mca-Filesystem Information
     2.13 Supported IBM SCSI-Subsystems
     2.14 Linux Kernel Versions
   3 Code History
   4 To do
   5 Users' Manual
     5.1 Commandline Parameters
     5.2 Troubleshooting
     5.3 Bugreports
     5.4 Support WWW-page
   6 References
   7 Credits to
     7.1 People
     7.2 Sponsors & Supporters
   8 Trademarks
   9 Disclaimer

                              * * *

   1 Abstract
   ----------
   This README-file describes the IBM SCSI-subsystem low level driver for
   Linux. The descriptions which were formerly kept in the source-code have
   been taken out to this file to easify the codes' readability. The driver
   description has been updated, as most of the former description was already
   quite outdated. The history of the driver development is also kept inside
   here. Multiple historical developments have been summarized to shorten the
   textsize a bit. At the end of this file you can find a small manual for
   this driver and hints to get it running on your machine.

   2 Driver Description
   --------------------
   2.1 IBM SCSI-Subsystem Detection
   --------------------------------
   This is done in the ibmmca_detect() function. It first checks, if the
   Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the
   Microchannel. In a next step, a free interrupt is chosen and the main
   interrupt handler is connected to it to handle answers of the SCSI-
   subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11
   instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a
   further step it is checked, if the adapter gets detected by force from
   the kernel commandline, where the I/O port and the SCSI-subsystem id can
   be specified. The next step checks if there is an integrated SCSI-subsystem
   installed. This register area is fixed through all IBM PS/2 MCA-machines
   and appears as something like a virtual slot 10 of the MCA-bus. On most
   PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not
   integrated SCSI-controller is available. But on certain PS/2s, like model
   9595, this slot 10 is used to store other information which at earlier
   stage confused the driver and resulted in the detection of some ghost-SCSI.
   If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS
   registers are either 0xff or 0x00, there must be an integrated SCSI-
   subsystem present and it will be registered as IBM Integrated SCSI-
   Subsystem. The next step checks, if there is a slot-adapter installed on
   the MCA-bus. To get this, the first two POS-registers, that represent the
   adapter ID are checked. If they fit to one of the ids, stored in the
   adapter list, a SCSI-subsystem is assumed to be found in a slot and will be
   registered. This check is done through all possible MCA-bus slots to allow
   more than one SCSI-adapter to be present in the PS/2-system and this is
   already the first point of problems. Looking into the technical reference
   manual for the IBM PS/2 common interfaces, the POS2 register must have
   different interpretation of its single bits to avoid overlapping I/O
   regions. While one can assume, that the integrated subsystem has a fix
   I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must
   use a different I/O-address. This is expressed by bit 1 to 3 of POS2
   (multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated
   subsystem, but not for the adapters! The following list shows, how the
   bits of POS2 and POS3 should be interpreted.

   The POS2-register of all PS/2 models' integrated SCSI-subsystems has the
   following interpretation of bits:
                           Bit 7 - 4 : Chip Revision ID (Release)
                           Bit 3 - 2 : Reserved
                           Bit 1     : 8k NVRAM Disabled
                           Bit 0     : Chip Enable (EN-Signal)
   The POS3-register is interpreted as follows (for most IBM SCSI-subsys.):
                           Bit 7 - 5 : SCSI ID
                           Bit 4 - 0 : Reserved = 0
   The slot-adapters have different interpretation of these bits. The IBM SCSI
   adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following
   interpretation of the POS2 register:
                           Bit 7 - 4 : ROM Segment Address Select
			   Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540)
			   Bit 0     : Adapter Enable (EN-Signal)
   and for the POS3 register:
                           Bit 7 - 5 : SCSI ID
			   Bit 4     : Fairness Enable (SCSI ID3 f. F/W)
			   Bit 3 - 0 : Arbitration Level
   The most modern product of the series is the IBM SCSI-2 F/W adapter, it
   allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be
   between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide
   adapter PUN expression. In short words, this means, that IBM PS/2 machines
   can only support 1 single integrated subsystem by default. Additional
   slot-adapters get ports assigned by the automatic configuration tool.

   One day I found a patch in ibmmca_detect(), forcing the I/O-address to be
   0x3540 for integrated SCSI-subsystems, there was a remark placed, that on
   integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5.
   This means, that really for these models, POS2 has to be interpreted
   sticking to the technical reference guide. In this case, the bit 2 (4) is
   a reserved bit and may not be interpreted. These differences between the
   adapters and the integrated controllers are taken into account by the
   detection routine of the driver on from version >3.0g.

   Every time, a SCSI-subsystem is discovered, the ibmmca_register() function
   is called. This function checks first, if the requested area for the I/O-
   address of this SCSI-subsystem is still available and assigns this I/O-
   area to the SCSI-subsystem. There are always 8 sequential I/O-addresses
   taken for each individual SCSI-subsystem found, which are:

     Offset            Type                  Permissions
       0     Command Interface Register 1    Read/Write
       1     Command Interface Register 2    Read/Write
       2     Command Interface Register 3    Read/Write
       3     Command Interface Register 4    Read/Write
       4     Attention Register              Read/Write
       5     Basic Control Register          Read/Write
       6     Interrupt Status Register       Read
       7     Basic Status Register           Read

   After the I/O-address range is assigned, the host-adapter is assigned
   to a local structure which keeps all adapter information needed for the
   driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun
   and the adapters' ldn tables are initialized and get probed afterwards by
   the check_devices() function. If no further adapters are found,
   ibmmca_detect() quits.

   2.2 Physical Units, Logical Units, and Logical Devices
   ------------------------------------------------------
   There can be up to 56 devices on the SCSI bus (besides the adapter):
   there are up to 7 "physical units" (each identified by physical unit
   number or pun, also called the scsi id, this is the number you select
   with hardware jumpers), and each physical unit can have up to 8
   "logical units" (each identified by logical unit number, or lun,
   between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
   busses and provides support for 30 logical devices at the same time, where
   in wide-addressing mode you can have 16 puns with 32 luns on each device.
   This section dexribes you the handling of devices on non-F/W adapters.
   Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
   which means a lot of possible devices for such a small machine.

   Typically the adapter has pun=7, so puns of other physical units
   are between 0 and 6(15). On a wide-adapter a pun higher than 7 is
   possible, but is normally not used. Almost all physical units have only
   one logical unit, with lun=0. A CD-ROM jukebox would be an example of a
   physical unit with more than one logical unit.

   The embedded microprocessor of the IBM SCSI-subsystem hides the complex
   two-dimensional (pun,lun) organization from the operating system.
   When the machine is powered-up (or rebooted), the embedded microprocessor
   checks, on its own, all 56 possible (pun,lun) combinations, and the first
   15 devices found are assigned into a one-dimensional array of so-called
   "logical devices", identified by "logical device numbers" or ldn. The last
   ldn=15 is reserved for the subsystem itself. Wide adapters may have
   to check up to 15 * 8 = 120 pun/lun combinations.

   2.3 SCSI-Device Recognition and Dynamical ldn Assignment
   --------------------------------------------------------
   One consequence of information hiding is that the real (pun,lun)
   numbers are also hidden. The two possibilities to get around this problem
   is to offer fake pun/lun combinations to the operating system or to
   delete the whole mapping of the adapter and to reassign the ldns, using
   the immediate assign command of the SCSI-subsystem for probing through
   all possible pun/lun combinations. a ldn is a "logical device number"
   which is used by IBM SCSI-subsystems to access some valid SCSI-device.
   At the beginning of the development of this driver, the following approach
   was used:

   First, the driver checked the ldn's (0 to 6) to find out which ldn's
   have devices assigned. This was done by the functions check_devices() and
   device_exists(). The interrupt handler has a special paragraph of code
   (see local_checking_phase_flag) to assist in the checking. Assume, for
   example, that three logical devices were found assigned at ldn 0, 1, 2.
   These are presented to the upper layer of Linux SCSI driver
   as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0).
   On the other hand, if the upper layer issues a command to device
   say (4,0), this driver returns DID_NO_CONNECT error.

   In a second step of the driver development, the following improvement has
   been applied: The first approach limited the number of devices to 7, far
   fewer than the 15 that it could usem then it just maped ldn ->
   (ldn/8,ldn%8) for pun,lun.  We ended up with a real mishmash of puns
   and luns, but it all seemed to work.

   The latest development, which is implemented from the driver version 3.0
   and later, realizes the device recognition in the following way:
   The physical SCSI-devices on the SCSI-bus are probed via immediate_assign-
   and device_inquiry-commands, that is all implemented in a completely new
   made check_devices() subroutine. This delivers an exact map of the physical
   SCSI-world that is now stored in the get_scsi[][]-array. This means,
   that the once hidden pun,lun assignment is now known to this driver.
   It no longer believes in default-settings of the subsystem and maps all
   ldns to existing pun,lun "by foot". This assures full control of the ldn
   mapping and allows dynamical remapping of ldns to different pun,lun, if
   there are more SCSI-devices installed than ldns available (n>15). The
   ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0,
   excluding the pun of the subsystem. This assures, that at least simple
   SCSI-installations have optimum access-speed and are not touched by
   dynamical remapping. The ldns 7 to 14 are put to existing devices with
   lun>0 or to non-existing devices, in order to satisfy the subsystem, if
   there are less than 15 SCSI-devices connected. In the case of more than 15
   devices, the dynamical mapping goes active. If the get_scsi[][] reports a
   device to be existant, but it has no ldn assigned, it gets a ldn out of 7
   to 14. The numbers are assigned in cyclic order. Therefore it takes 8
   dynamical reassignments on the SCSI-devices, until a certain device
   looses its ldn again. This assures, that dynamical remapping is avoided
   during intense I/O between up to 15 SCSI-devices (means pun,lun
   combinations). A further advantage of this method is, that people who
   build their kernel without probing on all luns will get what they expect,
   because the driver just won't assign everything with lun>0 when
   multpile lun probing is inactive.

   2.4 SCSI-Device Order
   ---------------------
   Because of the now correct recognition of physical pun,lun, and
   their report to mid-level- and higher-level-drivers, the new reported puns
   can be different from the old, faked puns. Therefore, Linux will eventually
   change /dev/sdXXX assignments and prompt you for corrupted superblock
   repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!!
   You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file
   entries right. After that, the system should come up as errorfree as before.
   If your boot-partition is not coming up, also edit the /etc/lilo.conf-file
   in a Linux session booted on old kernel and run lilo before reboot. Check
   lilo.conf anyway to get boot on other partitions with foreign OSes right
   again. But there exists a feature of this driver that allows you to change
   the assignment order of the SCSI-devices by flipping the PUN-assignment.
   See the next paragraph for a description.

   The problem for this is, that Linux does not assign the SCSI-devices in the
   way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to
   the device with at minimum id 0. But the first drive should be at id 6,
   because for historical reasons, drive at id 6 has, by hardware, the highest
   priority and a drive at id 0 the lowest. IBM was one of the rare producers,
   where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most
   other producers' BIOS does not (I think even Adaptec-BIOS). The
   IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the
   kernel enables to choose the preferred way of SCSI-device-assignment.
   Defining this flag would result in Linux determining the devices in the
   same order as DOS and OS/2 does on your MCA-machine. This is also standard
   on most industrial computers and OSes, like e.g. OS-9. Leaving this flag
   undefined will get your devices ordered in the default way of Linux. See
   also the remarks of Chris Beauregard from Dec 15, 1997 and the followups
   in section 3.

   2.5 Regular SCSI-Command-Processing
   -----------------------------------
   Only three functions get involved: ibmmca_queuecommand(), issue_cmd(),
   and interrupt_handler().

   The upper layer issues a scsi command by calling function
   ibmmca_queuecommand(). This function fills a "subsystem control block"
   (scb) and calls a local function issue_cmd(), which writes a scb
   command into subsystem I/O ports. Once the scb command is carried out,
   the interrupt_handler() is invoked. If a device is determined to be
   existant and it has not assigned any ldn, it gets one dynamically.
   For this, the whole stuff is done in ibmmca_queuecommand().

   2.6 Abort & Reset Commands
   --------------------------
   These are implemented with busy waiting for interrupt to arrive.
   ibmmca_reset() and ibmmca_abort() do not work sufficently well
   up to now and need still a lot of development work. But, this seems
   to be even a problem with other SCSI-low level drivers, too. However,
   this should be no excuse.

   2.7 Disk Geometry
   -----------------
   The ibmmca_biosparams() function should return the same disk geometry
   as the bios. This is needed for fdisk, etc. The returned geometry is
   certainly correct for disks smaller than 1 gigabyte. In the meantime,
   it has been proved, that this works fine even with disks larger than
   1 gigabyte.

   2.8 Kernel Boot Option
   ----------------------
   The function ibmmca_scsi_setup() is called if option ibmmcascsi=n
   is passed to the kernel. See file linux/init/main.c for details.

   2.9 Driver Module Support
   -------------------------
   Is implemented and tested by K. Kudielka. This could probably not work
   on kernels <2.1.0.

   2.10 Multiple Hostadapter Support
   ---------------------------------
   This driver supports up to eight interfaces of type IBM-SCSI-Subsystem.
   Integrated-, and MCA-adapters are automatically recognized. Unrecognizable
   IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters.

   2.11 /proc/scsi-Filesystem Information
   --------------------------------------
   Information about the driver condition is given in
   /proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information.

   This table is quite informative for interested users. It shows the load
   of commands on the subsystem and wether you are running the bypassed
   (software) or integrated (hardware) SCSI-command set (see below). The
   amount of accesses is shown. Read, write, modeselect is shown seperately
   in order to help debugging problems with CD-ROMs or tapedrives.

   The following table shows the list of 15 logical device numbers, that are
   used by the SCSI-subsystem. The load on each ldn is shown in the table,
   again, read and write commands are split. The last column shows the amount
   of reassignments, that have been applied to the ldns, if you have more than
   15 pun/lun combinations available on the SCSI-bus.

   The last two tables show the pun/lun map and the positions of the ldns
   on this pun/lun map. This may change during operation, when a ldn is
   reassigned to another pun/lun combination. If the necessity for dynamical
   assignments is set to 'no', the ldn structure keeps static.

   2.12 /proc/mca-Filesystem Information
   -------------------------------------
   The slot-file contains all default entries and in addition chip and I/O-
   address information of the SCSI-subsystem. This information is provided
   by ibmmca_getinfo().

   2.13 Supported IBM SCSI-Subsystems
   ----------------------------------
   The following IBM SCSI-subsystems are supported by this driver:

     - IBM Fast/Wide SCSI-2 Adapter
     - IBM 7568 Industrial Computer SCSI Adapter w/Cache
     - IBM Expansion Unit SCSI Controller
     - IBM SCSI Adapter w/Cache
     - IBM SCSI Adapter
     - IBM Integrated SCSI Controller
     - All clones, 100% compatible with the chipset and subsystem command
       system of IBM SCSI-adapters (forced detection)

   2.14 Linux Kernel Versions
   --------------------------
   The IBM SCSI-subsystem low level driver is prepared to be used with
   all versions of Linux between 2.0.x and 2.4.x. The compatibility checks
   are fully implemented up from version 3.1e of the driver. This means, that
   you just need the latest ibmmca.h and ibmmca.c file and copy it in the
   linux/drivers/scsi directory. The code is automatically adapted during
   kernel compilation. This is different from kernel 2.4.0! Here version
   4.0 or later of the driver must be used for kernel 2.4.0 or later. Version
   4.0 or later does not work together with older kernels! Driver versions
   older than 4.0 do not work together with kernel 2.4.0 or later. They work
   on all older kernels.

   3 Code History
   --------------
   Jan 15 1996:  First public release.
   - Martin Kolinek

   Jan 23 1996:  Scrapped code which reassigned scsi devices to logical
   device numbers. Instead, the existing assignment (created
   when the machine is powered-up or rebooted) is used.
   A side effect is that the upper layer of Linux SCSI
   device driver gets bogus scsi ids (this is benign),
   and also the hard disks are ordered under Linux the
   same way as they are under dos (i.e., C: disk is sda,
   D: disk is sdb, etc.).
   - Martin Kolinek

   I think that the CD-ROM is now detected only if a CD is
   inside CD_ROM while Linux boots. This can be fixed later,
   once the driver works on all types of PS/2's.
   - Martin Kolinek

   Feb 7 1996:   Modified biosparam function. Fixed the CD-ROM detection.
   For now, devices other than harddisk and CD_ROM are
   ignored. Temporarily modified abort() function
   to behave like reset().
   - Martin Kolinek

   Mar 31 1996:  The integrated scsi subsystem is correctly found
   in PS/2 models 56,57, but not in model 76. Therefore
   the ibmmca_scsi_setup() function has been added today.
   This function allows the user to force detection of
   scsi subsystem. The kernel option has format
   ibmmcascsi=n
   where n is the scsi_id (pun) of the subsystem. Most likely, n is 7.
   - Martin Kolinek

   Aug 21 1996:  Modified the code which maps ldns to (pun,0).  It was
   insufficient for those of us with CD-ROM changers.
   - Chris Beauregard

   Dec 14 1996: More improvements to the ldn mapping.  See check_devices
   for details.  Did more fiddling with the integrated SCSI detection,
   but I think it's ultimately hopeless without actually testing the
   model of the machine.  The 56, 57, 76 and 95 (ultimedia) all have
   different integrated SCSI register configurations.  However, the 56
   and 57 are the only ones that have problems with forced detection.
   - Chris Beauregard

   Mar 8-16 1997: Modified driver to run as a module and to support
   multiple adapters. A structure, called ibmmca_hostdata, is now
   present, containing all the variables, that were once only
   available for one single adapter. The find_subsystem-routine has vanished.
   The hardware recognition is now done in ibmmca_detect directly.
   This routine checks for presence of MCA-bus, checks the interrupt
   level and continues with checking the installed hardware.
   Certain PS/2-models do not recognize a SCSI-subsystem automatically.
   Hence, the setup defined by command-line-parameters is checked first.
   Thereafter, the routine probes for an integrated SCSI-subsystem.
   Finally, adapters are checked. This method has the advantage to cover all
   possible combinations of multiple SCSI-subsystems on one MCA-board. Up to
   eight SCSI-subsystems can be recognized and announced to the upper-level
   drivers with this improvement. A set of defines made changes to other
   routines as small as possible.
   - Klaus Kudielka

   May 30 1997: (v1.5b)
   1) SCSI-command capability enlarged by the recognition of MODE_SELECT.
      This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
      allows data to be written from the system to the device. It is a
      necessary step to be allowed to set blocksize of SCSI-tape-drives and
      the tape-speed, whithout confusing the SCSI-Subsystem.
   2) The recognition of a tape is included in the check_devices routine.
      This is done by checking for TYPE_TAPE, that is already defined in
      the kernel-scsi-environment. The markup of a tape is done in the
      global ldn_is_tape[] array. If the entry on index ldn
      is 1, there is a tapedrive connected.
   3) The ldn_is_tape[] array is necessary to distinguish between tape- and
      other devices. Fixed blocklength devices should not cause a problem
      with the SCB-command for read and write in the ibmmca_queuecommand
      subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for
      the tape-devices, as recommended by IBM in this Technical Reference,
      mentioned below. (IBM recommends to avoid using the read/write of the
      subsystem, but the fact was, that read/write causes a command error from
      the subsystem and this causes kernel-panic.)
   4) In addition, I propose to use the ldn instead of a fix char for the
      display of PS2_DISK_LED_ON(). On 95, one can distinguish between the
      devices that are accessed. It shows activity and easyfies debugging.
   The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2
   (I do not know yet the type). Optimization and CD-ROM audio-support,
   I am working on ...
   - Michael Lang

   June 19 1997: (v1.6b)
   1) Submitting the extra-array ldn_is_tape[] -> to the local ld[]
      device-array.
   2) CD-ROM Audio-Play seems to work now.
   3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code
      0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears
      also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that
      the problem is independent of the low-level-driver/bus-architecture.
   4) Hexadecimal ldn on PS/2-95 LED-display.
   5) Fixing of the PS/2-LED on/off that it works right with tapedrives and
      does not confuse the disk_rw_in_progress counter.
   - Michael Lang

   June 21 1997: (v1.7b)
   1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the
      outer-world about operational load statistics on the different ldns,
      seen by the driver. Everybody that has more than one IBM-SCSI should
      test this, because I only have one and cannot see what happens with more
      than one IBM-SCSI hosts.
   2) Definition of a driver version-number to have a better recognition of
      the source when there are existing too much releases that may confuse
      the user, when reading about release-specific problems. Up to know,
      I calculated the version-number to be 1.7. Because we are in BETA-test
      yet, it is today 1.7b.
   3) Sorry for the heavy bug I programmed on June 19 1997! After that, the
      CD-ROM did not work any more! The C7-command was a fake impression
      I got while programming. Now, the READ and WRITE commands for CD-ROM are
      no longer running over the subsystem, but just over
      IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts
      much faster(!) and hopefully all fancy multimedia-functions, like direct
      digital recording from audio-CDs also work. (I tried it with cdda2wav
      from the cdwtools-package and it filled up the harddisk immediately :-).)
      To easify boolean logics, a further local device-type in ld[], called
      is_cdrom has been included.
   4) If one uses a SCSI-device of unsupported type/commands, one
      immediately runs into a kernel-panic caused by Command Error. To better
      understand which SCSI-command caused the problem, I extended this
      specific panic-message slightly.
   - Michael Lang

   June 25 1997: (v1.8b)
   1) Some cosmetical changes for the handling of SCSI-device-types.
      Now, also CD-Burners / WORMs and SCSI-scanners should work. For
      MO-drives I have no experience, therefore not yet supported.
      In logical_devices I changed from different type-variables to one
      called 'device_type' where the values, corresponding to scsi.h,
      of a SCSI-device are stored.
   2) There existed a small bug, that maps a device, coming after a SCSI-tape
      wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong
      -> problem removed.
   3) Extension of the logical_device structure. Now it contains also device,
      vendor and revision-level of a SCSI-device for internal usage.
   - Michael Lang

   June 26-29 1997: (v2.0b)
   1) The release number 2.0b is necessary because of the completely new done
      recognition and handling of SCSI-devices with the adapter. As I got
      from Chris the hint, that the subsystem can reassign ldns dynamically,
      I remembered this immediate_assign-command, I found once in the handbook.
      Now, the driver first kills all ldn assignments that are set by default
      on the SCSI-subsystem. After that, it probes on all puns and luns for
      devices by going through all combinations with immediate_assign and
      probing for devices, using device_inquiry. The found physical(!) pun,lun
      structure is stored in get_scsi[][] as device types. This is followed
      by the assignment of all ldns to existing SCSI-devices. If more ldns
      than devices are available, they are assigned to non existing pun,lun
      combinations to satisfy the adapter. With this, the dynamical mapping
      was possible to implement. (For further info see the text in the
      source-code and in the description below. Read the description
      below BEFORE installing this driver on your system!)
   2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
   3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
      (pun) of the accessed SCSI-device. This is now senseful, because the
      pun known within the driver is exactly the pun of the physical device
      and no longer a fake one.
   4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where
      hit-statistics of ldns is shown and a second part, where the maps of
      physical and logical SCSI-devices are displayed. This could be very
      interesting, when one is using more than 15 SCSI-devices in order to
      follow the dynamical remapping of ldns.
   - Michael Lang

   June 26-29 1997: (v2.0b-1)
   1) I forgot to switch the local_checking_phase_flag to 1 and back to 0
      in the dynamical remapping part in ibmmca_queuecommand for the
      device_exist routine. Sorry.
   - Michael Lang

   July 1-13 1997: (v3.0b,c)
   1) Merging of the driver-developments of Klaus Kudielka and Michael Lang
      in order to get a optimum and unified driver-release for the
      IBM-SCSI-Subsystem-Adapter(s).
         For people, using the Kernel-release >=2.1.0, module-support should
      be no problem. For users, running under <2.1.0, module-support may not
      work, because the methods have changed between 2.0.x and 2.1.x.
   2) Added some more effective statistics for /proc-output.
   3) Change typecasting at necessary points from (unsigned long) to
      virt_to_bus().
   4) Included #if... at special points to have specific adaption of the
      driver to kernel 2.0.x and 2.1.x. It should therefore also run with
      later releases.
   5) Magneto-Optical drives and medium-changers are also recognized, now.
      Therefore, we have a completely gapfree recognition of all SCSI-
      device-types, that are known by Linux up to kernel 2.1.31.
   6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within
      the configuration, each connected SCSI-device will get a reset command
      during boottime. This can be necessary for some special SCSI-devices.
      This flag should be included in Config.in.
      (See also the new Config.in file.)
   Probable next improvement: bad disk handler.
   - Michael Lang

   Sept 14 1997: (v3.0c)
   1) Some debugging and speed optimization applied.
   - Michael Lang

   Dec 15, 1997
    - chrisb@truespectra.com
    - made the front panel display thingy optional, specified from the
    command-line via ibmmcascsi=display.  Along the lines of the /LED
    option for the OS/2 driver.
    - fixed small bug in the LED display that would hang some machines.
    - reversed ordering of the drives (using the
    IBMMCA_SCSI_ORDER_STANDARD define).  This is necessary for two main
    reasons:
	- users who've already installed Linux won't be screwed.  Keep
	in mind that not everyone is a kernel hacker.
	- be consistent with the BIOS ordering of the drives.  In the
	BIOS, id 6 is C:, id 0 might be D:.  With this scheme, they'd be
	backwards.  This confuses the crap out of those heathens who've
	got a impure Linux installation (which, <wince>, I'm one of).
    This whole problem arises because IBM is actually non-standard with
    the id to BIOS mappings.  You'll find, in fdomain.c, a similar
    comment about a few FD BIOS revisions.  The Linux (and apparently
    industry) standard is that C: maps to scsi id (0,0).  Let's stick
    with that standard.
    - Since this is technically a branch of my own, I changed the
    version number to 3.0e-cpb.

   Jan 17, 1998: (v3.0f)
   1) Addition of some statistical info for /proc in proc_info.
   2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15
      1997. In fact, IBM is right, concerning the assignment of SCSI-devices
      to driveletters. It is conform to the ANSI-definition of the SCSI-
      standard to assign drive C: to SCSI-id 6, because it is the highest
      hardware priority after the hostadapter (that has still today by
      default everywhere id 7). Also realtime-operating systems that I use,
      like LynxOS and OS9, which are quite industrial systems use top-down
      numbering of the harddisks, that is also starting at id 6. Now, one
      sits a bit between two chairs. On one hand side, using the define
      IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to
      the IBM- and ANSI-SCSI-standard and keeps this driver downward
      compatible to older releases, on the other hand side, people is quite
      habituated in believing that C: is assigned to (0,0) and much other
      SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD
      define out of the driver and put it into Config.in as subitem of
      'IBM SCSI support'. A help, added to Documentation/Configure.help
      explains the differences between saying 'y' or 'n' to the user, when
      IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to
      choose the way of assignment, depending on his own situation and gusto.
   3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is
      now called IBMMCA_SCSI_DEV_RESET.
   4) Optimization of proc_info and its subroutines.
   5) Added more in-source-comments and extended the driver description by
      some explanation about the SCSI-device-assignment problem.
   - Michael Lang

   Jan 18, 1998: (v3.0g)
   1) Correcting names to be absolutely conform to the later 2.1.x releases.
      This is necessary for
            IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET
            IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD
   - Michael Lang

   Jan 18, 1999: (v3.1 MCA-team internal)
   1) The multiple hosts structure is accessed from every subroutine, so there
      is no longer the address of the device structure passed from function
      to function, but only the hostindex. A call by value, nothing more. This
      should really be understood by the compiler and the subsystem should get
      the right values and addresses.
   2) The SCSI-subsystem detection was not complete and quite hugely buggy up
      to now, compared to the technical manual. The interpretation of the pos2
      register is not as assumed by people before, therefore, I dropped a note
      in the ibmmca_detect function to show the registers' interpretation.
      The pos-registers of integrated SCSI-subsystems do not contain any
      information concerning the IO-port offset, really. Instead, they contain
      some info about the adapter, the chip, the NVRAM .... The I/O-port is
      fixed to 0x3540 - 0x3547. There can be more than one adapters in the
      slots and they get an offset for the I/O area in order to get their own
      I/O-address area. See chapter 2 for detailed description. At least, the
      detection should now work right, even on models other than 95. The 95ers
      came happily around the bug, as their pos2 register contains always 0
      in the critical area. Reserved bits are not allowed to be interpreted,
      therefore, IBM is allowed to set those bits as they like and they may
      really vary between different PS/2 models. So, now, no interpretation
      of reserved bits - hopefully no trouble here anymore.
   3) The command error, which you may get on models 55, 56, 57, 70, 77 and
      P70 may have been caused by the fact, that adapters of older design do
      not like sending commands to non-existing SCSI-devices and will react
      with a command error as a sign of protest. While this error is not
      present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
      Adapters. Therefore, I implemented a workarround to forgive those
      adapters their protests, but it is marked up in the statisctis, so
      after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
      how often the command errors have been forgiven to the SCSI-subsystem.
      If the number is bigger than 0, you have a SCSI subsystem of older
      design, what should no longer matter.
   4) ibmmca_getinfo() has been adapted very carefully, so it shows in the
      slotn file really, what is senseful to be presented.
   5) ibmmca_register() has been extended in its parameter list in order to
      pass the right name of the SCSI-adapter to Linux.
   - Michael Lang

   Feb 6, 1999: (v3.1)
   1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for
      the delayed release, but it was not finished with the release of
      Kernel 2.2.0.
   - Michael Lang

   Feb 10, 1999 (v3.1)
   1) Added a new commandline parameter called 'bypass' in order to bypass
      every integrated subsystem SCSI-command consequently in case of
      troubles.
   2) Concatenated read_capacity requests to the harddisks. It gave a lot
      of troubles with some controllers and after I wanted to apply some
      extensions, it jumped out in the same situation, on my w/cache, as like
      on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
      descissive hint to move the code-part out and declare it global. Now,
      it seems to work by far much better an more stable. Let us see, what
      the world thinks of it...
   3) By the way, only Sony DAT-drives seem to show density code 0x13. A
      test with a HP drive gave right results, so the problem is vendor-
      specific and not a problem of the OS or the driver.
   - Michael Lang

   Feb 18, 1999 (v3.1d)
   1) The abort command and the reset function have been checked for
      inconsistencies. From the logical point of thinking, they work
      at their optimum, now, but as the subsystem does not answer with an
      interrupt, abort never finishes, sigh...
   2) Everything, that is accessed by a busmaster request from the adapter
      is now declared as global variable, even the return-buffer in the
      local checking phase. This assures, that no accesses to undefined memory
      areas are performed.
   3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to
      avoid memory-pointers for the areas higher than 16MByte in order to
      be sure, it also works on 16-Bit Microchannel bus systems.
   4) A lot of small things have been found, but nothing that endangered the
      driver operations. Just it should be more stable, now.
   - Michael Lang

   Feb 20, 1999 (v3.1e)
   1) I took the warning from the Linux Kernel Hackers Guide serious and
      checked the cmd->result return value to the done-function very carefully.
      It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if
      some error appeared, else it is undefined. Now, this is fixed. Before
      any SCB command gets queued, the tsb.dev_status is set to 0, so the
      cmd->result won't screw up Linux higher level drivers.
   2) The reset-function has slightly improved. This is still planed for
      abort. During the abort and the reset function, no interrupts are
      allowed. This is however quite hard to cope with, so the INT-status
      register is read. When the interrupt gets queued, one can find its
      status immediately on that register and is enabled to continue in the
      reset function. I had no chance to test this really, only in a bogus
      situation, I got this function running, but the situation was too much
      worse for Linux :-(, so tests will continue.
   3) Buffers got now consistent. No open address mapping, as before and
      therefore no further troubles with the unassigned memory segmentation
      faults that scrambled probes on 95XX series and even on 85XX series,
      when the kernel is done in a not so perfectly fitting way.
   4) Spontaneous interrupts from the subsystem, appearing without any
      command previously queued are answered with a DID_BAD_INTR result.
   5) Taken into account ZP Gus' proposals to reverse the SCSI-device
      scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed
      by him, I implemented it in a slightly derived way, which offers in
      addition more flexibility.
   - Michael Lang

   Apr 23, 2000 (v3.2pre1)
   1) During a very long time, I collected a huge amount of bugreports from
      various people, trying really quite different things on their SCSI-
      PS/2s. Today, all these bugreports are taken into account and should be
      mostly solved. The major topics were:
      - Driver crashes during boottime by no obvious reason.
      - Driver panics while the midlevel-SCSI-driver is trying to inquire
        the SCSI-device properties, even though hardware is in perfect state.
      - Displayed info for the various slot-cards is interpreted wrong.
      The main reasons for the crashes were two:
      1) The commands to check for device information like INQUIRY,
         TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices
	 to deliver information of up to 255 bytes. Midlevel drivers offer
	 1024 bytes of space for the answer, but the IBM-SCSI-adapters do
	 not accept this, as they stick quite near to ANSI-SCSI and report
	 a COMMAND_ERROR message which causes the driver to panic. The main
	 problem was located around the INQUIRY command. Now, for all the
	 mentioned commands, the buffersize, sent to the adapter is at
	 maximum 255 which seems to be a quite reasonable solution.
	 TEST_UNIT_READY gets a buffersize of 0 to make sure, that no
	 data is transferred in order to avoid any possible command failure.
      2) On unsuccessful TEST_UNIT_READY, the midlevel-driver has to send
         a REQUEST_SENSE in order to see, where the problem is located. This
	 REQUEST_SENSE may have various length in its answer-buffer. IBM
	 SCSI-subsystems report a command failure, if the returned buffersize
	 is different from the sent buffersize, but this can be supressed by
	 a special bit, which is now done and problems seem to be solved.
   2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on
      2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
   3) Commandline-parameters are recognized again, even under Kernel 2.3.x or
      higher.
   - Michael Lang

   April 27, 2000 (v3.2pre2)
   1) Bypassed commands get read by the adapter by one cycle instead of two.
      This increases SCSI-performance.
   2) Synchronous datatransfer is provided for sure to be 5 MHz on older
      SCSI and 10 MHz on internal F/W SCSI-adapter.
   3) New commandline parameters allow to force the adapter to slow down while
      in synchronous transfer. Could be helpful for very old devices.
   - Michael Lang

   June 2, 2000 (v3.2pre5)
   1) Added Jim Shorney's contribution to make the activity indicator
      flashing in addition to the LED-alphanumeric display-panel on
      models 95A. To be enabled to choose this feature freely, a new
      commandline parameter is added, called 'activity'.
   2) Added the READ_CONTROL bit for test_unit_ready SCSI-command.
   3) Added some suppress_exception bits to read_device_capacity and
      all device_inquiry occurences in the driver code.
   4) Complaints about the various KERNEL_VERSION implementations are
      taken into account. Every local_LinuxKernelVersion occurence is
      now replaced by KERNEL_VERSION, defined in linux/version.h.
      Corresponding changes were applied to ibmmca.h, too. This was a
      contribution to all kernel-parts by Philipp Hahn.
   - Michael Lang

   July 17, 2000 (v3.2pre8)
   A long period of collecting bugreports from all corners of the world
   now lead to the following corrections to the code:
   1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
      was, that it is possible to disbale Fast-SCSI for the external bus.
      The feature-control command, where this crash appeared regularly tried
      to set the maximum speed of 10MHz synchronous transfer speed and that
      reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now,
      the feature-command probes down from maximum speed until the adapter
      stops to complain, which is at the same time the maximum possible
      speed selected in the reference program. So, F/W external can run at
      5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the
      COMMAND ERROR message is used to detect if the adapter does not complain.
   2) Up to now, only combined busmode is supported, if you use external
      SCSI-devices, attached to the F/W-controller. If dual bus is selected,
      only the internal SCSI-devices get accessed by Linux. For most
      applications, this should do fine.
   3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W
      bus on the F/W adapter. If F/W adapter is detected, the driver
      automatically uses the extended PUN/LUN <-> LDN mapping tables, which
      are now new from 3.2pre8. This allows PUNs between 0 and 15 and should
      provide more fun with the F/W adapter.
   4) Several machines use the SCSI: POS registers for internal/undocumented
      storage of system relevant info. This confused the driver, mainly on
      models 9595, as it expected no onboard SCSI only, if all POS in
      the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism
      to check for integrated SCSI is much more restrictive and these problems
      should be history.
   - Michael Lang

   July 18, 2000 (v3.2pre9)
   This develop rather quickly at the moment. Two major things were still
   missing in 3.2pre8:
   1) The adapter PUN for F/W adapters has 4-bits, while all other adapters
      have 3-bits. This is now taken into account for F/W.
   2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should
      normally get the inverse probing order of your devices on the SCSI-bus.
      The ANSI device order gets scrambled in version 3.2pre8!! Now, a new
      and tested algorithm inverts the device-order on the SCSI-bus and
      automatically avoids accidental access to whatever SCSI PUN the adapter
      is set and works with SCSI- and Wide-SCSI-addressing.
   - Michael Lang

   July 23, 2000 (v3.2pre10 unpublished)
   1) LED panel display supports wide-addressing in ibmmca=display mode.
   2) Adapter-information and autoadaption to address-space is done.
   3) Auto-probing for maximum synchronous SCSI transfer rate is working.
   4) Optimization to some embedded function calls is applied.
   5) Added some comment for the user to wait for SCSI-devices beeing probed.
   6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but...
   - Michael Lang

   July 26, 2000 (v3.2pre11)
   1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
      a model 9595. Asking around in the community, nobody except of me has
      seen such errors. Weired, but I am trying to recompile everything on
      the model 9595. Maybe, as I use a specially modified gcc, that could
      cause problems. But, it was not the reason. The true background was,
      that the kernel was compiled for i386 and the 9595 has a 486DX-2.
      Normally, no troubles should appear, but for this special machine,
      only the right processor support is working fine!
   2) Previous problems with synchronous speed, slowing down from one adapter
      to the next during probing are corrected. Now, local variables store
      the synchronous bitmask for every single adapter found on the MCA bus.
   3) LED alphanumeric panel support for XX95 systems is now showing some
      alive rotator during boottime. This makes sense, when no monitor is
      connected to the system. You can get rid of all display activity, if
      you do not use any parameter or just ibmmcascsi=activity, for the
      harddrive activity LED, existant on all PS/2, except models 8595-XXX.
      If no monitor is available, please use ibmmcascsi=display, which works
      fine together with the linuxinfo utility for the LED-panel.
   - Michael Lang

   July 29, 2000 (v3.2)
   1) Submission of this driver for kernel 2.4test-XX and 2.2.17.
   - Michael Lang

   December 28, 2000 (v3.2d / v4.0)
   1) The interrupt handler had some wrong statement to wait for. This
      was done due to experimental reasons during 3.2 development but it
      has shown that this is not stable enough. Going back to wait for the
      adapter to be not busy is best.
   2) Inquiry requests can be shorter than 255 bytes of return buffer. Due
      to a bug in the ibmmca_queuecommand routine, this buffer was forced
      to 255 at minimum. If the memory address, this return buffer is pointing
      to does not offer more space, invalid memory accesses destabilized the
      kernel.
   3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary
      to remove old kernel version dependant waste from the driver. 3.2d is
      only distributed with older kernels but keeps compatibility with older
      kernel versions. 4.0 and higher versions cannot be used with older
      kernels anymore!! You must have at least kernel 2.4.0!!
   4) The commandline argument 'bypass' and all its functionality got removed
      in version 4.0. This was never really necessary, as all troubles were
      based on non-command related reasons up to now, so bypassing commands
      did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
   5) Dynamical reassignment of ldns was again verified and analyzed to be
      completely inoperational. This is corrected and should work now.
   6) All commands that get sent to the SCSI adapter were verified and
      completed in such a way, that they are now completely conform to the
      demands in the technical description of IBM. Main candidates were the
      DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
      be tranferred by bypassing the internal command buffer of the adapter
      or else the response can be a random result. GET_POS_INFO would be more
      safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
      is not allowed by the technical references of IBM. (Sorry, folks, the
      model 80 problem is still a task to be solved in a different way.)
   7) v3.2d is still hold back for some days for testing, while 4.0 is
      released.
   - Michael Lang

   January 3, 2001 (v4.0a)
   1) A lot of complains after the 2.4.0-prerelease kernel came in about
      the impossibility to compile the driver as a module. This problem is
      solved. In combination with that problem, some unprecise declaration
      of the function option_setup() gave some warnings during compilation.
      This is solved, too by a forward declaration in ibmmca.c.
   2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and
      was entirely removed.
   3) Some switch statements got optimized in code, as some minor variables
      in internal SCSI-command handlers.
   - Michael Lang

   4 To do
   -------
        - IBM SCSI-2 F/W external SCSI bus support in seperate mode!
	- It seems that the handling of bad disks is really bad -
	  non-existent, in fact. However, a low-level driver cannot help
	  much, if such things happen.

   5 Users' Manual
   ---------------
   5.1 Commandline Parameters
   --------------------------
   There exist several features for the IBM SCSI-subsystem driver.
   The commandline parameter format is:

         ibmmcascsi=<command1>,<command2>,<command3>,...

   where commandN can be one of the following:

         display    Owners of a model 95 or other PS/2 systems with an
	            alphanumeric LED display may set this to have their
		    display showing the following output of the 8 digits:

		                ------DA

		    where '-' stays dark, 'D' shows the SCSI-device id
		    and 'A' shows the SCSI hostindex, beeing currently
		    accessed. During boottime, this will give the message

		                SCSIini*

                    on the LED-panel, where the * represents a rotator,
		    showing the activity during the probing phase of the
		    driver which can take up to two minutes per SCSI-adapter.
	 adisplay   This works like display, but gives more optical overview
	            of the activities on the SCSI-bus. The display will have
		    the following output:

		                6543210A

		    where the numbers 0 to 6 light up at the shown position,
		    when the SCSI-device is accessed. 'A' shows again the SCSI
		    hostindex. If display nor adisplay is set, the internal
		    PS/2 harddisk LED is used for media-activities. So, if
		    you really do not have a system with a LED-display, you
		    should not set display or adisplay. Keep in mind, that
		    display and adisplay can only be used alternatively. It
		    is not recommended to use this option, if you have some
		    wide-addressed devices e.g. at the SCSI-2 F/W adapter in
		    your system. In addition, the usage of the display for
		    other tasks in parallel, like the linuxinfo-utility makes
		    no sense with this option.
	 activity   This enables the PS/2 harddisk LED activity indicator.
	            Most PS/2 have no alphanumeric LED display, but some
		    indicator. So you should use this parameter to activate it.
		    If you own model 9595 (Server95), you can have both, the
		    LED panel and the activity indicator in parallel. However,
		    some PS/2s, like the 8595 do not have any harddisk LED
		    activity indicator, which means, that you must use the
		    alphanumeric LED display if you want to monitor SCSI-
		    activity.
	 bypass     This is obsolete from driver version 4.0, as the adapters
	            got that far understood, that the selection between
		    integrated and bypassed commands should now work completely
		    correct! For historical reasons, the old description is
		    kept here:
	            This commandline parameter forces the driver never to use
	            SCSI-subsystems' integrated SCSI-command set. Except of
		    the immediate assign, which is of vital importance for
		    every IBM SCSI-subsystem to set its ldns right. Instead,
		    the ordinary ANSI-SCSI-commands are used and passed by the
		    controller to the SCSI-devices, therefore 'bypass'. The
		    effort, done by the subsystem is quite bogus and at a
		    minimum and therefore it should work everywhere. This
		    could maybe solve troubles with old or integrated SCSI-
		    controllers and nasty harddisks. Keep in mind, that using
		    this flag will slow-down SCSI-accesses slightly, as the
		    software generated commands are always slower than the
		    hardware. Non-harddisk devices always get read/write-
		    commands in bypass mode. On the most recent releases of
		    the Linux IBM-SCSI-driver, the bypass command should be
		    no longer a necessary thing, if you are sure about your
		    SCSI-hardware!
	 normal     This is the parameter, introduced on the 2.0.x development
	            rail by ZP Gu. This parameter defines the SCSI-device
		    scan order in the new industry standard. This means, that
		    the first SCSI-device is the one with the lowest pun.
		    E.g. harddisk at pun=0 is scanned before harddisk at
		    pun=6, which means, that harddisk at pun=0 gets sda
		    and the one at pun=6 gets sdb.
	 ansi       The ANSI-standard for the right scan order, as done by
	            IBM, Microware and Microsoft, scans SCSI-devices starting
		    at the highest pun, which means, that e.g. harddisk at
		    pun=6 gets sda and a harddisk at pun=0 gets sdb. If you
		    like to have the same SCSI-device order, as in DOS, OS-9
		    or OS/2, just use this parameter.
         fast       SCSI-I/O in synchronous mode is done at 5 MHz for IBM-
                    SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus
                    should then run at 10 MHz if Fast-SCSI is enabled,
                    and at 5 MHz if Fast-SCSI is disabled on the external
                    bus. This is the default setting when nothing is
                    specified here.
         medium     Synchronous rate is at 50% approximately, which means
                    2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext.
                    SCSI-bus (when Fast-SCSI speed enabled on external bus).
         slow       The slowest possible synchronous transfer rate is set.
                    This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz
                    for F/W external bus at Fast-SCSI speed on the external
		    bus.

   A further option is that you can force the SCSI-driver to accept a SCSI-
   subsystem at a certain I/O-address with a predefined adapter PUN. This
   is done by entering

                  commandN   = I/O-base
		  commandN+1 = adapter PUN

   e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem
   at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if
   the driver does really not recognize your SCSI-adapter! With driver version
   3.2, this recognition of various adapters was hugely improved and you
   should try first to remove your commandline arguments of such type with a
   newer driver. I bet, it will be recognized correctly. Even multiple and
   different types of IBM SCSI-adapters should be recognized correctly, too.
   Use the forced detection method only as last solution!

   Examples:

        ibmmcascsi=adisplay

   This will use the advanced display mode for the model 95 LED alphanumeric
   display.

        ibmmcascsi=display,0x3558,7

   This will activate the default display mode for the model 95 LED display
   and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558
   with adapter PUN 7.

   5.2 Troubleshooting
   -------------------
   The following FAQs should help you to solve some major problems with this
   driver.

     Q: "Reset SCSI-devices at boottime" halts the system at boottime, why?
     A: This is only tested with the IBM SCSI Adapter w/cache. It is not
        yet prooved to run on other adapters, however you may be lucky.
	In version 3.1d this has been hugely improved and should work better,
	now. Normally you really won't need to activate this flag in the
	kernel configuration, as all post 1989 SCSI-devices should accept
	the reset-signal, when the computer is switched on. The SCSI-
	subsystem generates this reset while beeing initialized. This flag
	is really reserved for users with very old, very strange or self-made
	SCSI-devices.
     Q: Why is the SCSI-order of my drives mirrored to the device-order
        seen from OS/2 or DOS ?
     A: It depends on the operating system, if it looks at the devices in
        ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or
	if it just starts at pun 0 and counts up. If you want to be conform
	with OS/2 and DOS, you have to activate this flag in the kernel
	configuration or you should set 'ansi' as parameter for the kernel.
	The parameter 'normal' sets the new industry standard, starting
	from pun 0, scanning up to pun 6. This allows you to change your
	opinion still after having already compiled the kernel.
     Q: Why I cannot find the IBM MCA SCSI support in the config menue?
     A: You have to activate MCA bus support, first.
     Q: Where can I find the latest info about this driver?
     A: See the file MAINTAINERS for the current WWW-address, which offers
        updates, info and Q/A lists. At this files' origin, the webaddress
	was: http://www.uni-mainz.de/~langm000/linux.html
     Q: My SCSI-adapter is not recognized by the driver, what can I do?
     A: Just force it to be recognized by kernel parameters. See section 5.1.
        If this really happens, do also send e-mail to the maintainer, as
	forced detection should be never necessary. Forced detection is in
	principal some flaw of the driver adapter detection and goes into
	bugreports.
     Q: The driver screws up, if it starts to probe SCSI-devices, is there
        some way out of it?
     A: Yes, that was some recognition problem of the correct SCSI-adapter
        and its I/O base addresses. Upgrade your driver to the latest release
	and it should be fine again.
     Q: I get a message: panic IBM MCA SCSI: command error .... , what can
        I do against this?
     A: Previously, I followed the way by ignoring command errors by using
        ibmmcascsi=forgiveall, but this command no longer exists and is
	obsolete. If such a problem appears, it is caused by some segmentation
	fault of the driver, which maps to some unallowed area. The latest
	version of the driver should be ok, as most bugs have been solved.
     Q: There are still kernel panics, even after having set
        ibmmcascsi=forgiveall. Are there other possibilities to prevent
	such panics?
     A: No, get just the latest release of the driver and it should work
        better and better with increasing version number. Forget about this
	ibmmcascsi=forgiveall, as also ignorecmd are obsolete.!
     Q: Linux panics or stops without any comment, but it is probable, that my
        harddisk(s) have bad blocks.
     A: Sorry, the bad-block handling is still a feeble point of this driver,
        but is on the schedule for development in the near future.
     Q: Linux panics while dynamically assigning SCSI-ids or ldns.
     A: If you disconnect a SCSI-device from the machine, while Linux is up
        and the driver uses dynamical reassignment of logical device numbers
	(ldn), it really gets "angry" if it won't find devices, that were still
	present at boottime and stops Linux.
     Q: The system does not recover after an abort-command has been generated.
     A: This is regrettably true, as it is not yet understood, why the
        SCSI-adapter does really NOT generate any interrupt at the end of
	the abort-command. As no interrupt is generated, the abort command
	cannot get finished and the system hangs, sorry, but checks are
	running to hunt down this problem. If there is a real pending command,
	the interrupt MUST get generated after abort. In this case, it
	should finish well.
     Q: The system gets in bad shape after a SCSI-reset, is this known?
     A: Yes, as there are a lot of prescriptions (see the Linux Hackers'
        Guide) what has to be done for reset, we still share the bad shape of
	the reset functions with all other low level SCSI-drivers.
	Astonishingly, reset works in most cases quite ok, but the harddisks
	won't run in synchonous mode anymore after a reset, until you reboot.
     Q: Why does my XXX w/Cache adapter not use read-prefetch?
     A: Ok, that is not completely possible. If a cache is present, the
        adapter tries to use it internally. Explicitly, one can use the cache
	with a read prefetch command, maybe in future, but this requires
	some major overhead of SCSI-commands that risks the performance to
	go down more than it gets improved. Tests with that are running.
     Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs.
     A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter
        was in such a case recognized as integrated SCSI-adapter or something
	else, but not as the correct adapter. As the I/O-ports get assigned
	wrongly by that reason, the system should crash in most cases. You
	should upgrade to the latest release of the SCSI-driver. The
	recommended version is 3.2 or later. Here, the F/W support is in
	a stable and reliable condition. Wide-addressing is in addition
	supported.
     Q: I get a Ooops message and something like "killing interrupt".
     A: The reason for this is that the IBM SCSI-subsystem only sends a
        termination status back, if some error appeared. In former releases
	of the driver, it was not checked, if the termination status block
	is NULL. From version 3.2, it is taken care of this.
     Q: I have a F/W adapter and the driver sees my internal SCSI-devices,
        but ignores the external ones.
     A: Select combined busmode in the IBM config-program and check for that
        no SCSI-id on the external devices appears on internal devices.
        Reboot afterwards. Dual busmode is supported, but works only for the
	internal bus, yet. External bus is still ignored. Take care for your
	SCSI-ids. If combined bus-mode is activated, on some adapters,
	the wide-addressing is not possible, so devices with ids between 8
	and 15 get ignored by the driver & adapter!
     Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck.
        A COMMAND ERROR is reported and characters on the screen are missing.
	Warm reboot is not possible. Things look like quite weired.
     A: Check the processor type of your 9595. If you have an 80486 or 486DX-2
        processor complex on your mainboard and you compiled a kernel that
	supports 80386 processors, it is possible, that the kernel cannot
	keep track of the PS/2 interrupt handling and stops on an NMI. Just
	compile a kernel for the correct processor type of your PS/2 and
	everything should be fine. This is necessary even if one assumes,
	that some 80486 system should be downward compatible to 80386
	software.
     Q: Some commands hang and interrupts block the machine. After some
        timeout, the syslog reports that it tries to call abort, but the
	machine is frozen.
     A: This can be a busy wait bug in the interrupt handler of driver
        version 3.2. You should at least upgrade to 3.2c if you use
	kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or
	later (including all test releases).
     Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver
        completely refuses to work, reports NMIs, COMMAND ERRORs or other
	ambiguous stuff. When reducing the RAM size down below 16 MB,
	everything is running smoothly.
     A: No real answer, yet. In any case, one should force the kernel to
        present SCBs only below the 16 MBytes barrier. Maybe this solves the
	problem. Not yet tried, but guessing that it could work. To get this,
	set unchecked_isa_dma argument of ibmmca.h from 0 to 1.

   5.3 Bugreports
   --------------
   If you really find bugs in the sourcecode or the driver will successfully
   refuse to work on your machine, you should send a bug report to me. The
   best for this is to follow the instructions on the WWW-page for this
   driver. Fill out the bug-report form, placed on the WWW-page and ship it,
   so the bugs can be taken into account with maximum efforts. But, please
   do not send bug reports about this driver to Linus Torvalds or Leonard
   Zubkoff, as Linus is burried in E-Mail and Leonard is supervising all
   SCSI-drivers and won't have the time left to look inside every single
   driver to fix a bug and especially DO NOT send modified code to Linus
   Torvalds or Alan J. Cox which has not been checked here!!! They are both
   quite burried in E-mail (as me, sometimes, too) and one should first check
   for problems on my local teststand. Recently, I got a lot of
   bugreports for errors in the ibmmca.c code, which I could not imagine, but
   a look inside some Linux-distribution showed me quite often some modified
   code, which did no longer work on most other machines than the one of the
   modifier. Ok, so now that there is maintenance service available for this
   driver, please use this address first in order to keep the level of
   confusion low. Thank you!

   When you get a SCSI-error message that panics your system, a list of
   register-entries of the SCSI-subsystem is shown (from Version 3.1d). With
   this list, it is very easy for the maintainer to localize the problem in
   the driver or in the configuration of the user. Please write down all the
   values from this report and send them to the maintainer. This would really
   help a lot and makes life easier concerning misunderstandings.

   Use the bug-report form (see 5.4 for its address) to send all the bug-
   stuff to the maintainer or write e-mail with the values from the table.

   5.4 Support WWW-page
   --------------------
   The address of the IBM SCSI-subsystem supporting WWW-page is:

        http://www.uni-mainz.de/~langm000/linux.html

   Here you can find info about the background of this driver, patches,
   troubleshooting support, news and a bugreport form. Please check that
   WWW-page regularly for latest hints. If ever this URL changes, please
   refer to the MAINTAINERS file in order to get the latest address.

   For the bugreport, please fill out the formular on the corresponding
   WWW-page. Read the dedicated instructions and write as much as you
   know about your problem. If you do not like such formulars, please send
   some e-mail directly, but at least with the same information as required by
   the formular.

   If you have extensive bugreports, including Ooops messages and
   screen-shots, please feel free to send it directly to the address
   of the maintainer, too. The current address of the maintainer is:

            Michael Lang <langa2@kph.uni-mainz.de>

   6 References
   ------------
   IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference,
   Common Interfaces", Armonk, September 1991, PN 04G3281,
   (available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for
   around 40,-DM at "Hallo IBM").

   IBM Corp., "Personal System/2 Micro Channel SCSI
   Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365.

   IBM Corp., "Personal System/2 Micro Channel SCSI
   Adapter Technical Reference", Armonk, March 1990, PN 68X2397.

   IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus",
   Armonk, March 1994, PN 83G7545.

   Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie-
   Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl.
   Addison Wesley, 1996.

   Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel
   Hill - North Carolina, 1995

   Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart
   1993

   Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme *
   Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988

   7 Credits to
   ------------
   7.1 People
   ----------
   Klaus Grimm
                who already a long time ago gave me the old code from the
		SCSI-driver in order to get it running for some old machine
		in our institute.
   Martin Kolinek
                who wrote the first release of the IBM SCSI-subsystem driver.
   Chris Beauregard
                who for a long time maintained MCA-Linux and the SCSI-driver
		in the beginning. Chris, wherever you are: Cheers to you!
   Klaus Kudielka
                with whom in the 2.1.x times, I had a quite fruitful
                cooperation to get the driver running as a module and to get
		it running with multiple SCSI-adapters.
   David Weinehall
                for his excellent maintenance of the MCA-stuff and the quite
		detailed bug reports and ideas for this driver (and his
		patience ;-)).
   Alan J. Cox
                for his bugreports and his bold activities in cross-checking
		the driver-code with his teststand.

   7.2 Sponsors & Supporters
   -------------------------
   "Hallo IBM",
   IBM-Deutschland GmbH
                the service of IBM-Deutschland for customers. Their E-Mail
		service is unbeatable. Whatever old stuff I asked for, I
		always got some helpful answers.
   Karl-Otto Reimers,
   IBM Klub - Sparte IBM Geschichte, Sindelfingen
                for sending me a copy of the w/Cache manual from the
		IBM-Deutschland archives.
   Harald Staiger
                for his extensive hardware donations which allows me today
		still to test the driver in various constellations.
   Erich Fritscher
                for his very kind sponsoring.
   Louis Ohland,
   Charles Lasitter
                for support by shipping me an IBM SCSI-2 Fast/Wide manual.
                In addition, the contribution of various hardware is quite
                decessive and will make it possible to add FWSR (RAID)
                adapter support to the driver in the near future! So,
                complaints about no RAID support won't remain forever.
                Yes, folks, that is no joke, RAID support is going to rise!
   Erik Weber
                for the great deal we made about a model 9595 and the nice
                surrounding equipment and the cool trip to Mannheim
                second-hand computer market. In addition, I would like
		to thank him for his exhaustive SCSI-driver testing on his
		95er PS/2 park.
   Anthony Hogbin
                for his direct shipment of a SCSI F/W adapter, which allowed
                me immediately on the first stage to try it on model 8557
                together with onboard SCSI adapter and some SCSI w/Cache.
   Andreas Hotz
                for his support by memory and an IBM SCSI-adapter. Collecting
                all this together now allows me to try really things with
                the driver at maximum load and variety on various models in
                a very quick and efficient way.
   Peter Jennewein
                for his model 30, which serves me as part of my teststand
		and his cool remark about how you make an ordinary diskette
		drive working and how to connect it to an IBM-diskette port.
   Johannes Gutenberg-Universitaet, Mainz &
   Institut fuer Kernphysik, Mainz Microtron (MAMI)
                for the offered space, the link, placed on the central
                homepage and the space to store and offer the driver and
		related material and the free working times, which allow
                me to answer all your e-mail.

   8 Trademarks
   ------------
   IBM, PS/2, OS/2, Microchannel are registered trademarks of International
   Business Machines Corporation

   MS-DOS is a registered trademark of Microsoft Corporation

   Microware, OS-9 are registered trademarks of Microware Systems

   9 Disclaimer
   ------------
   Beside the GNU General Public License and the dependant disclaimers and disclaimers
   concerning the Linux-kernel in special, this SCSI-driver comes without any
   warranty. Its functionality is tested as good as possible on certain
   machines and combinations of computer hardware, which does not exclude,
   that dataloss or severe damage of hardware is possible while using this
   part of software on some arbitrary computer hardware or in combination
   with other software packages. It is highly recommended to make backup
   copies of your data before using this software. Furthermore, personal
   injuries by hardware defects, that could be caused by this SCSI-driver are
   not excluded and it is highly recommended to handle this driver with a
   maximum of carefulness.

   This driver supports hardware, produced by International Business Machines
   Corporation (IBM).

------
Michael Lang
(langa2@kph.uni-mainz.de)

UPDATE NEWS: version 1.33 - 26 Aug 98

   Interrupt management in this driver has become, over
   time, increasingly odd and difficult to explain - this
   has been mostly due to my own mental inadequacies. In
   recent kernels, it has failed to function at all when
   compiled for SMP. I've fixed that problem, and after
   taking a fresh look at interrupts in general, greatly
   reduced the number of places where they're fiddled
   with. Done some heavy testing and it looks very good.
   The driver now makes use of the __initfunc() and
   __initdata macros to save about 4k of kernel memory.
   Once again, the same code works for both 2.0.xx and
   2.1.xx kernels.

UPDATE NEWS: version 1.32 - 28 Mar 98

   Removed the check for legal IN2000 hardware versions:
   It appears that the driver works fine with serial
   EPROMs (the 8-pin chip that defines hardware rev) as
   old as 2.1, so we'll assume that all cards are OK.

UPDATE NEWS: version 1.31 - 6 Jul 97

   Fixed a bug that caused incorrect SCSI status bytes to be
   returned from commands sent to LUN's greater than 0. This
   means that CDROM changers work now! Fixed a bug in the
   handling of command-line arguments when loaded as a module.
   Also put all the header data in in2000.h where it belongs.
   There are no longer any differences between this driver in
   the 2.1.xx source tree and the 2.0.xx tree, as of 2.0.31
   and 2.1.45 (or is it .46?) - this makes things much easier
   for me...

UPDATE NEWS: version 1.30 - 14 Oct 96

   Fixed a bug in the code that sets the transfer direction
   bit (DESTID_DPD in the WD_DESTINATION_ID register). There
   are quite a few SCSI commands that do a write-to-device;
   now we deal with all of them correctly. Thanks to Joerg
   Dorchain for catching this one.

UPDATE NEWS: version 1.29 - 24 Sep 96

   The memory-mapped hardware on the card is now accessed via
   the 'readb()' and 'readl()' macros - required by the new
   memory management scheme in the 2.1.x kernel series.
   As suggested by Andries Brouwer, 'bios_param()' no longer
   forces an artificial 1023 track limit on drives. Also
   removed some kludge-code left over from struggles with
   older (buggy) compilers.

UPDATE NEWS: version 1.28 - 07 May 96

   Tightened up the "interrupts enabled/disabled" discipline
   in 'in2000_queuecommand()' and maybe 1 or 2 other places.
   I _think_ it may have been a little too lax, causing an
   occasional crash during full moon. A fully functional
   /proc interface is now in place - if you want to play
   with it, start by doing 'cat /proc/scsi/in2000/0'. You
   can also use it to change a few run-time parameters on
   the fly, but it's mostly for debugging. The curious
   should take a good look at 'in2000_proc_info()' in the
   in2000.c file to get an understanding of what it's all
   about; I figure that people who are really into it will
   want to add features suited to their own needs...
   Also, sync is now DISABLED by default.

UPDATE NEWS: version 1.27 - 10 Apr 96

   Fixed a well-hidden bug in the adaptive-disconnect code
   that would show up every now and then during extreme
   heavy loads involving 2 or more simultaneously active
   devices. Thanks to Joe Mack for keeping my nose to the
   grindstone on this one.

UPDATE NEWS: version 1.26 - 07 Mar 96

   1.25 had a nasty bug that bit people with swap partitions
   and tape drives. Also, in my attempt to guess my way
   through Intel assembly language, I made an error in the
   inline code for IO writes. Made a few other changes and
   repairs - this version (fingers crossed) should work well.

UPDATE NEWS: version 1.25 - 05 Mar 96

   Kernel 1.3.70 interrupt mods added; old kernels still OK.
   Big help from Bill Earnest and David Willmore on speed
   testing and optimizing: I think there's a real improvement
   in this area.
   New! User-friendly command-line interface for LILO and
   module loading - the old method is gone, so you'll need
   to read the comments for 'setup_strings' near the top
   of in2000.c. For people with CDROM's or other devices
   that have a tough time with sync negotiation, you can
   now selectively disable sync on individual devices -
   search for the 'nosync' keyword in the command-line
   comments. Some of you disable the BIOS on the card, which
   caused the auto-detect function to fail; there is now a
   command-line option to force detection of a ROM-less card.

UPDATE NEWS: version 1.24a - 24 Feb 96

   There was a bug in the synchronous transfer code. Only
   a few people downloaded before I caught it - could have
   been worse.

UPDATE NEWS: version 1.24 - 23 Feb 96

   Lots of good changes. Advice from Bill Earnest resulted
   in much better detection of cards, more efficient usage
   of the fifo, and (hopefully) faster data transfers. The
   jury is still out on speed - I hope it's improved some.
   One nifty new feature is a cool way of doing disconnect/
   reselect. The driver defaults to what I'm calling
   'adaptive disconnect' - meaning that each command is
   evaluated individually as to whether or not it should be
   run with the option to disconnect/reselect (if the device
   chooses), or as a "SCSI-bus-hog". When several devices
   are operating simultaneously, disconnects are usually an
   advantage. In a single device system, or if only 1 device
   is being accessed, transfers usually go faster if disconnects
   are not allowed.



The default arguments (you get these when you don't give an 'in2000'
command-line argument, or you give a blank argument) will cause
the driver to do adaptive disconnect, synchronous transfers, and a
minimum of debug messages. If you want to fool with the options,
search for 'setup_strings' near the top of the in2000.c file and
check the 'hostdata->args' section in in2000.h - but be warned! Not
everything is working yet (some things will never work, probably).
I believe that disabling disconnects (DIS_NEVER) will allow you
to choose a LEVEL2 value higher than 'L2_BASIC', but I haven't
spent a lot of time testing this. You might try 'ENABLE_CLUSTERING'
to see what happens: my tests showed little difference either way.
There's also a define called 'DEFAULT_SX_PER'; this sets the data
transfer speed for the asynchronous mode. I've put it at 500 ns
despite the fact that the card could handle settings of 376 or
252, because higher speeds may be a problem with poor quality
cables or improper termination; 500 ns is a compromise. You can
choose your own default through the command-line with the
'period' keyword.


------------------------------------------------
***********  DIP switch settings  **************
------------------------------------------------

   sw1-1 sw1-2    BIOS address (hex)
   -----------------------------------------
    off   off     C8000 - CBFF0
    on    off     D8000 - DBFF0
    off   on      D0000 - D3FF0
    on    on      BIOS disabled

   sw1-3 sw1-4    IO port address (hex)
   ------------------------------------
    off   off     220 - 22F
    on    off     200 - 20F
    off   on      110 - 11F
    on    on      100 - 10F

   sw1-5 sw1-6 sw1-7    Interrupt
   ------------------------------
    off   off   off     15
    off   on    off     14
    off   off   on      11
    off   on    on      10
    on    -     -       disabled

   sw1-8 function depends on BIOS version. In earlier versions this
   controlled synchronous data transfer support for MSDOS:
      off = disabled
      on  = enabled
   In later ROMs (starting with 01.3 in April 1994) sw1-8 controls
   the "greater than 2 disk drive" feature that first appeared in
   MSDOS 5.0 (ignored by Linux):
      off = 2 drives maximum
      on  = 7 drives maximum

   sw1-9    Floppy controller
   --------------------------
    off     disabled
    on      enabled

------------------------------------------------

   I should mention that Drew Eckhardt's 'Generic NCR5380' sources
   were my main inspiration, with lots of reference to the IN2000
   driver currently distributed in the kernel source. I also owe
   much to a driver written by Hamish Macdonald for Linux-m68k(!).
   And to Eric Wright for being an ALPHA guinea pig. And to Bill
   Earnest for 2 tons of great input and information. And to David
   Willmore for extensive 'bonnie' testing. And to Joe Mack for
   continual testing and feedback.


            John Shifflett    jshiffle@netcom.com

README for WarpEngine/A4000T/A4091 SCSI kernels.

Use the following options to disable options in the SCSI driver.

Using amiboot for example.....

To disable Synchronous Negotiation....

	amiboot -k kernel 53c7xx=nosync:0

To disable Disconnection....

	amiboot -k kernel 53c7xx=nodisconnect:0

To disable certain SCSI devices...

	amiboot -k kernel 53c7xx=validids:0x3F

	this allows only device ID's 0,1,2,3,4 and 5 for linux to handle.
	(this is a bitmasked field - i.e. each bit represents a SCSI ID)

These commands work on a per controller basis and use the option 'next' to
move to the next controller in the system.

e.g.
	amiboot -k kernel 53c7xx=nodisconnect:0,next,nosync:0

	this uses No Disconnection on the first controller and Asynchronous
	SCSI on the second controller.

Known Issues:

Two devices are known not to function with the default settings of using
synchronous SCSI. These are the Archive Viper 150 Tape Drive and the
SyQuest SQ555 removeable hard drive. When using these devices on a controller
use the 'nosync:0' option.

Please try these options and post any problems/successes to me.

Alan Hourihane <alanh@fairlite.demon.co.uk>

The Linux NCR53C8XX/SYM53C8XX drivers README file

Written by Gerard Roudier <groudier@free.fr>
21 Rue Carnot
95170 DEUIL LA BARRE - FRANCE

29 May 1999
===============================================================================

1.  Introduction
2.  Supported chips and SCSI features
3.  Advantages of the enhanced 896 driver
      3.1 Optimized SCSI SCRIPTS
      3.2 New features of the SYM53C896 (64 bit PCI dual LVD SCSI controller)
4.  Memory mapped I/O versus normal I/O
5.  Tagged command queueing
6.  Parity checking
7.  Profiling information
8.  Control commands
      8.1  Set minimum synchronous period
      8.2  Set wide size
      8.3  Set maximum number of concurrent tagged commands
      8.4  Set order type for tagged command
      8.5  Set debug mode
      8.6  Clear profile counters
      8.7  Set flag (no_disc)
      8.8  Set verbose level
      8.9  Reset all logical units of a target
      8.10 Abort all tasks of all logical units of a target
9.  Configuration parameters
10. Boot setup commands
      10.1 Syntax
      10.2 Available arguments
             10.2.1  Master parity checking
             10.2.2  Scsi parity checking
             10.2.3  Scsi disconnections
             10.2.4  Special features
             10.2.5  Ultra SCSI support
             10.2.6  Default number of tagged commands
             10.2.7  Default synchronous period factor
             10.2.8  Negotiate synchronous with all devices
             10.2.9  Verbosity level
             10.2.10 Debug mode
             10.2.11 Burst max
             10.2.12 LED support
             10.2.13 Max wide
             10.2.14 Differential mode
             10.2.15 IRQ mode
             10.2.16 Reverse probe
             10.2.17 Fix up PCI configuration space
             10.2.18 Serial NVRAM
             10.2.19 Check SCSI BUS
             10.2.20 Exclude a host from being attached
             10.2.21 Suggest a default SCSI id for hosts
             10.2.22 Enable use of IMMEDIATE ARBITRATION
      10.3 Advised boot setup commands
      10.4 PCI configuration fix-up boot option
      10.5 Serial NVRAM support boot option
      10.6 SCSI BUS checking boot option
      10.7 IMMEDIATE ARBITRATION boot option
11. Some constants and flags of the ncr53c8xx.h header file
12. Installation
13. Architecture dependent features
14. Known problems
      14.1 Tagged commands with Iomega Jaz device
      14.2 Device names change when another controller is added
      14.3 Using only 8 bit devices with a WIDE SCSI controller.
      14.4 Possible data corruption during a Memory Write and Invalidate
      14.5 IRQ sharing problems
15. SCSI problem troubleshooting
      15.1 Problem tracking
      15.2 Understanding hardware error reports
16. Synchonous transfer negotiation tables
      16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers
      16.2 Synchronous timings for fast SCSI-2 53C8XX controllers
17. Serial NVRAM support (by Richard Waltham)
      17.1 Features
      17.2 Symbios NVRAM layout
      17.3 Tekram  NVRAM layout
18. Support for Big Endian
      18.1 Big Endian CPU
      18.2 NCR chip in Big Endian mode of operations

===============================================================================

1. Introduction

The initial Linux ncr53c8xx driver has been a port of the ncr driver from
FreeBSD that has been achieved in November 1995 by:
          Gerard Roudier              <groudier@free.fr>

The original driver has been written for 386bsd and FreeBSD by:
          Wolfgang Stanglmeier        <wolf@cologne.de>
          Stefan Esser                <se@mi.Uni-Koeln.de>

It is now available as a bundle of 2 drivers:

- ncr53c8xx generic driver that supports all the SYM53C8XX family including
  the ealiest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and
  the new 895A (1 channel LVD SCSI controller).
- sym53c8xx enhanced driver (a.k.a. 896 drivers) that drops support of oldest
  chips in order to gain advantage of new features, as LOAD/STORE intructions
  available since the 810A and hardware phase mismatch available with the
  896 and the 895A.

You can find technical information about the NCR 8xx family in the
PCI-HOWTO written by Michael Will and in the SCSI-HOWTO written by
Drew Eckhardt.

Information about new chips is available at LSILOGIC web server:

          http://www.lsilogic.com/

SCSI standard documentations are available at SYMBIOS ftp server:

          ftp://ftp.symbios.com/

Usefull SCSI tools written by Eric Youngdale are available at tsx-11:

          ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
          ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz

These tools are not ALPHA but quite clean and work quite well.
It is essential you have the 'scsiinfo' package.

This short documentation describes the features of the generic and enhanced
drivers, configuration parameters and control commands available through
the proc SCSI file system read / write operations.

This driver has been tested OK with linux/i386, Linux/Alpha and Linux/PPC.

Latest driver version and patches are available at:

          ftp://ftp.tux.org/pub/people/gerard-roudier
or
          ftp://ftp.symbios.com/mirror/ftp.tux.org/pub/tux/roudier/drivers

I am not a native speaker of English and there are probably lots of
mistakes in this README file. Any help will be welcome.


2. Supported chips and SCSI features

The following features are supported for all chips:

	Synchronous negotiation
	Disconnection
	Tagged command queuing
	SCSI parity checking
	Master parity checking

"Wide negotiation" is supported for chips that allow it.  The
following table shows some characteristics of NCR 8xx family chips
and what drivers support them.

                                                  Supported by   Supported by
       On board                                   the generic    the enhanced
Chip   SDMS BIOS   Wide   SCSI std.   Max. sync   driver         driver
----   ---------   ----   ---------   ----------  ------------   -------------
810        N         N      FAST10    10 MB/s        Y             N
810A       N         N      FAST10    10 MB/s        Y             Y
815        Y         N      FAST10    10 MB/s        Y             N
825        Y         Y      FAST10    20 MB/s        Y             N
825A       Y         Y      FAST10    20 MB/s        Y             Y
860        N         N      FAST20    20 MB/s        Y             Y
875        Y         Y      FAST20    40 MB/s        Y             Y
876        Y         Y      FAST20    40 MB/s        Y             Y
895        Y         Y      FAST40    80 MB/s        Y             Y
895A       Y         Y      FAST40    80 MB/s        Y             Y
896        Y         Y      FAST40    80 MB/s        Y             Y
897        Y         Y      FAST40    80 MB/s        Y             Y
1510D      Y         Y      FAST40    80 MB/s        Y             Y
1010       Y         Y      FAST80   160 MB/s        N             Y
1010_66*   Y         Y      FAST80   160 MB/s        N             Y

* Chip supports 33MHz and 66MHz PCI buses.


Summary of other supported features:

Module:                allow to load the driver
Memory mapped I/O:     increases performance
Profiling information: read operations from the proc SCSI file system
Control commands:      write operations to the proc SCSI file system
Debugging information: written to syslog (expert only)
Scatter / gather
Shared interrupt
Boot setup commands
Serial NVRAM:          Symbios and Tekram formats


3. Advantages of the enhanced 896 driver

3.1 Optimized SCSI SCRIPTS.

The 810A, 825A, 875, 895, 896 and 895A support new SCSI SCRIPTS instructions
named LOAD and STORE that allow to move up to 1 DWORD from/to an IO register
to/from memory much faster that the MOVE MEMORY instruction that is supported
by the 53c7xx and 53c8xx family.
The LOAD/STORE instructions support absolute and DSA relative addressing
modes.  The SCSI SCRIPTS had been entirely rewritten using LOAD/STORE instead
of MOVE MEMORY instructions.

3.2 New features of the SYM53C896 (64 bit PCI dual LVD SCSI controller)

The 896 and the 895A allows handling of the phase mismatch context from
SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor
until the C code has saved the context of the transfer).
Implementing this without using LOAD/STORE instructions would be painfull
and I did'nt even want to try it.

The 896 chip supports 64 bit PCI transactions and addressing, while the
895A supports 32 bit PCI transactions and 64 bit addressing.
The SCRIPTS processor of these chips is not true 64 bit, but uses segment
registers for bit 32-63. Another interesting feature is that LOAD/STORE
instructions that address the on-chip RAM (8k) remain internal to the chip.

Due to the use of LOAD/STORE SCRIPTS instructions, this driver does not
support the following chips:
- SYM53C810 revision < 0x10 (16)
- SYM53C815 all revisions
- SYM53C825 revision < 0x10 (16)

4. Memory mapped I/O versus normal I/O

Memory mapped I/O has less latency than normal I/O.  Since
linux-1.3.x, memory mapped I/O is used rather than normal I/O.  Memory
mapped I/O seems to work fine on most hardware configurations, but
some poorly designed motherboards may break this feature.

The configuration option CONFIG_SCSI_NCR53C8XX_IOMAPPED forces the
driver to use normal I/O in all cases.


5. Tagged command queueing

Queuing more than 1 command at a time to a device allows it to perform
optimizations based on actual head positions and its mechanical
characteristics. This feature may also reduce average command latency.
In order to really gain advantage of this feature, devices must have
a reasonnable cache size (No miracle is to be expected for a low-end
hard disk with 128 KB or less).
Some kown SCSI devices do not properly support tagged command queuing.
Generally, firmware revisions that fix this kind of problems are available
at respective vendor web/ftp sites.
All I can say is that the hard disks I use on my machines behave well with
this driver with tagged command queuing enabled:

- IBM S12 0662
- Conner 1080S
- Quantum Atlas I
- Quantum Atlas II

If your controller has NVRAM, you can configure this feature per target
from the user setup tool. The Tekram Setup program allows to tune the
maximum number of queued commands up to 32. The Symbios Setup only allows
to enable or disable this feature.

The maximum number of simultaneous tagged commands queued to a device
is currently set to 8 by default.  This value is suitable for most SCSI
disks.  With large SCSI disks (>= 2GB, cache >= 512KB, average seek time
<= 10 ms), using a larger value may give better performances.

The sym53c8xx driver supports up to 255 commands per device, and the
generic ncr53c8xx driver supports up to 64, but using more than 32 is
generally not worth-while, unless you are using a very large disk or disk
array. It is noticeable that most of recent hard disks seem not to accept
more than 64 simultaneous commands. So, using more than 64 queued commands
is probably just resource wasting.

If your controller does not have NVRAM or if it is managed by the SDMS
BIOS/SETUP, you can configure tagged queueing feature and device queue
depths from the boot command-line. For example:

  ncr53c8xx=tags:4/t2t3q15-t4q7/t1u0q32

will set tagged commands queue depths as follow:

- target 2  all luns  on controller 0 --> 15
- target 3  all luns  on controller 0 --> 15
- target 4  all luns  on controller 0 -->  7
- target 1  lun 0     on controller 1 --> 32
- all other target/lun                -->  4

In some special conditions, some SCSI disk firmwares may return a
QUEUE FULL status for a SCSI command. This behaviour is managed by the
driver using the following heuristic:

- Each time a QUEUE FULL status is returned, tagged queue depth is reduced
  to the actual number of disconnected commands.

- Every 1000 successfully completed SCSI commands, if allowed by the
  current limit, the maximum number of queueable commands is incremented.

Since QUEUE FULL status reception and handling is resource wasting, the
driver notifies by default this problem to user by indicating the actual
number of commands used and their status, as well as its decision on the
device queue depth change.
The heuristic used by the driver in handling QUEUE FULL ensures that the
impact on performances is not too bad. You can get rid of the messages by
setting verbose level to zero, as follow:

1st method: boot your system using 'ncr53c8xx=verb:0' option.
2nd method: apply "setverbose 0" control command to the proc fs entry
            corresponding to your controller after boot-up.

6. Parity checking

The driver supports SCSI parity checking and PCI bus master parity
checking.  These features must be enabled in order to ensure safe data
transfers.  However, some flawed devices or mother boards will have
problems with parity. You can disable either PCI parity or SCSI parity
checking by entering appropriate options from the boot command line.
(See 10: Boot setup commands).

7. Profiling information

Profiling information is available through the proc SCSI file system.
Since gathering profiling information may impact performances, this
feature is disabled by default and requires a compilation configuration
option to be set to Y.

The device associated with a host has the following pathname:

          /proc/scsi/ncr53c8xx/N     (N=0,1,2 ....)

Generally, only 1 board is used on hardware configuration, and that device is:
          /proc/scsi/ncr53c8xx/0

However, if the driver has been made as module, the number of the
hosts is incremented each time the driver is loaded.

In order to display profiling information, just enter:

         cat /proc/scsi/ncr53c8xx/0

and you will get something like the following text:

-------------------------------------------------------
General information:
  Chip NCR53C810, device id 0x1, revision id 0x2
  IO port address 0x6000, IRQ number 10
  Using memory mapped IO at virtual address 0x282c000
  Synchronous transfer period 25, max commands per lun 4
Profiling information:
  num_trans    = 18014
  num_kbytes   = 671314
  num_disc     = 25763
  num_break    = 1673
  num_int      = 1685
  num_fly      = 18038
  ms_setup     = 4940
  ms_data      = 369940
  ms_disc      = 183090
  ms_post      = 1320
-------------------------------------------------------

General information is easy to understand. The device ID and the
revision ID identify the SCSI chip as follows:

Chip    Device id     Revision Id
----    ---------     -----------
810       0x1            <  0x10
810A      0x1            >= 0x10
815       0x4
825       0x3            <  0x10
860       0x6
825A      0x3            >= 0x10
875       0xf
895       0xc

The profiling information is updated upon completion of SCSI commands.
A data structure is allocated and zeroed when the host adapter is
attached. So, if the driver is a module, the profile counters are
cleared each time the driver is loaded.  The "clearprof" command
allows you to clear these counters at any time.

The following counters are available:

("num" prefix means "number of",
"ms" means milli-seconds)

num_trans
	Number of completed commands
	Example above: 18014 completed commands

num_kbytes
	Number of kbytes transferred
	Example above: 671 MB transferred

num_disc
	Number of SCSI disconnections
	Example above: 25763 SCSI disconnections

num_break
	number of script interruptions (phase mismatch)
	Example above: 1673 script interruptions

num_int
	Number of interrupts other than "on the fly"
	Example above: 1685 interruptions not "on the fly"

num_fly
	Number of interrupts "on the fly"
	Example above: 18038 interruptions "on the fly"

ms_setup
	Elapsed time for SCSI commands setups
	Example above: 4.94 seconds

ms_data
	Elapsed time for data transfers
	Example above: 369.94 seconds spent for data transfer

ms_disc
	Elapsed time for SCSI disconnections
	Example above: 183.09 seconds spent disconnected

ms_post
	Elapsed time for command post processing
	(time from SCSI status get to command completion call)
	Example above: 1.32 seconds spent for post processing

Due to the 1/100 second tick of the system clock, "ms_post" time may
be wrong.

In the example above, we got 18038 interrupts "on the fly" and only
1673 script breaks generally due to disconnections inside a segment
of the scatter list.


8. Control commands

Control commands can be sent to the driver with write operations to
the proc SCSI file system. The generic command syntax is the
following:

      echo "<verb> <parameters>" >/proc/scsi/ncr53c8xx/0
      (assumes controller number is 0)

Using "all" for "<target>" parameter with the commands below will
apply to all targets of the SCSI chain (except the controller).

Available commands:

8.1 Set minimum synchronous period factor

    setsync <target> <period factor>

    target:    target number
    period:    minimum synchronous period.
               Maximum speed = 1000/(4*period factor) except for special
               cases below.

    Specify a period of 255, to force asynchronous transfer mode.

      10 means 25 nano-seconds synchronous period
      11 means 30 nano-seconds synchronous period
      12 means 50 nano-seconds synchronous period

8.2 Set wide size

    setwide <target> <size>

    target:    target number
    size:      0=8 bits, 1=16bits

8.3 Set maximum number of concurrent tagged commands

    settags <target> <tags>

    target:    target number
    tags:      number of concurrent tagged commands
               must not be greater than SCSI_NCR_MAX_TAGS (default: 8)

8.4 Set order type for tagged command

    setorder <order>

    order:     3 possible values:
               simple: use SIMPLE TAG for all operations (read and write)
               ordered: use ORDERED TAG for all operations
               default: use default tag type,
                        SIMPLE  TAG for read  operations
                        ORDERED TAG for write operations


8.5 Set debug mode

    setdebug <list of debug flags>

    Available debug flags:
        alloc:   print info about memory allocations (ccb, lcb)
        queue:   print info about insertions into the command start queue
        result:  print sense data on CHECK CONDITION status
        scatter: print info about the scatter process
        scripts: print info about the script binding process
	tiny:    print minimal debugging information
	timing:  print timing information of the NCR chip
	nego:    print information about SCSI negotiations
	phase:   print information on script interruptions

    Use "setdebug" with no argument to reset debug flags.


8.6 Clear profile counters

    clearprof

    The profile counters are automatically cleared when the amount of
    data transferred reaches 1000 GB in order to avoid overflow.
    The "clearprof" command allows you to clear these counters at any time.


8.7 Set flag (no_disc)

    setflag <target> <flag>

    target:    target number

    For the moment, only one flag is available:

        no_disc:   not allow target to disconnect.

    Do not specify any flag in order to reset the flag. For example:
    - setflag 4
      will reset no_disc flag for target 4, so will allow it disconnections.
    - setflag all
      will allow disconnection for all devices on the SCSI bus.


8.8 Set verbose level

    setverbose #level

    The driver default verbose level is 1. This command allows to change
    th driver verbose level after boot-up.

8.9 Reset all logical units of a target

    resetdev <target>

    target:    target number
    The driver will try to send a BUS DEVICE RESET message to the target.
    (Only supported by the SYM53C8XX driver and provided for test purpose)

8.10 Abort all tasks of all logical units of a target

    cleardev <target>

    target:    target number
    The driver will try to send a ABORT message to all the logical units
    of the target.
    (Only supported by the SYM53C8XX driver and provided for test purpose)


9. Configuration parameters

If the firmware of all your devices is perfect enough, all the
features supported by the driver can be enabled at start-up.  However,
if only one has a flaw for some SCSI feature, you can disable the
support by the driver of this feature at linux start-up and enable
this feature after boot-up only for devices that support it safely.

CONFIG_SCSI_NCR53C8XX_PROFILE_SUPPORT  (default answer: n)
    This option must be set for profiling information to be gathered
    and printed out through the proc file system. This features may
    impact performances.

CONFIG_SCSI_NCR53C8XX_IOMAPPED       (default answer: n)
    Answer "y" if you suspect your mother board to not allow memory mapped I/O.
    May slow down performance a little.  This option is required by
    Linux/PPC and is used no matter what you select here.  Linux/PPC
    suffers no performance loss with this option since all IO is memory
    mapped anyway.

CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS    (default answer: 8)
    Default tagged command queue depth.

CONFIG_SCSI_NCR53C8XX_MAX_TAGS         (default answer: 8)
    This option allows you to specify the maximum number of tagged commands
    that can be queued to a device. The maximum supported value is 32.

CONFIG_SCSI_NCR53C8XX_SYNC            (default answer: 5)
    This option allows you to specify the frequency in MHz the driver
    will use at boot time for synchronous data transfer negotiations.
    This frequency can be changed later with the "setsync" control command.
    0 means "asynchronous data transfers".

CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO (default answer: n)
    Force synchronous negotiation for all SCSI-2 devices.
    Some SCSI-2 devices do not report this feature in byte 7 of inquiry
    response but do support it properly (TAMARACK scanners for example).

CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT   (default and only reasonnable answer: n)
    If you suspect a device of yours does not properly support disconnections,
    you can answer "y". Then, all SCSI devices will never disconnect the bus
    even while performing long SCSI operations.

CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT
    Genuine SYMBIOS boards use GPIO0 in output for controller LED and GPIO3
    bit as a flag indicating singled-ended/differential interface.
    If all the boards of your system are genuine SYMBIOS boards or use
    BIOS and drivers from SYMBIOS, you would want to enable this option.
    This option must NOT be enabled if your system has at least one 53C8XX
    based scsi board with a vendor-specific BIOS.
    For example, Tekram DC-390/U, DC-390/W and DC-390/F scsi controllers
    use a vendor-specific BIOS and are known to not use SYMBIOS compatible
    GPIO wiring. So, this option must not be enabled if your system has
    such a board installed.

CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT
    Enable support for reading the serial NVRAM data on Symbios and
    some Symbios compatible cards, and Tekram DC390W/U/F cards. Useful for
    systems with more than one Symbios compatible controller where at least
    one has a serial NVRAM, or for a system with a mixture of Symbios and
    Tekram cards. Enables setting the boot order of host adaptors
    to something other than the default order or "reverse probe" order.
    Also enables Symbios and Tekram cards to be distinguished so
    CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT may be set in a system with a
    mixture of Symbios and Tekram cards so the Symbios cards can make use of
    the full range of Symbios features, differential, led pin, without
    causing problems for the Tekram card(s).

10. Boot setup commands

10.1 Syntax

Setup commands can be passed to the driver either at boot time or as a
string variable using 'insmod'.

A boot setup command for the ncr53c8xx (sym53c8xx) driver begins with the
driver name "ncr53c8xx="(sym53c8xx). The kernel syntax parser then expects
an optionnal list of integers separated with comma followed by an optional
list of  comma-separated strings. Example of boot setup command under lilo
prompt:

lilo: linux root=/dev/hda2 ncr53c8xx=tags:4,sync:10,debug:0x200

- enable tagged commands, up to 4 tagged commands queued.
- set synchronous negotiation speed to 10 Mega-transfers / second.
- set DEBUG_NEGO flag.

Since comma seems not to be allowed when defining a string variable using
'insmod', the driver also accepts <space> as option separator.
The following command will install driver module with the same options as
above.

    insmod ncr53c8xx.o ncr53c8xx="tags:4 sync:10 debug:0x200"

For the moment, the integer list of arguments is discarded by the driver.
It will be used in the future in order to allow a per controller setup.

Each string argument must be specified as "keyword:value". Only lower-case
characters and digits are allowed.

In a system that contains multiple 53C8xx adapters insmod will install the
specified driver on each adapter. To exclude a chip use the 'excl' keyword.

The sequence of commands,

    insmod sym53c8xx sym53c8xx=excl:0x1400
    insmod ncr53c8xx

installs the sym53c8xx driver on all adapters except the one at IO port
address 0x1400 and then installs the ncr53c8xx driver to the adapter at IO
port address 0x1400.


10.2 Available arguments

10.2.1  Master parity checking
        mpar:y     enabled
        mpar:n     disabled

10.2.2  Scsi parity checking
        spar:y     enabled
        spar:n     disabled

10.2.3  Scsi disconnections
        disc:y     enabled
        disc:n     disabled

10.2.4  Special features
   Only apply to 810A, 825A, 860, 875 and 895 controllers.
   Have no effect with other ones.
        specf:y    (or 1) enabled
        specf:n    (or 0) disabled
        specf:3           enabled except Memory Write And Invalidate
   The default driver setup is 'specf:3'. As a consequence, option 'specf:y'
   must be specified in the boot setup command to enable Memory Write And
   Invalidate.

10.2.5  Ultra SCSI support
   Only apply to 860, 875, 895, 895a, 896, 1010 and 1010_66 controllers.
   Have no effect with other ones.
        ultra:n    All ultra speeds enabled
        ultra:2    Ultra2 enabled
        ultra:1    Ultra enabled
        ultra:0    Ultra speeds disabled

10.2.6  Default number of tagged commands
        tags:0     (or tags:1 ) tagged command queuing disabled
        tags:#tags (#tags  > 1) tagged command queuing enabled
  #tags will be truncated to the max queued commands configuration parameter.
  This option also allows to specify a command queue depth for each device
  that support tagged command queueing.
  Example:
      ncr53c8xx=tags:10/t2t3q16-t5q24/t1u2q32
               will set devices queue depth as follow:
      - controller #0 target #2 and target #3                  -> 16 commands,
      - controller #0 target #5                                -> 24 commands,
      - controller #1 target #1 logical unit #2                -> 32 commands,
      - all other logical units (all targets, all controllers) -> 10 commands.

10.2.7  Default synchronous period factor
        sync:255     disabled (asynchronous transfer mode)
        sync:#factor
  #factor = 10     Ultra-2 SCSI 40 Mega-transfers / second
  #factor = 11     Ultra-2 SCSI 33 Mega-transfers / second
  #factor < 25     Ultra   SCSI 20 Mega-transfers / second
  #factor < 50     Fast    SCSI-2

  In all cases, the driver will use the minimum transfer period supported by
  controllers according to NCR53C8XX chip type.

10.2.8  Negotiate synchronous with all devices
        (force sync nego)
        fsn:y      enabled
        fsn:n      disabled

10.2.9  Verbosity level
        verb:0     minimal
        verb:1     normal
        verb:2     too much

10.2.10 Debug mode
        debug:0	 clear debug flags
        debug:#x   set debug flags
  #x is an integer value combining the following power-of-2 values:
  DEBUG_ALLOC       0x1
  DEBUG_PHASE       0x2
  DEBUG_POLL        0x4
  DEBUG_QUEUE       0x8
  DEBUG_RESULT     0x10
  DEBUG_SCATTER    0x20
  DEBUG_SCRIPT     0x40
  DEBUG_TINY       0x80
  DEBUG_TIMING    0x100
  DEBUG_NEGO      0x200
  DEBUG_TAGS      0x400
  DEBUG_FREEZE    0x800
  DEBUG_RESTART  0x1000

  You can play safely with DEBUG_NEGO. However, some of these flags may
  generate bunches of syslog messages.

10.2.11 Burst max
        burst:0    burst disabled
        burst:255  get burst length from initial IO register settings.
        burst:#x   burst enabled (1<<#x burst transfers max)
  #x is an integer value which is log base 2 of the burst transfers max.
  The NCR53C875 and NCR53C825A support up to 128 burst transfers (#x = 7).
  Other chips only support up to 16 (#x = 4).
  This is a maximum value. The driver set the burst length according to chip
  and revision ids. By default the driver uses the maximum value supported
  by the chip.

10.2.12 LED support
        led:1      enable  LED support
        led:0      disable LED support
  Donnot enable LED support if your scsi board does not use SDMS BIOS.
  (See 'Configuration parameters')

10.2.13 Max wide
        wide:1      wide scsi enabled
        wide:0      wide scsi disabled
  Some scsi boards use a 875 (ultra wide) and only supply narrow connectors.
  If you have connected a wide device with a 50 pins to 68 pins cable
  converter, any accepted wide negotiation will break further data transfers.
  In such a case, using "wide:0" in the bootup command will be helpfull.

10.2.14 Differential mode
        diff:0	never set up diff mode
        diff:1	set up diff mode if BIOS set it
        diff:2	always set up diff mode
        diff:3	set diff mode if GPIO3 is not set

10.2.15 IRQ mode
        irqm:0     always open drain
        irqm:1     same as initial settings (assumed BIOS settings)
        irqm:2     always totem pole
        irqm:0x10  driver will not use SA_SHIRQ flag when requesting irq
        irqm:0x20  driver will not use SA_INTERRUPT flag when requesting irq

    (Bits 0x10 and 0x20 can be combined with hardware irq mode option)

10.2.16 Reverse probe
        revprob:n   probe chip ids from the PCI configuration in this order:
                    810, 815, 820, 860, 875, 885, 895, 896
        revprob:y   probe chip ids in the reverse order.

10.2.17 Fix up PCI configuration space
        pcifix:<option bits>

    Available option bits:
        0x0:   No attempt to fix PCI configuration space registers values.
        0x1:   Set PCI cache-line size register if not set.
        0x2:   Set write and invalidate bit in PCI command register.
        0x4:   Increase if necessary PCI latency timer according to burst max.

    Use 'pcifix:7' in order to allow the driver to fix up all PCI features.

10.2.18 Serial NVRAM
        nvram:n     do not look for serial NVRAM
        nvram:y     test controllers for onboard serial NVRAM
        (alternate binary form)
        mvram=<bits options>
        0x01   look for NVRAM  (equivalent to nvram=y)
        0x02   ignore NVRAM "Synchronous negotiation" parameters for all devices
        0x04   ignore NVRAM "Wide negotiation"  parameter for all devices
        0x08   ignore NVRAM "Scan at boot time" parameter for all devices
        0x80   also attach controllers set to OFF in the NVRAM (sym53c8xx only)

10.2.19 Check SCSI BUS
        buschk:<option bits>

    Available option bits:
        0x0:   No check.
        0x1:   Check and donnot attach the controller on error.
        0x2:   Check and just warn on error.
        0x4:   Disable SCSI bus integrity checking.

10.2.20 Exclude a host from being attached
        excl=<io_address>

    Prevent host at a given io address from being attached.
    For example 'ncr53c8xx=excl:0xb400,excl:0xc000' indicate to the
    ncr53c8xx driver not to attach hosts at address 0xb400 and 0xc000.

10.2.21 Suggest a default SCSI id for hosts
        hostid:255	no id suggested.
        hostid:#x   (0 < x < 7) x suggested for hosts SCSI id.

    If a host SCSI id is available from the NVRAM, the driver will ignore
    any value suggested as boot option. Otherwise, if a suggested value
    different from 255 has been supplied, it will use it. Otherwise, it will
    try to deduce the value previously set in the hardware and use value
    7 if the hardware value is zero.

10.2.22 Enable use of IMMEDIATE ARBITRATION
        (only supported by the sym53c8xx driver. See 10.7 for more details)
        iarb:0    donnot use this feature.
        iarb:#x   use this feature according to bit fields as follow:

    bit 0 (1) : enable IARB each time the initiator has been reselected
                when it arbitrated for the SCSI BUS.
    (#x >> 4) : maximum number of successive settings of IARB if the initiator
                win arbitration and it has other commands to send to a device.

Boot fail safe
    safe:y	load the following assumed fail safe initial setup

  master parity			disabled		mpar:n
  scsi parity			enabled			spar:y
  disconnections		not allowed		disc:n
  special features		disabled		specf:n
  ultra scsi			disabled		ultra:n
  force sync negotiation	disabled		fsn:n
  reverse probe			disabled		revprob:n
  PCI fix up                    disabled                pcifix:0
  serial NVRAM                  enabled                 nvram:y
  verbosity level		2			verb:2
  tagged command queuing	disabled		tags:0
  synchronous negotiation	disabled		sync:255
  debug flags			none			debug:0
  burst length			from BIOS settings	burst:255
  LED support			disabled		led:0
  wide support			disabled		wide:0
  settle time			10 seconds		settle:10
  differential support		from BIOS settings	diff:1
  irq mode			from BIOS settings	irqm:1
  SCSI BUS check		donnot attach on error	buschk:1
  immediate arbitration		disabled		iarb:0

10.3 Advised boot setup commands

If the driver has been configured with default options, the equivalent
boot setup is:

   ncr53c8xx=mpar:y,spar:y,disc:y,specf:3,fsn:n,ultra:2,fsn:n,revprob:n,verb:1\
             tags:0,sync:50,debug:0,burst:7,led:0,wide:1,settle:2,diff:0,irqm:0

For an installation diskette or a safe but not fast system,
boot setup can be:

    ncr53c8xx=safe:y,mpar:y,disc:y
    ncr53c8xx=safe:y,disc:y
    ncr53c8xx=safe:y,mpar:y
    ncr53c8xx=safe:y

My personnal system works flawlessly with the following equivalent setup:

   ncr53c8xx=mpar:y,spar:y,disc:y,specf:1,fsn:n,ultra:2,fsn:n,revprob:n,verb:1\
             tags:32,sync:12,debug:0,burst:7,led:1,wide:1,settle:2,diff:0,irqm:0

The driver prints its actual setup when verbosity level is 2. You can try
"ncr53c8xx=verb:2" to get the "static" setup of the driver, or add "verb:2"
to your boot setup command in order to check the actual setup the driver is
using.

10.4 PCI configuration fix-up boot option

pcifix:<option bits>

Available option bits:
    0x1:     Set PCI cache-line size register if not set.
    0x2:     Set write and invalidate bit in PCI command register.

Use 'pcifix:3' in order to allow the driver to fix both PCI features.

These options only apply to new SYMBIOS chips 810A, 825A, 860, 875
and 895 and are only supported for Pentium and 486 class processors.
Recent SYMBIOS 53C8XX scsi processors are able to use PCI read multiple
and PCI write and invalidate commands. These features require the
cache line size register to be properly set in the PCI configuration
space of the chips. On the other hand, chips will use PCI write and
invalidate commands only if the corresponding bit is set to 1 in the
PCI command register.

Not all PCI bioses set the PCI cache line register and the PCI write and
invalidate bit in the PCI configuration space of 53C8XX chips.
Optimized PCI accesses may be broken for some PCI/memory controllers or
make problems with some PCI boards.

This fix-up worked flawlessly on my previous system.
(MB Triton HX / 53C875 / 53C810A)
I use these options at my own risks as you will do if you decide to
use them too.


10.5 Serial NVRAM support boot option

nvram:n     do not look for serial NVRAM
nvram:y     test controllers for onboard serial NVRAM

This option can also been entered as an hexadecimal value that allows
to control what information the driver will get from the NVRAM and what
information it will ignore.
For details see '17. Serial NVRAM support'.

When this option is enabled, the driver tries to detect all boards using
a Serial NVRAM. This memory is used to hold user set up parameters.

The parameters the driver is able to get from the NVRAM depend on the
data format used, as follow:

                                 Tekram format      Symbios format
General and host parameters
    Boot order                         N                   Y
    Host SCSI ID                       Y                   Y
    SCSI parity checking               Y                   Y
    Verbose boot messages              N                   Y
SCSI devices parameters
    Synchronous transfer speed         Y                   Y
    Wide 16 / Narrow                   Y                   Y
    Tagged Command Queuing enabled     Y                   Y
    Disconnections enabled             Y                   Y
    Scan at boot time                  N                   Y

In order to speed up the system boot, for each device configured without
the "scan at boot time" option, the driver forces an error on the
first TEST UNIT READY command received for this device.

Some SDMS BIOS revisions seem to be unable to boot cleanly with very fast
hard disks. In such a situation you cannot configure the NVRAM with
optimized parameters value.

The 'nvram' boot option can be entered in hexadecimal form in order
to ignore some options configured in the NVRAM, as follow:

mvram=<bits options>
      0x01   look for NVRAM  (equivalent to nvram=y)
      0x02   ignore NVRAM "Synchronous negotiation" parameters for all devices
      0x04   ignore NVRAM "Wide negotiation"  parameter for all devices
      0x08   ignore NVRAM "Scan at boot time" parameter for all devices
      0x80   also attach controllers set to OFF in the NVRAM (sym53c8xx only)

Option 0x80 is only supported by the sym53c8xx driver and is disabled by
default. Result is that, by default (option not set), the sym53c8xx driver
will not attach controllers set to OFF in the NVRAM.

The ncr53c8xx always tries to attach all the controllers. Option 0x80 has
not been added to the ncr53c8xx driver, since it has been reported to
confuse users who use this driver since a long time. If you desire a
controller not to be attached by the ncr53c8xx driver at Linux boot, you
must use the 'excl' driver boot option.

10.6 SCSI BUS checking boot option.

When this option is set to a non-zero value, the driver checks SCSI lines
logic state, 100 micro-seconds after having asserted the SCSI RESET line.
The driver just reads SCSI lines and checks all lines read FALSE except RESET.
Since SCSI devices shall release the BUS at most 800 nano-seconds after SCSI
RESET has been asserted, any signal to TRUE may indicate a SCSI BUS problem.
Unfortunately, the following common SCSI BUS problems are not detected:
- Only 1 terminator installed.
- Misplaced terminators.
- Bad quality terminators.
On the other hand, either bad cabling, broken devices, not conformant
devices, ... may cause a SCSI signal to be wrong when te driver reads it.

10.7 IMMEDIATE ARBITRATION boot option

This option is only supported by the SYM53C8XX driver (not by the NCR53C8XX).

SYMBIOS 53C8XX chips are able to arbitrate for the SCSI BUS as soon as they
have detected an expected disconnection (BUS FREE PHASE). For this process
to be started, bit 1 of SCNTL1 IO register must be set when the chip is
connected to the SCSI BUS.

When this feature has been enabled for the current connection, the chip has
every chance to win arbitration if only devices with lower priority are
competing for the SCSI BUS. By the way, when the chip is using SCSI id 7,
then it will for sure win the next SCSI BUS arbitration.

Since, there is no way to know what devices are trying to arbitrate for the
BUS, using this feature can be extremally unfair. So, you are not advised
to enable it, or at most enable this feature for the case the chip lost
the previous arbitration (boot option 'iarb:1').

This feature has the following advantages:

a) Allow the initiator with ID 7 to win arbitration when it wants so.
b) Overlap at least 4 micro-seconds of arbitration time with the execution
   of SCRIPTS that deal with the end of the current connection and that
   starts the next job.

Hmmm... But (a) may just prevent other devices from reselecting the initiator,
and delay data transfers or status/completions, and (b) may just waste
SCSI BUS bandwidth if the SCRIPTS execution lasts more than 4 micro-seconds.

The use of IARB needs the SCSI_NCR_IARB_SUPPORT option to have been defined
at compile time and the 'iarb' boot option to have been set to a non zero
value at boot time. It is not that useful for real work, but can be used
to stress SCSI devices or for some applications that can gain advantage of
it. By the way, if you experience badnesses like 'unexpected disconnections',
'bad reselections', etc... when using IARB on heavy IO load, you should not
be surprised, because force-feeding anything and blocking its arse at the
same time cannot work for a long time. :-))


11. Some constants and flags of the ncr53c8xx.h header file

Some of these are defined from the configuration parameters.  To
change other "defines", you must edit the header file.  Do that only
if you know what you are doing.

SCSI_NCR_SETUP_SPECIAL_FEATURES	(default: defined)
	If defined, the driver will enable some special features according
	to chip and revision id.
        For 810A, 860, 825A, 875 and 895 scsi chips, this option enables
	support of features that reduce load of PCI bus and memory accesses
	during  scsi transfer processing: burst op-code fetch, read multiple,
        read line, prefetch, cache line, write and invalidate,
        burst 128 (875 only), large dma fifo (875 only), offset 16 (875 only).
	Can be changed by the following boot setup command:
		ncr53c8xx=specf:n

SCSI_NCR_IOMAPPED		(default: not defined)
	If defined, normal I/O is forced.

SCSI_NCR_SHARE_IRQ		(default: defined)
	If defined, request shared IRQ.

SCSI_NCR_MAX_TAGS		(default: 8)
	Maximum number of simultaneous tagged commands to a device.
	Can be changed by "settags <target> <maxtags>"

SCSI_NCR_SETUP_DEFAULT_SYNC     (default: 50)
	Transfer period factor the driver will use at boot time for synchronous
	negotiation. 0 means asynchronous.
	Can be changed by "setsync <target> <period factor>"

SCSI_NCR_SETUP_DEFAULT_TAGS     (default: 8)
	Default number of simultaneous tagged commands to a device.
	< 1 means tagged command queuing disabled at start-up.

SCSI_NCR_ALWAYS_SIMPLE_TAG	(default: defined)
	Use SIMPLE TAG for read and write commands.
	Can be changed by "setorder <ordered|simple|default>"

SCSI_NCR_SETUP_DISCONNECTION	(default: defined)
	If defined, targets are allowed to disconnect.

SCSI_NCR_SETUP_FORCE_SYNC_NEGO	(default: not defined)
	If defined, synchronous negotiation is tried for all SCSI-2 devices.
	Can be changed by "setsync <target> <period>"

SCSI_NCR_SETUP_MASTER_PARITY	(default: defined)
	If defined, master parity checking is enabled.

SCSI_NCR_SETUP_MASTER_PARITY	(default: defined)
	If defined, SCSI parity checking is enabled.

SCSI_NCR_PROFILE_SUPPORT	(default: not defined)
	If defined, profiling information is gathered.

SCSI_NCR_MAX_SCATTER		(default: 128)
	Scatter list size of the driver ccb.

SCSI_NCR_MAX_TARGET		(default: 16)
	Max number of targets per host.

SCSI_NCR_MAX_HOST		(default: 2)
	Max number of host controllers.

SCSI_NCR_SETTLE_TIME		(default: 2)
	Number of seconds the driver will wait after reset.

SCSI_NCR_TIMEOUT_ALERT		(default: 3)
	If a pending command will time out after this amount of seconds,
	an ordered tag is used for the next command.
	Avoids timeouts for unordered tagged commands.

SCSI_NCR_CAN_QUEUE		(default: 7*SCSI_NCR_MAX_TAGS)
	Max number of commands that can be queued to a host.

SCSI_NCR_CMD_PER_LUN		(default: SCSI_NCR_MAX_TAGS)
	Max number of commands queued to a host for a device.

SCSI_NCR_SG_TABLESIZE		(default: SCSI_NCR_MAX_SCATTER-1)
	Max size of the Linux scatter/gather list.

SCSI_NCR_MAX_LUN	(default: 8)
	Max number of LUNs per target.


12. Installation

This driver is part of the linux kernel distribution.
Driver files are located in the sub-directory "drivers/scsi" of the
kernel source tree.

Driver files:

	README.ncr53c8xx	: this file
	ChangeLog.ncr53c8xx	: change log
	ncr53c8xx.h		: definitions
	ncr53c8xx.c		: the driver code

New driver versions are made available separately in order to allow testing
changes and new features prior to including them into the linux kernel
distribution. The following URL provides informations on latest avalaible
patches:

      ftp://ftp.tux.org/pub/people/gerard-roudier/README


13. Architecture dependent features.

<Not yet written>


14. Known problems

14.1 Tagged commands with Iomega Jaz device

I have not tried this device, however it has been reported to me the
following: This device is capable of Tagged command queuing. However
while spinning up, it rejects Tagged commands. This behaviour is
conforms to 6.8.2 of SCSI-2 specifications. The current behaviour of
the driver in that situation is not satisfying. So do not enable
Tagged command queuing for devices that are able to spin down.  The
other problem that may appear is timeouts. The only way to avoid
timeouts seems to edit linux/drivers/scsi/sd.c and to increase the
current timeout values.

14.2 Device names change when another controller is added.

When you add a new NCR53C8XX chip based controller to a system that already
has one or more controllers of this family, it may happen that the order
the driver registers them to the kernel causes problems due to device
name changes.
When at least one controller uses NvRAM, SDMS BIOS version 4 allows you to
define the order the BIOS will scan the scsi boards. The driver attaches
controllers according to BIOS information if NvRAM detect option is set.

If your controllers do not have NvRAM, you can:

- Ask the driver to probe chip ids in reverse order from the boot command
  line: ncr53c8xx=revprob:y
- Make appropriate changes in the fstab.
- Use the 'scsidev' tool from Eric Youngdale.

14.3 Using only 8 bit devices with a WIDE SCSI controller.

When only 8 bit NARROW devices are connected to a 16 bit WIDE SCSI controller,
you must ensure that lines of the wide part of the SCSI BUS are pulled-up.
This can be achieved by ENABLING the WIDE TERMINATOR portion of the SCSI
controller card.
The TYAN 1365 documentation revision 1.2 is not correct about such settings.
(page 10, figure 3.3).

14.4 Possible data corruption during a Memory Write and Invalidate

This problem is described in SYMBIOS DEL 397, Part Number 69-039241, ITEM 4.

In some complex situations, 53C875 chips revision <= 3 may start a PCI
Write and Invalidate Command at a not cache-line-aligned 4 DWORDS boundary.
This is only possible when Cache Line Size is 8 DWORDS or greater.
Pentium systems use a 8 DWORDS cache line size and so are concerned by
this chip bug, unlike i486 systems that use a 4 DWORDS cache line size.

When this situation occurs, the chip may complete the Write and Invalidate
command after having only filled part of the last cache line involved in
the transfer, leaving to data corruption the remainder of this cache line.

Not using Write And Invalidate obviously gets rid of this chip bug, and so
it is now the default setting of the driver.
However, for people like me who want to enable this feature, I have added
part of a work-around suggested by SYMBIOS. This work-around resets the
addressing logic when the DATA IN phase is entered and so prevents the bug
from being triggered for the first SCSI MOVE of the phase. This work-around
should be enough according to the following:

The only driver internal data structure that is greater than 8 DWORDS  and
that is moved by the SCRIPTS processor is the 'CCB header' that contains
the context of the SCSI transfer. This data structure is aligned on 8 DWORDS
boundary (Pentium Cache Line Size), and so is immune to this chip bug, at
least on Pentium systems.
But the conditions of this bug can be met when a SCSI read command is
performed using a buffer that is 4 DWORDS but not cache-line aligned.
This cannot happen under Linux when scatter/gather lists are used since
they only refer to system buffers that are well aligned. So, a work around
may only be needed under Linux when a scatter/gather list is not used and
when the SCSI DATA IN phase is reentered after a phase mismatch.

14.5 IRQ sharing problems

When an IRQ is shared by devices that are handled by different drivers, it
may happen that one driver complains about the request of the IRQ having
failed. Inder Linux-2.0, this may be due to one driver having requested the
IRQ using the SA_INTERRUPT flag but some other having requested the same IRQ
without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by
one driver not having requested the IRQ with the SA_SHIRQ flag.

By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the
SA_INTERRUPT and the SA_SHIRQ flag under Linux-2.0 and with only the SA_SHIRQ
flag under Linux-2.2.

Under Linux-2.0, you can disable use of SA_INTERRUPT flag from the boot
command line by using the following option:

     ncr53c8xx=irqm:0x20   (for the generic ncr53c8xx driver)
     sym53c8xx=irqm:0x20   (for the sym53c8xx driver)

If this does not fix the problem, then you may want to check how all other
drivers are requesting the IRQ and report the problem. Note that if at least
a single driver does not request the IRQ with the SA_SHIRQ flag (share IRQ),
then the request of the IRQ obviously will not succeed for all the drivers.

15. SCSI problem troubleshooting

15.1 Problem tracking

Most SCSI problems are due to a non conformant SCSI bus or to buggy
devices.  If infortunately you have SCSI problems, you can check the
following things:

- SCSI bus cables
- terminations at both end of the SCSI chain
- linux syslog messages (some of them may help you)

If you donnot find the source of problems, you can configure the
driver with no features enabled.

- only asynchronous data transfers
- tagged commands disabled
- disconnections not allowed

Now, if your SCSI bus is ok, your system have every chance to work
with this safe configuration but performances will not be optimal.

If it still fails, then you can send your problem description to
appropriate mailing lists or news-groups.  Send me a copy in order to
be sure I will receive it.  Obviously, a bug in the driver code is
possible.

     My email address: Gerard Roudier <groudier@free.fr>

Allowing disconnections is important if you use several devices on
your SCSI bus but often causes problems with buggy devices.
Synchronous data transfers increases throughput of fast devices like
hard disks.  Good SCSI hard disks with a large cache gain advantage of
tagged commands queuing.

Try to enable one feature at a time with control commands.  For example:

- echo "setsync all 25" >/proc/scsi/ncr53c8xx/0
  Will enable fast synchronous data transfer negotiation for all targets.

- echo "setflag 3" >/proc/scsi/ncr53c8xx/0
  Will reset flags (no_disc) for target 3, and so will allow it to disconnect
  the SCSI Bus.

- echo "settags 3 8" >/proc/scsi/ncr53c8xx/0
  Will enable tagged command queuing for target 3 if that device supports it.

Once you have found the device and the feature that cause problems, just
disable that feature for that device.

15.2 Understanding hardware error reports

When the driver detects an unexpected error condition, it may display a
message of the following pattern.

sym53c876-0:1: ERROR (0:48) (1-21-65) (f/95) @ (script 7c0:19000000).
sym53c876-0: script cmd = 19000000
sym53c876-0: regdump: da 10 80 95 47 0f 01 07 75 01 81 21 80 01 09 00.

Some fields in such a message may help you understand the cause of the
problem, as follows:

sym53c876-0:1: ERROR (0:48) (1-21-65) (f/95) @ (script 7c0:19000000).
............A.........B.C....D.E..F....G.H.......I.....J...K.......

Field A : target number.
  SCSI ID of the device the controller was talking with at the moment the
  error occurs.

Field B : DSTAT io register (DMA STATUS)
  Bit 0x40 : MDPE Master Data Parity Error
             Data parity error detected on the PCI BUS.
  Bit 0x20 : BF   Bus Fault
             PCI bus fault condition detected
  Bit 0x01 : IID  Illegal Instruction Detected
             Set by the chip when it detects an Illegal Instruction format
             on some condition that makes an instruction illegal.
  Bit 0x80 : DFE Dma Fifo Empty
             Pure status bit that does not indicate an error.
  If the reported DSTAT value contains a combination of MDPE (0x40),
  BF (0x20), then the cause may be likely due to a PCI BUS problem.

Field C : SIST io register (SCSI Interrupt Status)
  Bit 0x08 : SGE  SCSI GROSS ERROR
             Indicates that the chip detected a severe error condition
             on the SCSI BUS that prevents the SCSI protocol from functionning
             properly.
  Bit 0x04 : UDC  Undexpected Disconnection
             Indicates that the device released the SCSI BUS when the chip
             was not expecting this to happen. A device may behave so to
             indicate the SCSI initiator that an error condition not reportable              using the SCSI protocol has occurred.
  Bit 0x02 : RST  SCSI BUS Reset
             Generally SCSI targets donnot reset the SCSI BUS, although any
             device on the BUS can reset it at any time.
  Bit 0x01 : PAR  Parity
             SCSI parity error detected.
  On a faulty SCSI BUS, any error condition among SGE (0x08), UDC (0x04) and
  PAR (0x01) may be detected by the chip. If your SCSI system sometimes
  encounters such error conditions, especially SCSI GROSS ERROR, then a SCSI
  BUS problem is likely the cause of these errors.

For fields D,E,F,G and H, you may look into the sym53c8xx_defs.h file
that contains some minimal comments on IO register bits.
Field D : SOCL  Scsi Output Control Latch
          This register reflects the state of the SCSI control lines the
          chip want to drive or compare against.
Field E : SBCL  Scsi Bus Control Lines
          Actual value of control lines on the SCSI BUS.
Field F : SBDL  Scsi Bus Data Lines
          Actual value of data lines on the SCSI BUS.
Field G : SXFER  SCSI Transfer
          Contains the setting of the Synchronous Period for output and
          the current Synchronous offset (offset 0 means asynchronous).
Field H : SCNTL3 Scsi Control Register 3
          Contains the setting of timing values for both asynchronous and
          synchronous data transfers.

Understanding Fields I, J, K and dumps requires to have good knowledge of
SCSI standards, chip cores functionnals and internal driver data structures.
You are not required to decode and understand them, unless you want to help
maintain the driver code.

16. Synchonous transfer negotiation tables

Tables below have been created by calling the routine the driver uses
for synchronisation negotiation timing calculation and chip setting.
The first table corresponds to Ultra chips 53875 and 53C860 with 80 MHz
clock and 5 clock divisors.
The second one has been calculated by setting the scsi clock to 40 Mhz
and using 4 clock divisors and so applies to all NCR53C8XX chips in fast
SCSI-2 mode.

Periods are in nano-seconds and speeds are in Mega-transfers per second.
1 Mega-transfers/second means 1 MB/s with 8 bits SCSI and 2 MB/s with
Wide16 SCSI.

16.1 Synchronous timings for 53C895, 53C875 and 53C860 SCSI controllers

 ----------------------------------------------
 Negotiated                     NCR settings
 Factor   Period   Speed        Period   Speed
 ------   ------   ------       ------   ------
 10       25       40.000       25       40.000   (53C895 only)
 11       30.2     33.112       31.25    32.000   (53C895 only)
 12       50       20.000       50       20.000
 13       52       19.230       62       16.000
 14       56       17.857       62       16.000
 15       60       16.666       62       16.000
 16       64       15.625       75       13.333
 17       68       14.705       75       13.333
 18       72       13.888       75       13.333
 19       76       13.157       87       11.428
 20       80       12.500       87       11.428
 21       84       11.904       87       11.428
 22       88       11.363       93       10.666
 23       92       10.869       93       10.666
 24       96       10.416      100       10.000
 25      100       10.000      100       10.000
 26      104        9.615      112        8.888
 27      108        9.259      112        8.888
 28      112        8.928      112        8.888
 29      116        8.620      125        8.000
 30      120        8.333      125        8.000
 31      124        8.064      125        8.000
 32      128        7.812      131        7.619
 33      132        7.575      150        6.666
 34      136        7.352      150        6.666
 35      140        7.142      150        6.666
 36      144        6.944      150        6.666
 37      148        6.756      150        6.666
 38      152        6.578      175        5.714
 39      156        6.410      175        5.714
 40      160        6.250      175        5.714
 41      164        6.097      175        5.714
 42      168        5.952      175        5.714
 43      172        5.813      175        5.714
 44      176        5.681      187        5.333
 45      180        5.555      187        5.333
 46      184        5.434      187        5.333
 47      188        5.319      200        5.000
 48      192        5.208      200        5.000
 49      196        5.102      200        5.000


16.2 Synchronous timings for fast SCSI-2 53C8XX controllers

 ----------------------------------------------
 Negotiated                     NCR settings
 Factor   Period   Speed        Period   Speed
 ------   ------   ------       ------   ------
 25      100       10.000      100       10.000
 26      104        9.615      125        8.000
 27      108        9.259      125        8.000
 28      112        8.928      125        8.000
 29      116        8.620      125        8.000
 30      120        8.333      125        8.000
 31      124        8.064      125        8.000
 32      128        7.812      131        7.619
 33      132        7.575      150        6.666
 34      136        7.352      150        6.666
 35      140        7.142      150        6.666
 36      144        6.944      150        6.666
 37      148        6.756      150        6.666
 38      152        6.578      175        5.714
 39      156        6.410      175        5.714
 40      160        6.250      175        5.714
 41      164        6.097      175        5.714
 42      168        5.952      175        5.714
 43      172        5.813      175        5.714
 44      176        5.681      187        5.333
 45      180        5.555      187        5.333
 46      184        5.434      187        5.333
 47      188        5.319      200        5.000
 48      192        5.208      200        5.000
 49      196        5.102      200        5.000


17. Serial NVRAM (added by Richard Waltham: dormouse@farsrobt.demon.co.uk)

17.1 Features

Enabling serial NVRAM support enables detection of the serial NVRAM included
on Symbios and some Symbios compatible host adaptors, and Tekram boards. The
serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
host adaptor and it's attached drives.

The Symbios NVRAM also holds data on the boot order of host adaptors in a
system with more than one host adaptor. This enables the order of scanning
the cards for drives to be changed from the default used during host adaptor
detection.

This can be done to a limited extent at the moment using "reverse probe" but
this only changes the order of detection of different types of cards. The
NVRAM boot order settings can do this as well as change the order the same
types of cards are scanned in, something "reverse probe" cannot do.

Tekram boards using Symbios chips, DC390W/F/U, which have NVRAM are detected
and this is used to distinguish between Symbios compatible and Tekram host
adaptors. This is used to disable the Symbios compatible "diff" setting
incorrectly set on Tekram boards if the CONFIG_SCSI_53C8XX_SYMBIOS_COMPAT
configuration parameter is set enabling both Symbios and Tekram boards to be
used together with the Symbios cards using all their features, including
"diff" support. ("led pin" support for Symbios compatible cards can remain
enabled when using Tekram cards. It does nothing useful for Tekram host
adaptors but does not cause problems either.)


17.2 Symbios NVRAM layout

typical data at NVRAM address 0x100 (53c810a NVRAM)
-----------------------------------------------------------
00 00
64 01
8e 0b

00 30 00 00 00 00 07 00 00 00 00 00 00 00 07 04 10 04 00 00

04 00 0f 00 00 10 00 50 00 00 01 00 00 62
04 00 03 00 00 10 00 58 00 00 01 00 00 63
04 00 01 00 00 10 00 48 00 00 01 00 00 61
00 00 00 00 00 00 00 00 00 00 00 00 00 00

0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00

0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

fe fe
00 00
00 00
-----------------------------------------------------------
NVRAM layout details

NVRAM Address 0x000-0x0ff not used
              0x100-0x26f initialised data
              0x270-0x7ff not used

general layout

        header  -   6 bytes,
        data    - 356 bytes (checksum is byte sum of this data)
        trailer -   6 bytes
                  ---
        total     368 bytes

data area layout

        controller set up  -  20 bytes
        boot configuration -  56 bytes (4x14 bytes)
        device set up      - 128 bytes (16x8 bytes)
        unused (spare?)    - 152 bytes (19x8 bytes)
                             ---
        total                356 bytes

-----------------------------------------------------------
header

00 00   - ?? start marker
64 01   - byte count (lsb/msb excludes header/trailer)
8e 0b   - checksum (lsb/msb excludes header/trailer)
-----------------------------------------------------------
controller set up

00 30 00 00 00 00 07 00 00 00 00 00 00 00 07 04 10 04 00 00
                   |     |           |     |
                   |     |           |      -- host ID
                   |     |           |
                   |     |            --Removable Media Support
                   |     |               0x00 = none
                   |     |               0x01 = Bootable Device
                   |     |               0x02 = All with Media
                   |     |
                   |      --flag bits 2
                   |        0x00000001= scan order hi->low
                   |            (default 0x00 - scan low->hi)
                    --flag bits 1
                       0x00000001 scam enable
                       0x00000010 parity enable
                       0x00000100 verbose boot msgs

remaining bytes unknown - they do not appear to change in my
current set up for any of the controllers.

default set up is identical for 53c810a and 53c875 NVRAM
(Removable Media added Symbios BIOS version 4.09)
-----------------------------------------------------------
boot configuration

boot order set by order of the devices in this table

04 00 0f 00 00 10 00 50 00 00 01 00 00 62 -- 1st controller
04 00 03 00 00 10 00 58 00 00 01 00 00 63    2nd controller
04 00 01 00 00 10 00 48 00 00 01 00 00 61    3rd controller
00 00 00 00 00 00 00 00 00 00 00 00 00 00    4th controller
       |  |  |  |     |        |     |  |
       |  |  |  |     |        |      ---- PCI io port adr
       |  |  |  |     |         --0x01 init/scan at boot time
       |  |  |  |      --PCI device/function number (0xdddddfff)
       |  |   ----- ?? PCI vendor ID (lsb/msb)
        ----PCI device ID (lsb/msb)

?? use of this data is a guess but seems reasonable

remaining bytes unknown - they do not appear to change in my
current set up

default set up is identical for 53c810a and 53c875 NVRAM
-----------------------------------------------------------
device set up (up to 16 devices - includes controller)

0f 00 08 08 64 00 0a 00 - id 0
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00

0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00
0f 00 08 08 64 00 0a 00 - id 15
 |     |  |  |     |  |
 |     |  |  |      ----timeout (lsb/msb)
 |     |  |   --synch period (0x?? 40 Mtrans/sec- fast 40) (probably 0x28)
 |     |  |                  (0x30 20 Mtrans/sec- fast 20)
 |     |  |                  (0x64 10 Mtrans/sec- fast )
 |     |  |                  (0xc8  5 Mtrans/sec)
 |     |  |                  (0x00  asynchronous)
 |     |   -- ?? max sync offset (0x08 in NVRAM on 53c810a)
 |     |                         (0x10 in NVRAM on 53c875)
 |      --device bus width (0x08 narrow)
 |                         (0x10 16 bit wide)
  --flag bits
    0x00000001 - disconnect enabled
    0x00000010 - scan at boot time
    0x00000100 - scan luns
    0x00001000 - queue tags enabled

remaining bytes unknown - they do not appear to change in my
current set up

?? use of this data is a guess but seems reasonable
(but it could be max bus width)

default set up for 53c810a NVRAM
default set up for 53c875 NVRAM - bus width     - 0x10
                                - sync offset ? - 0x10
                                - sync period   - 0x30
-----------------------------------------------------------
?? spare device space (32 bit bus ??)

00 00 00 00 00 00 00 00  (19x8bytes)
.
.
00 00 00 00 00 00 00 00

default set up is identical for 53c810a and 53c875 NVRAM
-----------------------------------------------------------
trailer

fe fe   - ? end marker ?
00 00
00 00

default set up is identical for 53c810a and 53c875 NVRAM
-----------------------------------------------------------



17.3 Tekram NVRAM layout

nvram 64x16 (1024 bit)

Drive settings

Drive ID 0-15 (addr 0x0yyyy0 = device setup, yyyy = ID)
              (addr 0x0yyyy1 = 0x0000)

    x x x x  x x x x  x x x x  x x x x
               | | |      | |  | | | |
               | | |      | |  | | |  ----- parity check   0 - off
               | | |      | |  | | |                       1 - on
               | | |      | |  | | |
               | | |      | |  | |  ------- sync neg       0 - off
               | | |      | |  | |                         1 - on
               | | |      | |  | |
               | | |      | |  |  --------- disconnect     0 - off
               | | |      | |  |                           1 - on
               | | |      | |  |
               | | |      | |   ----------- start cmd      0 - off
               | | |      | |                              1 - on
               | | |      | |
               | | |      |  -------------- tagged cmds    0 - off
               | | |      |                                1 - on
               | | |      |
               | | |       ---------------- wide neg       0 - off
               | | |                                       1 - on
               | | |
                --------------------------- sync rate      0 - 10.0 Mtrans/sec
                                                           1 -  8.0
                                                           2 -  6.6
                                                           3 -  5.7
                                                           4 -  5.0
                                                           5 -  4.0
                                                           6 -  3.0
                                                           7 -  2.0
                                                           7 -  2.0
                                                           8 - 20.0
                                                           9 - 16.7
                                                           a - 13.9
                                                           b - 11.9

Global settings

Host flags 0 (addr 0x100000, 32)

    x x x x  x x x x  x x x x  x x x x
    | | | |  | | | |           | | | |
    | | | |  | | | |            ----------- host ID    0x00 - 0x0f
    | | | |  | | | |
    | | | |  | | |  ----------------------- support for    0 - off
    | | | |  | | |                          > 2 drives     1 - on
    | | | |  | | |
    | | | |  | |  ------------------------- support drives 0 - off
    | | | |  | |                            > 1Gbytes      1 - on
    | | | |  | |
    | | | |  |  --------------------------- bus reset on   0 - off
    | | | |  |                                power on     1 - on
    | | | |  |
    | | | |   ----------------------------- active neg     0 - off
    | | | |                                                1 - on
    | | | |
    | | |  -------------------------------- imm seek       0 - off
    | | |                                                  1 - on
    | | |
    | |  ---------------------------------- scan luns      0 - off
    | |                                                    1 - on
    | |
     -------------------------------------- removable      0 - disable
                                            as BIOS dev    1 - boot device
                                                           2 - all

Host flags 1 (addr 0x100001, 33)

    x x x x  x x x x  x x x x  x x x x
               | | |             | | |
               | | |              --------- boot delay     0 -   3 sec
               | | |                                       1 -   5
               | | |                                       2 -  10
               | | |                                       3 -  20
               | | |                                       4 -  30
               | | |                                       5 -  60
               | | |                                       6 - 120
               | | |
                --------------------------- max tag cmds   0 -  2
                                                           1 -  4
                                                           2 -  8
                                                           3 - 16
                                                           4 - 32

Host flags 2 (addr 0x100010, 34)

    x x x x  x x x x  x x x x  x x x x
                                     |
                                      ----- F2/F6 enable   0 - off ???
                                                           1 - on  ???

checksum (addr 0x111111)

checksum = 0x1234 - (sum addr 0-63)

----------------------------------------------------------------------------

default nvram data:

0x0037 0x0000 0x0037 0x0000 0x0037 0x0000 0x0037 0x0000
0x0037 0x0000 0x0037 0x0000 0x0037 0x0000 0x0037 0x0000
0x0037 0x0000 0x0037 0x0000 0x0037 0x0000 0x0037 0x0000
0x0037 0x0000 0x0037 0x0000 0x0037 0x0000 0x0037 0x0000

0x0f07 0x0400 0x0001 0x0000 0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0xfbbc


18. Support for Big Endian

The PCI local bus has been primarily designed for x86 architecture.
As a consequence, PCI devices generally expect DWORDS using little endian
byte ordering.

18.1 Big Endian CPU

In order to support NCR chips on a Big Endian architecture the driver has to
perform byte reordering each time it is needed. This feature has been
added to the driver by Cort <cort@cs.nmt.edu> and is available in driver
version 2.5 and later ones. For the moment Big Endian support has only
been tested on Linux/PPC (PowerPC).

18.2 NCR chip in Big Endian mode of operations

It can be read in SYMBIOS documentation that some chips support a special
Big Endian mode, on paper: 53C815, 53C825A, 53C875, 53C875N, 53C895.
This mode of operations is not software-selectable, but needs pin named
BigLit to be pulled-up. Using this mode, most of byte reorderings should
be avoided when the driver is running on a Big Endian CPU.
Driver version 2.5 is also, in theory, ready for this feature.

===============================================================================
End of NCR53C8XX driver README file