AetherDroid/android_kernel_samsung_on5xelte
1
0
Fork 0
mirror of https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git synced 2025-09-05 07:57:45 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed MTP to work with TWRP

Browse source
This commit is contained in:
awab228 2018-06-19 23:16:04 +02:00
commit f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

110
Documentation/scsi/00-INDEX Normal file
View file

@ -0,0 +1,110 @@
00-INDEX
- this file
53c700.txt
- info on driver for 53c700 based adapters
BusLogic.txt
- info on driver for adapters with BusLogic chips
ChangeLog.1992-1997
- Changes to scsi files, if not listed elsewhere
ChangeLog.arcmsr
- Changes to driver for ARECA's SATA RAID controller cards
ChangeLog.ips
- IBM ServeRAID driver Changelog
ChangeLog.lpfc
- Changes to lpfc driver
ChangeLog.megaraid
- Changes to LSI megaraid controller.
ChangeLog.megaraid_sas
- Changes to serial attached scsi version of LSI megaraid controller.
ChangeLog.ncr53c8xx
- Changes to ncr53c8xx driver
ChangeLog.sym53c8xx
- Changes to sym53c8xx driver
ChangeLog.sym53c8xx_2
- Changes to second generation of sym53c8xx driver
FlashPoint.txt
- info on driver for BusLogic FlashPoint adapters
LICENSE.FlashPoint
- Licence of the Flashpoint driver
LICENSE.qla2xxx
- License for QLogic Linux Fibre Channel HBA Driver firmware.
LICENSE.qla4xxx
- License for QLogic Linux iSCSI HBA Driver.
Mylex.txt
- info on driver for Mylex adapters
NinjaSCSI.txt
- info on WorkBiT NinjaSCSI-32/32Bi driver
aacraid.txt
- Driver supporting Adaptec RAID controllers
advansys.txt
- List of Advansys Host Adapters
aha152x.txt
- info on driver for Adaptec AHA152x based adapters
aic79xx.txt
- Adaptec Ultra320 SCSI host adapters
aic7xxx.txt
- info on driver for Adaptec controllers
arcmsr_spec.txt
- ARECA FIRMWARE SPEC (for IOP331 adapter)
bfa.txt
- Brocade FC/FCOE adapter driver.
bnx2fc.txt
- FCoE hardware offload for Broadcom network interfaces.
cxgb3i.txt
- Chelsio iSCSI Linux Driver
dc395x.txt
- README file for the dc395x SCSI driver
dpti.txt
- info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters
dtc3x80.txt
- info on driver for DTC 2x80 based adapters
g_NCR5380.txt
- info on driver for NCR5380 and NCR53c400 based adapters
hpsa.txt
- HP Smart Array Controller SCSI driver.
hptiop.txt
- HIGHPOINT ROCKETRAID 3xxx RAID DRIVER
in2000.txt
- info on in2000 driver
libsas.txt
- Serial Attached SCSI management layer.
link_power_management_policy.txt
- Link power management options.
lpfc.txt
- LPFC driver release notes
megaraid.txt
- Common Management Module, shared code handling ioctls for LSI drivers
ncr53c8xx.txt
- info on driver for NCR53c8xx based adapters
osd.txt
Object-Based Storage Device, command set introduction.
osst.txt
- info on driver for OnStream SC-x0 SCSI tape
ppa.txt
- info on driver for IOmega zip drive
qlogicfas.txt
- info on driver for QLogic FASxxx based adapters
scsi-changer.txt
- README for the SCSI media changer driver
scsi-generic.txt
- info on the sg driver for generic (non-disk/CD/tape) SCSI devices.
scsi-parameters.txt
- List of SCSI-parameters to pass to the kernel at module load-time.
scsi.txt
- short blurb on using SCSI support as a module.
scsi_mid_low_api.txt
- info on API between SCSI layer and low level drivers
scsi_eh.txt
- info on SCSI midlayer error handling infrastructure
scsi_fc_transport.txt
- SCSI Fiber Channel Tansport
st.txt
- info on scsi tape driver
sym53c500_cs.txt
- info on PCMCIA driver for Symbios Logic 53c500 based adapters
sym53c8xx_2.txt
- info on second generation driver for sym53c8xx based adapters
tmscsim.txt
- info on driver for AM53c974 based adapters
ufs.txt
- info on Universal Flash Storage(UFS) and UFS host controller driver.

135
Documentation/scsi/53c700.txt Normal file
View file

@ -0,0 +1,135 @@
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
==================
A compile time flag is:
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).
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.

566
Documentation/scsi/BusLogic.txt Normal file
View file

@ -0,0 +1,566 @@
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 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://sourceforge.net/projects/dandelion/".
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.
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.
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 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="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 zImage
Then install "arch/x86/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.

2023
Documentation/scsi/ChangeLog.1992-1997 Normal file
View file

File diff suppressed because it is too large Load diff

118
Documentation/scsi/ChangeLog.arcmsr Normal file
View file

@ -0,0 +1,118 @@
**************************************************************************
** History
**
** REV# DATE NAME DESCRIPTION
** 1.00.00.00 3/31/2004 Erich Chen First release
** 1.10.00.04 7/28/2004 Erich Chen modify for ioctl
** 1.10.00.06 8/28/2004 Erich Chen modify for 2.6.x
** 1.10.00.08 9/28/2004 Erich Chen modify for x86_64
** 1.10.00.10 10/10/2004 Erich Chen bug fix for SMP & ioctl
** 1.20.00.00 11/29/2004 Erich Chen bug fix with arcmsr_bus_reset when PHY error
** 1.20.00.02 12/09/2004 Erich Chen bug fix with over 2T bytes RAID Volume
** 1.20.00.04 1/09/2005 Erich Chen fits for Debian linux kernel version 2.2.xx
** 1.20.00.05 2/20/2005 Erich Chen cleanly as look like a Linux driver at 2.6.x
** thanks for peoples kindness comment
** Kornel Wieliczek
** Christoph Hellwig
** Adrian Bunk
** Andrew Morton
** Christoph Hellwig
** James Bottomley
** Arjan van de Ven
** 1.20.00.06 3/12/2005 Erich Chen fix with arcmsr_pci_unmap_dma "unsigned long" cast,
** modify PCCB POOL allocated by "dma_alloc_coherent"
** (Kornel Wieliczek's comment)
** 1.20.00.07 3/23/2005 Erich Chen bug fix with arcmsr_scsi_host_template_init
** occur segmentation fault,
** if RAID adapter does not on PCI slot
** and modprobe/rmmod this driver twice.
** bug fix enormous stack usage (Adrian Bunk's comment)
** 1.20.00.08 6/23/2005 Erich Chen bug fix with abort command,
** in case of heavy loading when sata cable
** working on low quality connection
** 1.20.00.09 9/12/2005 Erich Chen bug fix with abort command handling, firmware version check
** and firmware update notify for hardware bug fix
** 1.20.00.10 9/23/2005 Erich Chen enhance sysfs function for change driver's max tag Q number.
** add DMA_64BIT_MASK for backward compatible with all 2.6.x
** add some useful message for abort command
** add ioctl code 'ARCMSR_IOCTL_FLUSH_ADAPTER_CACHE'
** customer can send this command for sync raid volume data
** 1.20.00.11 9/29/2005 Erich Chen by comment of Arjan van de Ven fix incorrect msleep redefine
** cast off sizeof(dma_addr_t) condition for 64bit pci_set_dma_mask
** 1.20.00.12 9/30/2005 Erich Chen bug fix with 64bit platform's ccbs using if over 4G system memory
** change 64bit pci_set_consistent_dma_mask into 32bit
** increcct adapter count if adapter initialize fail.
** miss edit at arcmsr_build_ccb....
** psge += sizeof(struct _SG64ENTRY *) =>
** psge += sizeof(struct _SG64ENTRY)
** 64 bits sg entry would be incorrectly calculated
** thanks Kornel Wieliczek give me kindly notify
** and detail description
** 1.20.00.13 11/15/2005 Erich Chen scheduling pending ccb with FIFO
** change the architecture of arcmsr command queue list
** for linux standard list
** enable usage of pci message signal interrupt
** follow Randy.Danlup kindness suggestion cleanup this code
** 1.20.00.14 05/02/2007 Erich Chen & Nick Cheng
** 1.implement PCI-Express error recovery function and AER capability
** 2.implement the selection of ARCMSR_MAX_XFER_SECTORS_B=4096
** if firmware version is newer than 1.42
** 3.modify arcmsr_iop_reset to improve the ability
** 4.modify the ISR, arcmsr_interrupt routine,to prevent the
** inconsistency with sg_mod driver if application directly calls
** the arcmsr driver w/o passing through scsi mid layer
** specially thanks to Yanmin Zhang's openhanded help about AER
** 1.20.00.15 08/30/2007 Erich Chen & Nick Cheng
** 1. support ARC1200/1201/1202 SATA RAID adapter, which is named
** ACB_ADAPTER_TYPE_B
** 2. modify the arcmsr_pci_slot_reset function
** 3. modify the arcmsr_pci_ers_disconnect_forepart function
** 4. modify the arcmsr_pci_ers_need_reset_forepart function
** 1.20.00.15 09/27/2007 Erich Chen & Nick Cheng
** 1. add arcmsr_enable_eoi_mode() on adapter Type B
** 2. add readl(reg->iop2drv_doorbell_reg) in arcmsr_handle_hbb_isr()
** in case of the doorbell interrupt clearance is cached
** 1.20.00.15 10/01/2007 Erich Chen & Nick Cheng
** 1. modify acb->devstate[i][j]
** as ARECA_RAID_GOOD instead of
** ARECA_RAID_GONE in arcmsr_alloc_ccb_pool
** 1.20.00.15 11/06/2007 Erich Chen & Nick Cheng
** 1. add conditional declaration for
** arcmsr_pci_error_detected() and
** arcmsr_pci_slot_reset
** 1.20.00.15 11/23/2007 Erich Chen & Nick Cheng
** 1.check if the sg list member number
** exceeds arcmsr default limit in arcmsr_build_ccb()
** 2.change the returned value type of arcmsr_build_ccb()
** from "void" to "int"
** 3.add the conditional check if arcmsr_build_ccb()
** returns FAILED
** 1.20.00.15 12/04/2007 Erich Chen & Nick Cheng
** 1. modify arcmsr_drain_donequeue() to ignore unknown
** command and let kernel process command timeout.
** This could handle IO request violating max. segments
** while Linux XFS over DM-CRYPT.
** Thanks to Milan Broz's comments <mbroz@redhat.com>
** 1.20.00.15 12/24/2007 Erich Chen & Nick Cheng
** 1.fix the portability problems
** 2.fix type B where we should _not_ iounmap() acb->pmu;
** it's not ioremapped.
** 3.add return -ENOMEM if ioremap() fails
** 4.transfer IS_SG64_ADDR w/ cpu_to_le32()
** in arcmsr_build_ccb
** 5. modify acb->devstate[i][j] as ARECA_RAID_GONE instead of
** ARECA_RAID_GOOD in arcmsr_alloc_ccb_pool()
** 6.fix arcmsr_cdb->Context as (unsigned long)arcmsr_cdb
** 7.add the checking state of
** (outbound_intstatus & ARCMSR_MU_OUTBOUND_HANDLE_INT) == 0
** in arcmsr_handle_hba_isr
** 8.replace pci_alloc_consistent()/pci_free_consistent() with kmalloc()/kfree() in arcmsr_iop_message_xfer()
** 9. fix the release of dma memory for type B in arcmsr_free_ccb_pool()
** 10.fix the arcmsr_polling_hbb_ccbdone()
** 1.20.00.15 02/27/2008 Erich Chen & Nick Cheng
** 1.arcmsr_iop_message_xfer() is called from atomic context under the
** queuecommand scsi_host_template handler. James Bottomley pointed out
** that the current GFP_KERNEL|GFP_DMA flags are wrong: firstly we are in
** atomic context, secondly this memory is not used for DMA.
** Also removed some unneeded casts. Thanks to Daniel Drake <dsd@gentoo.org>
**************************************************************************

122
Documentation/scsi/ChangeLog.ips Normal file
View file

@ -0,0 +1,122 @@
IBM ServeRAID driver Change Log
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5.00.01 - Sarasota ( 5i ) adapters must always be scanned first
- Get rid on IOCTL_NEW_COMMAND code
- Add Extended DCDB Commands for Tape Support in 5I
4.90.11 - Don't actually RESET unless it's physically required
- Remove unused compile options
4.90.08 - Data Corruption if First Scatter Gather Element is > 64K
4.90.08 - Increase Delays in Flashing ( Trombone Only - 4H )
4.90.05 - Use New PCI Architecture to facilitate Hot Plug Development
4.90.01 - Add ServeRAID Version Checking
4.80.26 - Clean up potential code problems ( Arjan's recommendations )
4.80.21 - Change memcpy() to copy_to_user() in NVRAM Page 5 IOCTL path
4.80.20 - Set max_sectors in Scsi_Host structure ( if >= 2.4.7 kernel )
- 5 second delay needed after resetting an i960 adapter
4.80.14 - Take all semaphores off stack
- Clean Up New_IOCTL path
4.80.04 - Eliminate calls to strtok() if 2.4.x or greater
- Adjustments to Device Queue Depth
4.80.00 - Make ia64 Safe
4.72.01 - I/O Mapped Memory release ( so "insmod ips" does not Fail )
- Don't Issue Internal FFDC Command if there are Active Commands
- Close Window for getting too many IOCTL's active
4.72.00 - Allow for a Scatter-Gather Element to exceed MAX_XFER Size
4.71.00 - Change all memory allocations to not use GFP_DMA flag
- Code Clean-Up for 2.4.x kernel
4.70.15 - Fix Breakup for very large ( non-SG ) requests
4.70.13 - Don't release HA Lock in ips_next() until SC taken off queue
- Unregister SCSI device in ips_release()
- Don't Send CDB's if we already know the device is not present
4.70.12 - Corrective actions for bad controller ( during initialization )
4.70.09 - Use a Common ( Large Buffer ) for Flashing from the JCRM CD
- Add IPSSEND Flash Support
- Set Sense Data for Unknown SCSI Command
- Use Slot Number from NVRAM Page 5
- Restore caller's DCDB Structure
4.20.14 - Update patch files for kernel 2.4.0-test5
4.20.13 - Fix some failure cases / reset code
- Hook into the reboot_notifier to flush the controller
cache
4.20.03 - Rename version to coincide with new release schedules
- Performance fixes
- Fix truncation of /proc files with cat
- Merge in changes through kernel 2.4.0test1ac21
4.10.13 - Fix for dynamic unload and proc file system
4.10.00 - Add support for ServeRAID 4M/4L
4.00.06 - Fix timeout with initial FFDC command
4.00.05 - Remove wish_block from init routine
- Use linux/spinlock.h instead of asm/spinlock.h for kernels
2.3.18 and later
- Sync with other changes from the 2.3 kernels
4.00.04 - Rename structures/constants to be prefixed with IPS_
4.00.03 - Add alternative passthru interface
- Add ability to flash ServeRAID BIOS
4.00.02 - Fix problem with PT DCDB with no buffer
4.00.01 - Add support for First Failure Data Capture
4.00.00 - Add support for ServeRAID 4
3.60.02 - Make DCDB direction based on lookup table.
- Only allow one DCDB command to a SCSI ID at a time.
3.60.01 - Remove bogus error check in passthru routine.
3.60.00 - Bump max commands to 128 for use with ServeRAID
firmware 3.60.
- Change version to 3.60 to coincide with ServeRAID release
numbering.
1.00.00 - Initial Public Release
- Functionally equivalent to 0.99.05
0.99.05 - Fix an oops on certain passthru commands
0.99.04 - Fix race condition in the passthru mechanism
-- this required the interface to the utilities to change
- Fix error recovery code
0.99.03 - Make interrupt routine handle all completed request on the
adapter not just the first one
- Make sure passthru commands get woken up if we run out of
SCBs
- Send all of the commands on the queue at once rather than
one at a time since the card will support it.
0.99.02 - Added some additional debug statements to print out
errors if an error occurs while trying to read/write
to a logical drive (IPS_DEBUG).
- Fixed read/write errors when the adapter is using an
8K stripe size.

1865
Documentation/scsi/ChangeLog.lpfc Normal file
View file

File diff suppressed because it is too large Load diff

614
Documentation/scsi/ChangeLog.megaraid Normal file
View file

@ -0,0 +1,614 @@
Release Date : Thu Nov 16 15:32:35 EST 2006 -
Sumant Patro <sumant.patro@lsi.com>
Current Version : 2.20.5.1 (scsi module), 2.20.2.6 (cmm module)
Older Version : 2.20.4.9 (scsi module), 2.20.2.6 (cmm module)
1. Changes in Initialization to fix kdump failure.
Send SYNC command on loading.
This command clears the pending commands in the adapter
and re-initialize its internal RAID structure.
Without this change, megaraid driver either panics or fails to
initialize the adapter during kdump's second kernel boot
if there are pending commands or interrupts from other devices
sharing the same IRQ.
2. Authors email-id domain name changed from lsil.com to lsi.com.
Also modified the MODULE_AUTHOR to megaraidlinux@lsi.com
Release Date : Fri May 19 09:31:45 EST 2006 - Seokmann Ju <sju@lsil.com>
Current Version : 2.20.4.9 (scsi module), 2.20.2.6 (cmm module)
Older Version : 2.20.4.8 (scsi module), 2.20.2.6 (cmm module)
1. Fixed a bug in megaraid_init_mbox().
Customer reported "garbage in file on x86_64 platform".
Root Cause: the driver registered controllers as 64-bit DMA capable
for those which are not support it.
Fix: Made change in the function inserting identification machanism
identifying 64-bit DMA capable controllers.
> -----Original Message-----
> From: Vasily Averin [mailto:vvs@sw.ru]
> Sent: Thursday, May 04, 2006 2:49 PM
> To: linux-scsi@vger.kernel.org; Kolli, Neela; Mukker, Atul;
> Ju, Seokmann; Bagalkote, Sreenivas;
> James.Bottomley@SteelEye.com; devel@openvz.org
> Subject: megaraid_mbox: garbage in file
>
> Hello all,
>
> I've investigated customers claim on the unstable work of
> their node and found a
> strange effect: reading from some files leads to the
> "attempt to access beyond end of device" messages.
>
> I've checked filesystem, memory on the node, motherboard BIOS
> version, but it
> does not help and issue still has been reproduced by simple
> file reading.
>
> Reproducer is simple:
>
> echo 0xffffffff >/proc/sys/dev/scsi/logging_level ;
> cat /vz/private/101/root/etc/ld.so.cache >/tmp/ttt ;
> echo 0 >/proc/sys/dev/scsi/logging
>
> It leads to the following messages in dmesg
>
> sd_init_command: disk=sda, block=871769260, count=26
> sda : block=871769260
> sda : reading 26/26 512 byte blocks.
> scsi_add_timer: scmd: f79ed980, time: 7500, (c02b1420)
> sd 0:1:0:0: send 0xf79ed980 sd 0:1:0:0:
> command: Read (10): 28 00 33 f6 24 ac 00 00 1a 00
> buffer = 0xf7cfb540, bufflen = 13312, done = 0xc0366b40,
> queuecommand 0xc0344010
> leaving scsi_dispatch_cmnd()
> scsi_delete_timer: scmd: f79ed980, rtn: 1
> sd 0:1:0:0: done 0xf79ed980 SUCCESS 0 sd 0:1:0:0:
> command: Read (10): 28 00 33 f6 24 ac 00 00 1a 00
> scsi host busy 1 failed 0
> sd 0:1:0:0: Notifying upper driver of completion (result 0)
> sd_rw_intr: sda: res=0x0
> 26 sectors total, 13312 bytes done.
> use_sg is 4
> attempt to access beyond end of device
> sda6: rw=0, want=1044134458, limit=951401367
> Buffer I/O error on device sda6, logical block 522067228
> attempt to access beyond end of device
2. When INQUIRY with EVPD bit set issued to the MegaRAID controller,
system memory gets corrupted.
Root Cause: MegaRAID F/W handle the INQUIRY with EVPD bit set
incorrectly.
Fix: MegaRAID F/W has fixed the problem and being process of release,
soon. Meanwhile, driver will filter out the request.
3. One of member in the data structure of the driver leads unaligne
issue on 64-bit platform.
Customer reporeted "kernel unaligned access addrss" issue when
application communicates with MegaRAID HBA driver.
Root Cause: in uioc_t structure, one of member had misaligned and it
led system to display the error message.
Fix: A patch submitted to community from following folk.
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Sakurai Hiroomi
> Sent: Wednesday, July 12, 2006 4:20 AM
> To: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Help: strange messages from kernel on IA64 platform
>
> Hi,
>
> I saw same message.
>
> When GAM(Global Array Manager) is started, The following
> message output.
> kernel: kernel unaligned access to 0xe0000001fe1080d4,
> ip=0xa000000200053371
>
> The uioc structure used by ioctl is defined by packed,
> the allignment of each member are disturbed.
> In a 64 bit structure, the allignment of member doesn't fit 64 bit
> boundary. this causes this messages.
> In a 32 bit structure, we don't see the message because the allinment
> of member fit 32 bit boundary even if packed is specified.
>
> patch
> I Add 32 bit dummy member to fit 64 bit boundary. I tested.
> We confirmed this patch fix the problem by IA64 server.
>
> **************************************************************
> ****************
> --- linux-2.6.9/drivers/scsi/megaraid/megaraid_ioctl.h.orig
> 2006-04-03 17:13:03.000000000 +0900
> +++ linux-2.6.9/drivers/scsi/megaraid/megaraid_ioctl.h
> 2006-04-03 17:14:09.000000000 +0900
> @@ -132,6 +132,10 @@
> /* Driver Data: */
> void __user * user_data;
> uint32_t user_data_len;
> +
> + /* 64bit alignment */
> + uint32_t pad_0xBC;
> +
> mraid_passthru_t __user *user_pthru;
>
> mraid_passthru_t *pthru32;
> **************************************************************
> ****************
Release Date : Mon Apr 11 12:27:22 EST 2006 - Seokmann Ju <sju@lsil.com>
Current Version : 2.20.4.8 (scsi module), 2.20.2.6 (cmm module)
Older Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module)
1. Fixed a bug in megaraid_reset_handler().
Customer reported "Unable to handle kernel NULL pointer dereference
at virtual address 00000000" when system goes to reset condition
for some reason. It happened randomly.
Root Cause: in the megaraid_reset_handler(), there is possibility not
returning pending packets in the pend_list if there are multiple
pending packets.
Fix: Made the change in the driver so that it will return all packets
in the pend_list.
2. Added change request.
As found in the following URL, rmb() only didn't help the
problem. I had to increase the loop counter to 0xFFFFFF. (6 F's)
http://marc.theaimsgroup.com/?l=linux-scsi&m=110971060502497&w=2
I attached a patch for your reference, too.
Could you check and get this fix in your driver?
Best Regards,
Jun'ichi Nomura
Release Date : Fri Nov 11 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
Current Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module)
Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
1. Sorted out PCI IDs to remove megaraid support overlaps.
Based on the patch from Daniel, sorted out PCI IDs along with
character node name change from 'megadev' to 'megadev_legacy' to avoid
conflict.
---
Hopefully we'll be getting the build restriction zapped much sooner,
but we should also be thinking about totally removing the hardware
support overlap in the megaraid drivers.
This patch pencils in a date of Feb 06 for this, and performs some
printk abuse in hope that existing legacy users might pick up on what's
going on.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
---
2. Fixed a issue: megaraid always fails to reset handler.
---
I found that the megaraid driver always fails to reset the
adapter with the following message:
megaraid: resetting the host...
megaraid mbox: reset sequence completed successfully
megaraid: fast sync command timed out
megaraid: reservation reset failed
when the "Cluster mode" of the adapter BIOS is enabled.
So, whenever the reset occurs, the adapter goes to
offline and just become unavailable.
Jun'ichi Nomura [mailto:jnomura@mtc.biglobe.ne.jp]
---
Release Date : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
1. Added IOCTL backward compatibility.
Convert megaraid_mm driver to new compat_ioctl entry points.
I don't have easy access to hardware, so only compile tested.
- Signed-off-by:Andi Kleen <ak@muc.de>
2. megaraid_mbox fix: wrong order of arguments in memset()
That, BTW, shows why cross-builds are useful-the only indication of
problem had been a new warning showing up in sparse output on alpha
build (number of exceeding 256 got truncated).
- Signed-off-by: Al Viro
<viro@parcelfarce.linux.theplanet.co.uk>
3. Convert pci_module_init to pci_register_driver
Convert from pci_module_init to pci_register_driver
(from:http://kernelnewbies.org/KernelJanitors/TODO)
- Signed-off-by: Domen Puncer <domen@coderock.org>
4. Use the pre defined DMA mask constants from dma-mapping.h
Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistend_dma_mask(). See
http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for more
details.
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
5. Remove SSID checking for Dobson, Lindsay, and Verde based products.
Checking the SSVID/SSID for controllers which have Dobson, Lindsay,
and Verde is unnecessary because device ID has been assigned by LSI
and it is unique value. So, all controllers with these IOPs have to be
supported by the driver regardless SSVID/SSID.
6. Date Thu, 27 Jan 2005 04:31:09 +0100
From Herbert Poetzl <>
Subject RFC: assert_spin_locked() for 2.6
Greetings!
overcautious programming will kill your kernel ;)
ever thought about checking a spin_lock or even
asserting that it must be held (maybe just for
spinlock debugging?) ...
there are several checks present in the kernel
where somebody does a variation on the following:
BUG_ON(!spin_is_locked(&some_lock));
so what's wrong about that? nothing, unless you
compile the code with CONFIG_DEBUG_SPINLOCK but
without CONFIG_SMP ... in which case the BUG()
will kill your kernel ...
maybe it's not advised to make such assertions,
but here is a solution which works for me ...
(compile tested for sh, x86_64 and x86, boot/run
tested for x86 only)
best,
Herbert
- Herbert Poetzl <herbert@13thfloor.at>, Thu, 27 Jan 2005
Release Date : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
Current Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
Older Version : 2.20.4.4 (scsi module), 2.20.2.4 (cmm module)
1. Modified name of two attributes in scsi_host_template.
On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote:
> + .sdev_attrs = megaraid_device_attrs,
> + .shost_attrs = megaraid_class_device_attrs,
These are, perhaps, slightly confusing names.
The terms device and class_device have well defined meanings in the
generic device model, neither of which is what you mean here.
Why not simply megaraid_sdev_attrs and megaraid_shost_attrs?
Other than this, it looks fine to me too.
Release Date : Thu Jan 27 00:01:03 EST 2005 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.4.4 (scsi module), 2.20.2.5 (cmm module)
Older Version : 2.20.4.3 (scsi module), 2.20.2.4 (cmm module)
1. Bump up the version of scsi module due to its conflict.
Release Date : Thu Jan 21 00:01:03 EST 2005 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.4.3 (scsi module), 2.20.2.5 (cmm module)
Older Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module)
1. Remove driver ioctl for logical drive to scsi address translation and
replace with the sysfs attribute. To remove drives and change
capacity, application shall now use the device attribute to get the
logical drive number for a scsi device. For adding newly created
logical drives, class device attribute would be required to uniquely
identify each controller.
- Atul Mukker <atulm@lsil.com>
"James, I've been thinking about this a little more, and you may be on
to something here. Let each driver add files as such:"
- Matt Domsch <Matt_Domsch@dell.com>, 12.15.2004
linux-scsi mailing list
"Then, if you simply publish your LD number as an extra parameter of
the device, you can look through /sys to find it."
- James Bottomley <James.Bottomley@SteelEye.com>, 01.03.2005
linux-scsi mailing list
"I don't see why not ... it's your driver, you can publish whatever
extra information you need as scsi_device attributes; that was one of
the designs of the extensible attribute system."
- James Bottomley <James.Bottomley@SteelEye.com>, 01.06.2005
linux-scsi mailing list
2. Add AMI megaraid support - Brian King <brking@charter.net>
PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
PCI_VENDOR_ID_AMI, PCI_SUBSYS_ID_PERC3_DC,
3. Make some code static - Adrian Bunk <bunk@stusta.de>
Date: Mon, 15 Nov 2004 03:14:57 +0100
The patch below makes some needlessly global code static.
-wait_queue_head_t wait_q;
+static wait_queue_head_t wait_q;
Signed-off-by: Adrian Bunk <bunk@stusta.de>
4. Added NEC ROMB support - NEC MegaRAID PCI Express ROMB controller
PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_MEGARAID_NEC_ROMB_2E,
PCI_SUBSYS_ID_NEC, PCI_SUBSYS_ID_MEGARAID_NEC_ROMB_2E,
5. Fixed Tape drive issue : For any Direct CDB command to physical device
including tape, timeout value set by driver was 10 minutes. With this
value, most of command will return within timeout. However, for those
command like ERASE or FORMAT, it takes more than an hour depends on
capacity of the device and the command could be terminated before it
completes.
To address this issue, the 'timeout' field in the DCDB command will
have NO TIMEOUT (i.e., 4) value as its timeout on DCDB command.
Release Date : Thu Dec 9 19:10:23 EST 2004
- Sreenivas Bagalkote <sreenib@lsil.com>
Current Version : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module)
Older Version : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module)
i. Introduced driver ioctl that returns scsi address for a given ld.
"Why can't the existing sysfs interfaces be used to do this?"
- Brian King (brking@us.ibm.com)
"I've looked into solving this another way, but I cannot see how
to get this driver-private mapping of logical drive number-> HCTL
without putting code something like this into the driver."
"...and by providing a mapping a function to userspace, the driver
is free to change its mapping algorithm in the future if necessary .."
- Matt Domsch (Matt_Domsch@dell.com)
Release Date : Thu Dec 9 19:02:14 EST 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
Current Version : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module)
Older Version : 2.20.4.1 (scsi module), 2.20.2.2 (cmm module)
i. Fix a bug in kioc's dma buffer deallocation
Release Date : Thu Nov 4 18:24:56 EST 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
Current Version : 2.20.4.1 (scsi module), 2.20.2.2 (cmm module)
Older Version : 2.20.4.0 (scsi module), 2.20.2.1 (cmm module)
i. Handle IOCTL cmd timeouts more properly.
ii. pci_dma_sync_{sg,single}_for_cpu was introduced into megaraid_mbox
incorrectly (instead of _for_device). Changed to appropriate
pci_dma_sync_{sg,single}_for_device.
Release Date : Wed Oct 06 11:15:29 EDT 2004 - Sreenivas Bagalkote <sreenib@lsil.com>
Current Version : 2.20.4.0 (scsi module), 2.20.2.1 (cmm module)
Older Version : 2.20.4.0 (scsi module), 2.20.2.0 (cmm module)
i. Remove CONFIG_COMPAT around register_ioctl32_conversion
Release Date : Mon Sep 27 22:15:07 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.4.0 (scsi module), 2.20.2.0 (cmm module)
Older Version : 2.20.3.1 (scsi module), 2.20.2.0 (cmm module)
i. Fix data corruption. Because of a typo in the driver, the IO packets
were wrongly shared by the ioctl path. This causes a whole IO command
to be replaced by an incoming ioctl command.
Release Date : Tue Aug 24 09:43:35 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.3.1 (scsi module), 2.20.2.0 (cmm module)
Older Version : 2.20.3.0 (scsi module), 2.20.2.0 (cmm module)
i. Function reordering so that inline functions are defined before they
are actually used. It is now mandatory for GCC 3.4.1 (current stable)
Declare some heavy-weight functions to be non-inlined,
megaraid_mbox_build_cmd, megaraid_mbox_runpendq,
megaraid_mbox_prepare_pthru, megaraid_mbox_prepare_epthru,
megaraid_busywait_mbox
- Andrew Morton, 08.19.2004
linux-scsi mailing list
"Something else to clean up after inclusion: every instance of an
inline function is actually rendered as a full function call, because
the function is always used before it is defined. Atul, please
re-arrange the code to eliminate the need for most (all) of the
function prototypes at the top of each file, and define (not just
declare with a prototype) each inline function before its first use"
- Matt Domsch <Matt_Domsch@dell.com>, 07.27.2004
linux-scsi mailing list
ii. Display elapsed time (countdown) while waiting for FW to boot.
iii. Module compilation reorder in Makefile so that unresolved symbols do
not occur when driver is compiled non-modular.
Patrick J. LoPresti <patl@users.sourceforge.net>, 8.22.2004
linux-scsi mailing list
Release Date : Thu Aug 19 09:58:33 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.3.0 (scsi module), 2.20.2.0 (cmm module)
Older Version : 2.20.2.0 (scsi module), 2.20.1.0 (cmm module)
i. When copying the mailbox packets, copy only first 14 bytes (for 32-bit
mailboxes) and only first 22 bytes (for 64-bit mailboxes). This is to
avoid getting the stale values for busy bit. We want to set the busy
bit just before issuing command to the FW.
ii. In the reset handling, if the reseted command is not owned by the
driver, do not (wrongly) print information for the "attached" driver
packet.
iii. Have extended wait when issuing command in synchronous mode. This is
required for the cases where the option ROM is disabled and there is
no BIOS to start the controller. The FW starts to boot after receiving
the first command from the driver. The current driver has 1 second
timeout for the synchronous commands, which is far less than what is
actually required. We now wait up to MBOX_RESET_TIME (180 seconds) for
FW boot process.
iv. In megaraid_mbox_product_info, clear the mailbox contents completely
before preparing the command for inquiry3. This is to ensure that the
FW does not get junk values in the command.
v. Do away with the redundant LSI_CONFIG_COMPAT redefinition for
CONFIG_COMPAT. Replace <asm/ioctl32.h> with <linux/ioctl32.h>
- James Bottomley <James.Bottomley@SteelEye.com>, 08.17.2004
linux-scsi mailing list
vi. Add support for 64-bit applications. Current drivers assume only
32-bit applications, even on 64-bit platforms. Use the "data" and
"buffer" fields of the mimd_t structure, instead of embedded 32-bit
addresses in application mailbox and passthru structures.
vii. Move the function declarations for the management module from
megaraid_mm.h to megaraid_mm.c
- Andrew Morton, 08.19.2004
linux-scsi mailing list
viii. Change default values for MEGARAID_NEWGEN, MEGARAID_MM, and
MEGARAID_MAILBOX to 'n' in Kconfig.megaraid
- Andrew Morton, 08.19.2004
linux-scsi mailing list
ix. replace udelay with msleep
x. Typos corrected in comments and whitespace adjustments, explicit
grouping of expressions.
Release Date : Fri Jul 23 15:22:07 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.2.0 (scsi module), 2.20.1.0 (cmm module)
Older Version : 2.20.1.0 (scsi module), 2.20.0.0 (cmm module)
i. Add PCI ids for Acer ROMB 2E solution
ii. Add PCI ids for I4
iii. Typo corrected for subsys id for megaraid sata 300-4x
iv. Remove yield() while mailbox handshake in synchronous commands
"My other main gripe is things like this:
+ // wait for maximum 1 second for status to post
+ for (i = 0; i < 40000; i++) {
+ if (mbox->numstatus != 0xFF) break;
+ udelay(25); yield();
+ }
which litter the driver. Use of yield() in drivers is deprecated."
- James Bottomley <James.Bottomley@SteelEye.com>, 07.14.2004
linux-scsi mailing list
v. Remove redundant __megaraid_busywait_mbox routine
vi. Fix bug in the management module, which causes a system lockup when the
IO module is loaded and then unloaded, followed by executing any
management utility. The current version of management module does not
handle the adapter unregister properly.
Specifically, it still keeps a reference to the unregistered
controllers. To avoid this, the static array adapters has been
replaced by a dynamic list, which gets updated every time an adapter
is added or removed.
Also, during unregistration of the IO module, the resources are
now released in the exact reverse order of the allocation time
sequence.
Release Date : Fri Jun 25 18:58:43 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.1.0
Older Version : megaraid 2.20.0.1
i. Stale list pointer in adapter causes kernel panic when module
megaraid_mbox is unloaded
Release Date : Thu Jun 24 20:37:11 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.0.1
Older Version : megaraid 2.20.0.00
i. Modules are not 'y' by default, but depend on current definition of
SCSI & PCI.
ii. Redundant structure mraid_driver_t removed.
iii. Miscellaneous indentation and goto/label fixes.
- Christoph Hellwig <hch@infradead.org>, 06.24.2004 linux-scsi
iv. scsi_host_put(), do just before completing HBA shutdown.
Release Date : Mon Jun 21 19:53:54 EDT 2004 - Atul Mukker <atulm@lsil.com>
Current Version : 2.20.0.0
Older Version : megaraid 2.20.0.rc2 and 2.00.3
i. Independent module to interact with userland applications and
multiplex command to low level RAID module(s).
"Shared code in a third module, a "library module", is an acceptable
solution. modprobe automatically loads dependent modules, so users
running "modprobe driver1" or "modprobe driver2" would automatically
load the shared library module."
- Jeff Garzik <jgarzik@pobox.com> 02.25.2004 LKML
"As Jeff hinted, if your userspace<->driver API is consistent between
your new MPT-based RAID controllers and your existing megaraid driver,
then perhaps you need a single small helper module (lsiioctl or some
better name), loaded by both mptraid and megaraid automatically, which
handles registering the /dev/megaraid node dynamically. In this case,
both mptraid and megaraid would register with lsiioctl for each
adapter discovered, and lsiioctl would essentially be a switch,
redirecting userspace tool ioctls to the appropriate driver."
- Matt Domsch <Matt_Domsch@dell.com> 02.25.2004 LKML
ii. Remove C99 initializations from pci_device id.
"pci_id_table_g would be much more readable when not using C99
initializers.
PCI table doesn't change, there's lots of users that prefer the more
readable variant. And it's really far less and much easier to grok
lines without C99 initializers."
- Christoph Hellwig <hch@infradead.org>, 05.28.2004 linux-scsi
iii. Many fixes as suggested by Christoph Hellwig <hch@infradead.org> on
linux-scsi, 05.28.2004
iv. We now support up to 32 parallel ioctl commands instead of current 1.
There is a conscious effort to let memory allocation not fail for ioctl
commands.
v. Do away with internal memory management. Use pci_pool_(create|alloc)
instead.
vi. Kill tasklet when unloading the driver.
vii. Do not use "host_lock', driver has fine-grain locks now to protect all
data structures.
viii. Optimize the build scatter-gather list routine. The callers already
know the data transfer address and length.
ix. Better implementation of error handling and recovery. Driver now
performs extended errors recovery for instances like scsi cable pull.
x. Disassociate the management commands with an overlaid scsi command.
Driver now treats the management packets as special packets and has a
dedicated callback routine.

641
Documentation/scsi/ChangeLog.megaraid_sas Normal file
View file

@ -0,0 +1,641 @@
Release Date : Thu. Jun 19, 2014 17:00:00 PST 2014 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Kashyap Desai
Sumit Saxena
Uday Lingala
Current Version : 06.803.02.00-rc1
Old Version : 06.803.01.00-rc1
1. Fix reset_mutex leak in megasas_reset_fusion().
2. Remove unused variables in megasas_instance.
3. Fix LD/VF affiliation parsing.
4. Add missing initial call to megasas_get_ld_vf_affiliation().
5. Version and Changelog update.
-------------------------------------------------------------------------------
Release Date : Mon. Mar 10, 2014 17:00:00 PST 2014 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Kashyap Desai
Sumit Saxena
Current Version : 06.803.01.00-rc1
Old Version : 06.700.06.00-rc1
1. Load correct raid context timeout value for multipathing & clustering.
2. Fix megasas_ioc_init_fusion to use local stack variable.
3. Return leaked MPT frames to MPT command pool.
4. Add Dell PowerEdge VRTX SR-IOV VF device support.
5. Version and Changelog update.
-------------------------------------------------------------------------------
Release Date : Sat. Aug 31, 2013 17:00:00 PST 2013 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Kashyap Desai
Sumit Saxena
Current Version : 06.700.06.00-rc1
Old Version : 06.600.18.00-rc1
1. Add High Availability clustering support using shared Logical Disks.
2. Version and Changelog update.
-------------------------------------------------------------------------------
Release Date : Wed. May 15, 2013 17:00:00 PST 2013 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Kashyap Desai
Sumit Saxena
Current Version : 06.600.18.00-rc1
Old Version : 06.506.00.00-rc1
1. Return DID_ERROR for scsi io, when controller is in critical h/w error.
2. Fix the interrupt mask for Gen2 controller.
3. Update balance count in driver to be in sync of firmware.
4. Free event detail memory without device ID check.
5. Set IO request timeout value provided by OS timeout for Tape devices.
6. Add support for MegaRAID Fury (device ID-0x005f) 12Gb/s controllers.
7. Add support to display Customer branding details in syslog.
8. Set IoFlags to enable Fast Path for JBODs for Invader/Fury(12 Gb/s)
controllers.
9. Add support for Extended MSI-x vectors for Invader and Fury(12Gb/s
HBA).
10.Add support for Uneven Span PRL11.
11.Add support to differentiate between iMR and MR Firmware.
12.Version and Changelog update.
-------------------------------------------------------------------------------
Release Date : Sat. Feb 9, 2013 17:00:00 PST 2013 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 06.506.00.00-rc1
Old Version : 06.504.01.00-rc1
1. Add 4k FastPath DIF support.
2. Dont load DevHandle unless FastPath enabled.
3. Version and Changelog update.
-------------------------------------------------------------------------------
Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 06.504.01.00-rc1
Old Version : 00.00.06.18-rc1
1. Removed un-needed completion_lock spinlock calls.
2. Add module param for configurable MSI-X vector count.
3. Load io_request DataLength in bytes.
4. Add array boundary check for SystemPD.
5. Add SystemPD FastPath support.
6. Remove duplicate code.
7. Version, Changelog, Copyright update.
-------------------------------------------------------------------------------
Release Date : Tue. Jun 17, 2012 17:00:00 PST 2012 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford/Kashyap Desai
Current Version : 00.00.06.18-rc1
Old Version : 00.00.06.15-rc1
1. Fix Copyright dates.
2. Add throttlequeuedepth module parameter.
3. Add resetwaittime module parameter.
4. Move poll_aen_lock initializer.
-------------------------------------------------------------------------------
Release Date : Mon. Mar 19, 2012 17:00:00 PST 2012 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.06.15-rc1
Old Version : 00.00.06.14-rc1
1. Optimize HostMSIxVectors setting.
2. Add fpRead/WriteCapable, fpRead/WriteAcrossStripe checks.
-------------------------------------------------------------------------------
Release Date : Fri. Jan 6, 2012 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.06.14-rc1
Old Version : 00.00.06.12-rc1
1. Fix reglockFlags for degraded raid5/6 for MR 9360/9380.
2. Mask off flags in ioctl path to prevent memory scribble with older
MegaCLI versions.
3. Remove poll_mode_io module paramater, sysfs node, and associated code.
-------------------------------------------------------------------------------
Release Date : Wed. Oct 5, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.06.12-rc1
Old Version : 00.00.05.40-rc1
1. Continue booting immediately if FW in FAULT at driver load time.
2. Increase default cmds per lun to 256.
3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock.
4. Remove some un-necessary code.
5. Clear state change interrupts for Fusion/Invader.
6. Clear FUSION_IN_RESET before enabling interrupts.
7. Add support for MegaRAID 9360/9380 12GB/s controllers.
8. Add multiple MSI-X vector/multiple reply queue support.
9. Add driver workaround for PERC5/1068 kdump kernel panic.
-------------------------------------------------------------------------------
Release Date : Tue. Jul 26, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.05.40-rc1
Old Version : 00.00.05.38-rc1
1. Fix FastPath I/O to work with degraded RAID 1.
2. Add .change_queue_depth support.
-------------------------------------------------------------------------------
Release Date : Wed. May 11, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.05.38-rc1
Old Version : 00.00.05.34-rc1
1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable.
2. Remove un-used function megasas_return_cmd_for_smid().
3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion().
4. Disable interrupts/free_irq() in megasas_shutdown().
5. Fix bug where AENs could be lost in probe() and resume().
6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath
IO.
7. Add 1078 OCR support.
-------------------------------------------------------------------------------
Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.05.34-rc1
Old Version : 00.00.05.29-rc1
1. Fix some failure gotos from megasas_probe_one(), etc.
2. Add missing check_and_restore_queue_depth() call in
complete_cmd_fusion().
3. Enable MSI-X before calling megasas_init_fw().
4. Call tasklet_schedule() even if outbound_intr_status == 0 for MFI based
boards in MSI-X mode.
5. Fix megasas_probe_one() to clear PCI_MSIX_FLAGS_ENABLE in msi control
register in kdump kernel.
6. Fix megasas_get_cmd() to only print "Command pool empty" if
megasas_dbg_lvl is set.
7. Fix megasas_build_dcdb_fusion() to not filter by TYPE_DISK.
8. Fix megasas_build_dcdb_fusion() to use io_request->LUN[1] field.
9. Add MR_EVT_CFG_CLEARED to megasas_aen_polling().
10. Fix tasklet_init() in megasas_init_fw() to use instancet->tasklet.
11. Fix fault state handling in megasas_transition_to_ready().
12. Fix max_sectors setting for IEEE SGL's.
13. Fix iMR OCR support to work correctly.
-------------------------------------------------------------------------------
Release Date : Tues. Dec 14, 2010 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.05.29-rc1
Old Version : 00.00.04.31-rc1
1. Rename megaraid_sas.c to megaraid_sas_base.c.
2. Update GPL headers.
3. Add MSI-X support and 'msix_disable' module parameter.
4. Use lowest memory bar (for SR-IOV VF support).
5. Add struct megasas_instance_temlate changes, and change all code to use
new instance entries:
irqreturn_t (*service_isr )(int irq, void *devp);
void (*tasklet)(unsigned long);
u32 (*init_adapter)(struct megasas_instance *);
u32 (*build_and_issue_cmd) (struct megasas_instance *,
struct scsi_cmnd *);
void (*issue_dcmd) (struct megasas_instance *instance,
struct megasas_cmd *cmd);
6. Add code to support MegaRAID 9265/9285 controllers device id (0x5b).
-------------------------------------------------------------------------------
1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.31-rc1
3 Older Version : 00.00.04.17.1-rc1
1. Add the Online Controller Reset (OCR) to the Driver.
OCR is the new feature for megaraid_sas driver which
will allow the fw to do the chip reset which will not
affact the OS behavious.
To add the OCR support, driver need to do:
a). reset the controller chips -- Xscale and Gen2 which
will change the function calls and add the reset function
related to this two chips.
b). during the reset, driver will store the pending cmds
which not returned by FW to driver's pending queue. Driver
will re-issue those pending cmds again to FW after the OCR
finished.
c). In driver's timeout routine, driver will report to
OS as reset. Also driver's queue routine will block the
cmds until the OCR finished.
d). in Driver's ISR routine, if driver get the FW state as
state change, FW in Failure status and FW support online controller
reset (OCR), driver will start to do the controller reset.
e). In driver's IOCTL routine, the application cmds will wait for the
OCR to finish, then issue the cmds to FW.
f). Before driver kill adapter, driver will do last chance of
OCR to see if driver can bring back the FW.
2. Add the support update flag to the driver to tell LSI megaraid_sas
application which driver will support the device update. So application
will not need to do the device update after application add/del the device
from the system.
3. In driver's timeout routine, driver will do three time reset if fw is in
failed state. Driver will kill adapter if can't bring back FW after the
this three times reset.
4. Add the input parameter max_sectors to 1MB support to our GEN2 controller.
customer can use the input paramenter max_sectors to add 1MB support to GEN2
controller.
1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.17.1-rc1
3 Older Version : 00.00.04.12
1. Add the pad_0 in mfi frame structure to 0 to fix the
context value larger than 32bit value issue.
2. Add the logic drive list to the driver. Driver will
keep the logic drive list internal after driver load.
3. driver fixed the device update issue after get the AEN
PD delete/ADD, LD add/delete from FW.
1 Release Date : Tues. July 28, 2009 10:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.12
3 Older Version : 00.00.04.10
1. Change the AEN sys PD update from scsi_scan to
scsi_add_device and scsi_remove_device.
2. Takeoff the debug print-out in aen_polling routine.
1 Release Date : Thur. July 02, 2009 10:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.10
3 Older Version : 00.00.04.08
1. Add the 3 mins timeout during the controller initialize.
2. Add the fix for 64bit sense date errors.
1 Release Date : Tues. May 05, 2009 10:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.08
3 Older Version : 00.00.04.06
1. Add the fix of pending in FW after deleted the logic drives.
2. Add the fix of deallocating memory after get pdlist.
1 Release Date : Tues. March 26, 2009 10:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.06
3 Older Version : 00.00.04.04
1. Add the fix of the driver cmd empty fix of the driver cmd empty.
2. Add the fix of the driver MSM AEN CMD cause the system slow.
1 Release Date : Tues. March 03, 2009 10:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.04
3 Older Version : 00.00.04.01
1. Add the Tape drive fix to the driver: If the command is for
the tape device, set the pthru timeout to the os layer timeout value.
2. Add Poll_wait mechanism to Gen-2 Linux driv.
In the aen handler, driver needs to wakeup poll handler similar to
the way it raises SIGIO.
3. Add new controller new SAS2 support to the driver.
4. Report the unconfigured PD (system PD) to OS.
5. Add the IEEE SGL support to the driver
6. Reasign the Application cmds to SAS2 controller
1 Release Date : Thur.July. 24 11:41:51 PST 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.04.01
3 Older Version : 00.00.03.22
1. Add the new controller (0078, 0079) support to the driver
Those controllers are LSI's next generatation(gen2) SAS controllers.
1 Release Date : Mon.June. 23 10:12:45 PST 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.22
3 Older Version : 00.00.03.20
1. Add shutdown DCMD cmd to the shutdown routine to make FW shutdown proper.
2. Unexpected interrupt occurs in HWR Linux driver, add the dumy readl pci flush will fix this issue.
1 Release Date : Mon. March 10 11:02:31 PDT 2008 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.20-RC1
3 Older Version : 00.00.03.16
1. Rollback the sense info implementation
Sense buffer ptr data type in the ioctl path is reverted back
to u32 * as in previous versions of driver.
2. Fixed the driver frame count.
When Driver sent wrong frame count to firmware. As this
particular command is sent to drive, FW is seeing continuous
chip resets and so the command will timeout.
3. Add the new controller(1078DE) support to the driver
and Increase the max_wait to 60 from 10 in the controller
operational status. With this max_wait increase, driver will
make sure the FW will finish the pending cmd for KDUMP case.
1 Release Date : Thur. Nov. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.16
3 Older Version : 00.00.03.15
1. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from 10. FW may take
a max of 60 seconds to respond to the INIT cmd.
1 Release Date : Fri. Sep. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.15
3 Older Version : 00.00.03.14
1. Added module parameter "poll_mode_io" to support for "polling"
(reduced interrupt operation). In this mode, IO completion
interrupts are delayed. At the end of initiating IOs, the
driver schedules for cmd completion if there are pending cmds
to be completed. A timer-based interrupt has also been added
to prevent IO completion processing from being delayed
indefinitely in the case that no new IOs are initiated.
1 Release Date : Fri. Sep. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.14
3 Older Version : 00.00.03.13
1. Setting the max_sectors_per_req based on max SGL supported by the
FW. Prior versions calculated this value from controller info
(max_sectors_1, max_sectors_2). For certain controllers/FW,
this was resulting in a value greater than max SGL supported
by the FW. Issue was first reported by users running LUKS+XFS
with megaraid_sas. Thanks to RB for providing the logs and
duplication steps that helped to get to the root cause of the
issue. 2. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from
10. FW may take a max of 60 seconds to respond to the INIT
cmd.
1 Release Date : Fri. June. 15 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.13
3 Older Version : 00.00.03.12
1. Added the megasas_reset_timer routine to intercept cmd timeout and throttle io.
On Fri, 2007-03-16 at 16:44 -0600, James Bottomley wrote:
It looks like megaraid_sas at least needs this to throttle its commands
> as they begin to time out. The code keeps the existing transport
> template use of eh_timed_out (and allows the transport to override the
> host if they both have this callback).
>
> James
1 Release Date : Sat May. 12 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.12
3 Older Version : 00.00.03.11
1. When MegaSAS driver receives reset call from OS, driver waits in reset
routine for max 3 minutes for all pending command completion. Now driver will
call completion routine every 5 seconds from the reset routine instead of
waiting for depending on cmd completion from isr path.
1 Release Date : Mon Apr. 30 10:25:52 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.11
3 Older Version : 00.00.03.09
1. Memory Manager for IOCTL removed for 2.6 kernels.
pci_alloc_consistent replaced by dma_alloc_coherent. With this
change there is no need of memory manager in the driver code
On Wed, 2007-02-07 at 13:30 -0800, Andrew Morton wrote:
> I suspect all this horror is due to stupidity in the DMA API.
>
> pci_alloc_consistent() just goes and assumes GFP_ATOMIC, whereas
> the caller (megasas_mgmt_fw_ioctl) would have been perfectly happy
> to use GFP_KERNEL.
>
> I bet this fixes it
It does, but the DMA API was expanded to cope with this exact case, so
use dma_alloc_coherent() directly in the megaraid code instead. The dev
is just &pci_dev->dev.
James <James.Bottomley@SteelEye.com>
3. SYNCHRONIZE_CACHE is not supported by FW and thus blocked by driver.
4. Hibernation support added
5. Performing diskdump while running IO in RHEL 4 was failing. Fixed.
1 Release Date : Fri Feb. 09 14:36:28 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.09
3 Older Version : 00.00.03.08
i. Under heavy IO mid-layer prints "DRIVER_TIMEOUT" errors
The driver now waits for 10 seconds to elapse instead of 5 (as in
previous release) to resume IO.
1 Release Date : Mon Feb. 05 11:35:24 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.08
3 Older Version : 00.00.03.07
i. Under heavy IO mid-layer prints "DRIVER_TIMEOUT" errors
Fix: The driver is now throttling IO.
Checks added in megasas_queue_command to know if FW is able to
process commands within timeout period. If number of retries
is 2 or greater,the driver stops sending cmd to FW temporarily. IO is
resumed if pending cmd count reduces to 16 or 5 seconds has elapsed
from the time cmds were last sent to FW.
ii. FW enables WCE bit in Mode Sense cmd for drives that are configured
as WriteBack. The OS may send "SYNCHRONIZE_CACHE" cmd when Logical
Disks are exposed with WCE=1. User is advised to enable Write Back
mode only when the controller has battery backup. At this time
Synhronize cache is not supported by the FW. Driver will short-cycle
the cmd and return success without sending down to FW.
1 Release Date : Sun Jan. 14 11:21:32 PDT 2007 -
Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang
2 Current Version : 00.00.03.07
3 Older Version : 00.00.03.06
i. bios_param entry added in scsi_host_template that returns disk geometry
information.
1 Release Date : Fri Oct 20 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang
2 Current Version : 00.00.03.06
3 Older Version : 00.00.03.05
1. Added new memory management module to support the IOCTL memory allocation. For IOCTL we try to allocate from the memory pool created during driver initialization. If mem pool is empty then we allocate at run time.
2. Added check in megasas_queue_command and dpc/isr routine to see if we have already declared adapter dead
(hw_crit_error=1). If hw_crit_error==1, now we donot accept any processing of pending cmds/accept any cmd from OS
1 Release Date : Mon Oct 02 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.05
3 Older Version : 00.00.03.04
i. PCI_DEVICE macro used
Convert the pci_device_id-table of the megaraid_sas-driver to the PCI_DEVICE-macro, to safe some lines.
- Henrik Kretzschmar <henne@nachtwindheim.de>
ii. All compiler warnings removed
iii. megasas_ctrl_info struct reverted to 3.02 release
iv. Default value of megasas_dbg_lvl set to 0
v. Removing in megasas_exit the sysfs entry created for megasas_dbg_lvl
vi. In megasas_teardown_frame_pool(), cmd->frame was passed instead of
cmd->sense to pci_pool_free. Fixed. Bug was pointed out by
Eric Sesterhenn
1 Release Date : Wed Sep 13 14:22:51 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.04
3 Older Version : 00.00.03.03
i. Added Reboot notify
ii. Reduced by 1 max cmds sent to FW from Driver to make the reply_q_sz same
as Max Cmds FW can support
1 Release Date : Tue Aug 22 16:33:14 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.03
3 Older Version : 00.00.03.02
i. Send stop adapter to FW & Dump pending FW cmds before declaring adapter dead.
New varible added to set dbg level.
ii. Disable interrupt made as fn pointer as they are different for 1068 / 1078
iii. Frame count optimization. Main frame can contain 2 SGE for 64 bit SGLs and
3 SGE for 32 bit SGL
iv. Tasklet added for cmd completion
v. If FW in operational state before firing INIT, now we send RESET Flag to FW instead of just READY. This is used to do soft reset.
vi. megasas_ctrl_prop structure updated (based on FW struct)
vii. Added print : FW now in Ready State during initialization
1 Release Date : Sun Aug 06 22:49:52 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.02
3 Older Version : 00.00.03.01
i. Added FW tranistion state for Hotplug scenario
1 Release Date : Sun May 14 22:49:52 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.01
3 Older Version : 00.00.02.04
i. Added support for ZCR controller.
New device id 0x413 added.
ii. Bug fix : Disable controller interrupt before firing INIT cmd to FW.
Interrupt is enabled after required initialization is over.
This is done to ensure that driver is ready to handle interrupts when
it is generated by the controller.
-Sumant Patro <Sumant.Patro@lsil.com>
1 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.02.04
3 Older Version : 00.00.02.04
i. Remove superflous instance_lock
gets rid of the otherwise superflous instance_lock and avoids an unsave
unsynchronized access in the error handler.
- Christoph Hellwig <hch@lst.de>
1 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.02.04
3 Older Version : 00.00.02.04
i. Support for 1078 type (ppc IOP) controller, device id : 0x60 added.
During initialization, depending on the device id, the template members
are initialized with function pointers specific to the ppc or
xscale controllers.
-Sumant Patro <Sumant.Patro@lsil.com>
1 Release Date : Fri Feb 03 14:16:25 PST 2006 - Sumant Patro
<Sumant.Patro@lsil.com>
2 Current Version : 00.00.02.04
3 Older Version : 00.00.02.02
i. Register 16 byte CDB capability with scsi midlayer
"This patch properly registers the 16 byte command length capability of the
megaraid_sas controlled hardware with the scsi midlayer. All megaraid_sas
hardware supports 16 byte CDB's."
-Joshua Giles <joshua_giles@dell.com>
1 Release Date : Mon Jan 23 14:09:01 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.02.02
3 Older Version : 00.00.02.01
i. New template defined to represent each family of controllers (identified by processor used).
The template will have defintions that will be initialised to appropritae values for a specific family of controllers. The template definition has four function pointers. During driver initialisation the function pointers will be set based on the controller family type. This change is done to support new controllers that has different processors and thus different register set.
-Sumant Patro <Sumant.Patro@lsil.com>
1 Release Date : Mon Dec 19 14:36:26 PST 2005 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.02.00-rc4
3 Older Version : 00.00.02.01
i. Code reorganized to remove code duplication in megasas_build_cmd.
"There's a lot of duplicate code megasas_build_cmd. Move that out of the different codepathes and merge the reminder of megasas_build_cmd into megasas_queue_command"
- Christoph Hellwig <hch@lst.de>
ii. Defined MEGASAS_IOC_FIRMWARE32 for code paths that handles 32 bit applications in 64 bit systems.
"MEGASAS_IOC_FIRMWARE can't be redefined if CONFIG_COMPAT is set, we need to define a MEGASAS_IOC_FIRMWARE32 define so native binaries continue to work"
- Christoph Hellwig <hch@lst.de>

495
Documentation/scsi/ChangeLog.ncr53c8xx Normal file
View file

@ -0,0 +1,495 @@
Sat May 12 12:00 2001 Gerard Roudier (groudier@club-internet.fr)
* version ncr53c8xx-3.4.3b
- Ensure LEDC bit in GPCNTL is cleared when reading the NVRAM.
Fix sent by Stig Telfer <stig@api-networks.com>.
- Define scsi_set_pci_device() as nil for kernel < 2.4.4.
Mon Feb 12 22:30 2001 Gerard Roudier (groudier@club-internet.fr)
* version ncr53c8xx-3.4.3
- Call pci_enable_device() as AC wants this to be done.
- Get both the BAR cookies actual and PCI BAR values.
(see Changelog.sym53c8xx rev. 1.7.3 for details)
- Merge changes for linux-2.4 that declare the host template
in the driver object also when the driver is statically
linked with the kernel.
Sun Sep 24 21:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version ncr53c8xx-3.4.2
- See Changelog.sym53c8xx, driver version 1.7.2.
Wed Jul 26 23:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version ncr53c8xx-3.4.1
- Provide OpenFirmware path through the proc FS on PPC.
- Remove trailing argument #2 from a couple of #undefs.
Sun Jul 09 16:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version ncr53c8xx-3.4.0
- Remove the PROFILE C and SCRIPTS code.
This facility was not this useful and thus was not longer
desirable given the increasing complexity of the driver code.
- Merges from FreeBSD sym-1.6.2 driver:
* Clarify memory barriers needed by the driver for architectures
that implement a weak memory ordering.
- General cleanup:
Move definitions for barriers and IO/MMIO operations to the
sym53c8xx_defs.h header files. They are now shared by the
both drivers.
Use SCSI_NCR_IOMAPPED instead of NCR_IOMAPPED.
Thu May 11 12:30 2000 Pam Delaney (pam.delaney@lsil.com)
* revision 3.3b
Mon Apr 24 12:00 2000 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2i
- Return value 1 (instead of 0) from the driver setup routine.
- Let the driver also attach controllers that have been set to
OFF in the NVRAM as it did prior to revision 3.2g.
Sat Apr 1 12:00 2000 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2h
- Fix a compilation problem on Alpha introduced in version 3.2g.
(`port' changed to `base_io').
- Move from `sym' to this driver a tiny change for __sparc__ that
applies to cache line size (? Probably from David S Miller).
- Make sure no data transfer will happen for Scsi_Cmnd requests
that supply SCSI_DATA_NONE direction (this avoids some BUG()
statement in the PCI code when a data buffer is also supplied).
Thu Mar 16 9:30 2000 Pam Delaney (pam.delaney@lsil.com)
* revision 3.3b-3
- Added exclusion for the 53C1010 and 53C1010_66 chips
to the driver (change to sym53c8xx_comm.h).
Mon March 6 23:15 2000 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2g
- Add the file sym53c8xx_comm.h that collects code that should
be shared by sym53c8xx and ncr53c8xx drivers. For now, it is
a header file that is only included by the ncr53c8xx driver,
but things will be cleaned up later. This code addresses
notably:
* Chip detection and PCI related initialisations
* NVRAM detection and reading
* DMA mapping
* Boot setup command
* And some other ...
- Add support for the new dynamic dma mapping kernel interface.
Requires Linux-2.3.47 (tested with pre-2.3.47-6).
- Get data transfer direction from the scsi command structure
(Scsi_Cmnd) when this information is available.
Mon March 6 23:15 2000 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2g
- Add the file sym53c8xx_comm.h that collects code that should
be shared by sym53c8xx and ncr53c8xx drivers. For now, it is
a header file that is only included by the ncr53c8xx driver,
but things will be cleaned up later. This code addresses
notably:
* Chip detection and PCI related initialisations
* NVRAM detection and reading
* DMA mapping
* Boot setup command
* And some other ...
- Add support for the new dynamic dma mapping kernel interface.
Requires Linux-2.3.47 (tested with pre-2.3.47-6).
- Get data transfer direction from the scsi command structure
(Scsi_Cmnd) when this information is available.
Fri Jan 14 14:00 2000 Pam Delaney (pam.delaney@lsil.com)
* revision pre-3.3b-1
- Merge parallel driver series 3.31 and 3.2e
Tue Jan 11 14:00 2000 Pam Delaney (pam.delaney@lsil.com)
* revision 3.31
- Added support for mounting disks on wide-narrow-wide
scsi configurations.
- Built off of version 3.30
Mon Jan 10 13:30 2000 Pam Delaney (pam.delaney@lsil.com)
* revision 3.30
- Added capability to use the integrity checking code
in the kernel (optional).
- Disabled support for the 53C1010.
- Built off of version 3.2c
Sat Jan 8 22:00 2000 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2e
- Add year 2000 copyright.
- Display correctly bus signals when bus is detected wrong.
- Remove the dead code that broke driver 3.2d.
Mon Dec 6 22:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2d
- Change messages written by the driver at initialisation and
through the /proc FS (rather cosmetic changes that consist in
printing out the PCI bus number and device/function).
- Get rid of the old PCI bios interface, but preserve kernel 2.0
compatibility from a simple wrapper.
- Remove the compilation condition about having to acquire the
io_request_lock since it seems to be a definite feature now.:)
- proc_dir structure no longer needed for kernel >= 2.3.27.
- Change the driver detection code by the sym53c8xx one, modulo
some minor changes. The driver can now attach any number of
controllers (>40) and does no longer hoger stack space at
initialisation.
- Definitely disable overlapped PCI arbitration for all dual
function chips, since I cannot make sure for what chip revisions
it is actually safe.
- Add support for the SYM53C1510D.
- Update the poor Tekram sync factor table.
- Remove the compilation condition about having to acquire the
io_request_lock since it seems to be a definite feature now.:)
- proc_dir structure no longer needed for kernel >= 2.3.27.
Sat Sep 11 18:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2c
- Handle correctly (hopefully) jiffies wrap-around.
- Restore the entry used to detect 875 until revision 0xff.
(I removed it inadvertently, it seems :) )
- Replace __initfunc() which is deprecated stuff by __init which
is not yet so. ;-)
- Add support of some 'resource handling' for linux-2.3.13.
Basically the BARs have been changed to something more complex
in the pci_dev structure.
- Remove some deprecated code.
Sat May 10 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision pre-3.2b-1
- Support for the 53C895A by Pamela Delaney <pam.delaney@lsil.com>
The 53C895A contains all of the features of the 896 but has only
one channel and has a 32 bit PCI bus. It does 64 bit PCI addressing
using dual cycle PCI data transfers.
- Miscellaneous minor fixes.
- Some additions to the README.ncr53c8xx file.
Sun Apr 11 10:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2a
- Add 'hostid:#id' boot option. This option allows to change the
default SCSI id the driver uses for controllers.
- Remove nvram layouts and driver set-up structures from the C source,
and use the one defined in sym53c8xx_defs.h file.
(shared by both drivers).
- Set for now MAX LUNS to 16 (instead of 8).
Thu Mar 11 23:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.2 (8xx-896 driver bundle)
- Only define the host template in ncr53c8xx.h and include the
sym53c8xx_defs.h file.
- Declare static all symbols that do not need to be visible from
outside the driver code.
- Add 'excl' boot command option that allows to pass to the driver
io address of devices not to attach.
- Add info() function called from the host template to print
driver/host information.
- Minor documentation additions.
Sat Mar 6 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1h
- Fix some oooold bug that hangs the bus if a device rejects a
negotiation. Btw, the corresponding stuff also needed some cleanup
and thus the change is a bit larger than it could have been.
- Still some typo that made compilation fail for 64 bit (trivial fix).
Sun Feb 14:00 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1g
- Deal correctly with 64 bit PCI address registers on Linux 2.2.
Pointed out by Leonard Zubkoff.
- Allow to tune request_irq() flags from the boot command line using
ncr53c8xx=irqm:??, as follows:
a) If bit 0x10 is set in irqm, IRQF_SHARED flag is not used.
b) If bit 0x20 is set in irqm, IRQF_DISABLED flag is not used.
By default the driver uses both IRQF_SHARED and IRQF_DISABLED.
Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by
a 53C8XX adapter and a network board.
- Tiny misspelling fixed (ABORT instead of ABRT). Was fortunately
harmless.
- Negotiate SYNC data transfers with CCS devices.
Sat Jan 16 17:30 1999 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1f
- Some PCI fix-ups not needed any more for PPC (from Cort).
- Cache line size set to 16 DWORDS for Sparc (from DSM).
- Waiting list look-up didn't work for the first command of the list.
- Remove 2 useless lines of code.
Sun Dec 13 18:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1e
- Same work-around as for the 53c876 rev <= 0x15 for 53c896 rev 1:
Disable overlapped arbitration. This will not make difference
since the chip has on-chip RAM.
Thu Nov 26 22:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1d
- The SISL RAID change requires now remap_pci_mem() stuff to be
compiled for __i386__ when normal IOs are used.
- Minor spelling fixes in doc files.
Sat Nov 21 18:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1c
- Ignore chips that are driven by SISL RAID (DAC 960).
Change sent by Leonard Zubkoff and slightly reworked.
- Still a buglet in the tags initial settings that needed to be fixed.
It was not possible to disable TGQ at system startup for devices
that claim TGQ support. The driver used at least 2 for the queue
depth but did'nt keep track of user settings for tags depth lower
than 2.
Wed Nov 11 10:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1b
- The driver was unhappy when configured with default_tags > MAX_TAGS
Hopefully doubly-fixed.
- Update the Configure.help driver section that speaks of TAGS.
Wed Oct 21 21:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.1a
- Changes from Eddie Dost for Sparc and Alpha:
ioremap/iounmap support for Sparc.
pcivtophys changed to bus_dvma_to_phys.
- Add the 53c876 description to the chip table. This is only useful
for printing the right name of the controller.
- DEL-441 Item 2 work-around for the 53c876 rev <= 5 (0x15).
- Add additional checking of INQUIRY data:
Check INQUIRY data received length is at least 7. Byte 7 of
inquiry data contains device features bits and the driver might
be confused by garbage. Also check peripheral qualifier.
- Cleanup of the SCSI tasks management:
Remove the special case for 32 tags. Now the driver only uses the
scheme that allows up to 64 tags per LUN.
Merge some code from the 896 driver.
Use a 1,3,5,...MAXTAGS*2+1 tag numbering. Previous driver could
use any tag number from 1 to 253 and some non conformant devices
might have problems with large tag numbers.
- 'no_sync' changed to 'no_disc' in the README file. This is an old
and trivial mistake that seems to demonstrate the README file is
not often read. :)
Sun Oct 4 14:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0i
- Cosmetic changes for sparc (but not for the driver) that needs
__irq_itoa() to be used for printed IRQ value to be understandable.
- Some problems with the driver that didn't occur using driver 2.5f
were due to a SCSI selection problem triggered by a clearly
documented feature that in fact seems not to work: (53C8XX chips
are claimed by the manuals to be able to execute SCSI scripts just
after abitration while the SCSI core is performing SCSI selection).
This optimization is broken and has been removed.
- Some broken scsi devices are confused when a negotiation is started
on a LUN that does not correspond to a real device. According to
SCSI specs, this is a device firmware bug. This has been worked
around by only starting negotiation if the LUN has previously be
used for at least 1 successful SCSI command.
- The 'last message sent' printed out on M_REJECT message reception
was read from the SFBR i/o register after the previous message had
been sent.
This was not correct and affects all previous driver versions and
the original FreeBSD one as well. The SCSI scripts has been fixed
so that it now provides the right information to the C code.
Sat Jul 18 13:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0g
- Preliminary fixes for Big Endian (sent by Eddie C. Dost).
Big Endian architectures should work again with the driver.
Eddie's patch has been partially applied since current 2.1.109
does not have all the Sparc changes of the vger tree.
- Use of BITS_PER_LONG instead of (~0UL == 0xffffffffUL) has fixed
the problem observed when the driver was compiled using EGCS or
PGCC.
Mon Jul 13 20:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0f
- Some spelling fixes.
- linux/config.h misplaced in ncr53c8xx.h
- MODULE_PARM stuff added for linux 2.1.
- check INQUIRY response data format is exactly 2.
- use BITS_PER_LONG if defined.
Sun Jun 28 12:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0e
- Some cleanup, spelling fixes, version checks, documentations
changes, etc ...
Sat Jun 20 20:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0c
- Add a boot setup option that allows to set up device queue depths
at boot-up. This option is very useful since Linux does not
allow to change scsi device queue depth once the system has been
booted up.
Sun Jun 15 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0a
- Support for up to 64 TAGS per LUN.
- Rewrite the TARGET vs LUN capabilities management.
CmdQueue is now handled as a LUN capability as it shall be.
This also fixes a bug triggered when disabling tagged command
queuing for a device that had this feature enabled.
- Remove the ncr_opennings() stuff that was useless under Linux
and hard to understand to me.
- Add "setverbose" procfs driver command. It allows to tune
verbose level after boot-up. Setting this level to zero, for
example avoid flooding the syslog file.
- Add KERN_XXX to some printk's.
Tue Jun 10 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 3.0
- Linux config changes for 2.0.34:
Remove NVRAM detection config option. This option is now enabled
by default but can be disabled by editing the driver header file.
Add a PROFILE config option.
- Update Configure.help
- Add calls to new function mdelay() for milli-seconds delay if
kernel version >= 2.1.105.
- Replace all printf(s) by printk(s). After all, the ncr53c8xx is
a driver for Linux.
- Perform auto-sense on COMMAND TERMINATED. Not sure it is useful.
- Some other minor changes.
Tue Jun 4 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6n
- Code cleanup and simplification:
Remove kernel 1.2.X and 1.3.X support.
Remove the _old_ target capabilities table.
Remove the error recovery code that have'nt been really useful.
Use a single alignment boundary (CACHE_LINE_SIZE) for data
structures.
- Several aggressive SCRIPTS optimizations and changes:
Reselect SCRIPTS code rewritten.
Support for selection/reselection without ATN.
And some others.
- Miscallaneous changes in the C code:
Count actual number of CCB queued to the controller (future use).
Lots of other minor changes.
Wed May 13 20:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6m
- Problem of missed SCSI bus reset with the 53C895 fixed by
Richard Waltham. The 53C895 needs about 650 us for the bus
mode to settle. Delays used while resetting the controller
and the bus have been adjusted. Thanks Richard!
- Some simplification for 64 bit arch done ccb address testing.
- Add a check of the MSG_OUT phase after Selection with ATN.
- The new tagged queue stuff seems ok, so some informationnal
message have been conditionned by verbose >= 3.
- Donnot reset if a SBMC interrupt reports the same bus mode.
- Print out the whole driver set-up. Some options were missing and
the print statement was misplaced for modules.
- Ignore a SCSI parity interrupt if the chip is not connected to
the SCSI bus.
Sat May 1 16:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6l
- Add CCB done queue support for Alpha and perhaps some other
architectures.
- Add some barriers to enforce memory ordering for x86 and
Alpha architectures.
- Fix something that looks like an old bug in the nego SIR
interrupt code in case of negotiation failure.
Sat Apr 25 21:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6k
- Remove all accesses to the on-chip RAM from the C code:
Use SCRIPTS to load the on-chip RAM.
Use SCRIPTS to repair the start queue on selection timeout.
Use the copy of script in main memory to calculate the chip
context on phase mismatch.
- The above allows now to use the on-chip RAM without requiring
to get access to the on-chip RAM from the C code. This makes
on-chip RAM useable for linux-1.2.13 and for Linux-Alpha for
instance.
- Some simplifications and cleanups in the SCRIPTS and C code.
- Buglet fixed in parity error recovery SCRIPTS (never tested).
- Minor updates in README.ncr53c8xx.
Wed Apr 15 21:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6j
- Incorporate changes from linux-2.1.95 ncr53c8xx driver version.
- Add SMP support for linux-2.1.95 and above.
- Fix a bug when QUEUE FULL is returned and no commands are
disconnected. This happens with Atlas I / L912 and may happen
with Atlas II / LXY4.
- Nail another one on CHECK condition when requeuing the command
for auto-sense.
- Call scsi_done() for all completed commands after interrupt
handling.
- Increase the done queue to 24 entries.
Sat Apr 4 20:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6i
- CTEST0 is used by the 53C885 for Power Management and
priority setting between the 2 functions.
Use SDID instead as actual target number. Just have had to
overwrite it with SSID on reselection.
- Split DATA_IN and DATA_OUT scripts into 2 sub-scripts.
64 segments are moved from on-chip RAM scripts.
If more segments, a script in main memory is used for the
additional segments.
- Since the SCRIPTS processor continues SCRIPTS execution after
having won arbitration, do some stuff prior to testing any SCSI
phase on reselection. This should have the vertue to process
scripts in parallel with the SCSI core performing selection.
- Increase the done queue to 12 entries.
Sun Mar 29 12:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6h
- Some fixes.
Tue Mar 26 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6g
- New done queue. 8 entries by default (6 always useable).
Can be increased if needed.
- Resources management using doubly linked queues.
- New auto-sense and QUEUE FULL handling that does not need to
stall the NCR queue any more.
- New CCB starvation avoiding algorithm.
- Prepare CCBs for SCSI commands that cannot be queued, instead of
inserting these commands into the waiting list. The waiting list
is now only used while resetting and when memory for CCBs is not
yet available?
Sun Feb 8 22:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6f
- Some fixes in order to really support the 53C895, at least with
FAST-20 devices.
- Heavy changes in the target/lun resources management to allow
the scripts to jump directly to the CCB on reselection instead
of walking on the lun CCBs list. Up to 32 tags per lun are now
supported without script processor and PCI traffic overhead.
Sun Jan 11 22:00 1998 Gerard Roudier (groudier@club-internet.fr)
* revision 2.6d
- new (different ?) implementation of the start queue:
Use a simple CALL to a launch script in the CCB.
- implement a minimal done queue (1 entry :-) ).
this avoid scanning all CCBs on INT FLY (Only scan all CCBs, on
overflow). Hit ratio is better than 99.9 % on my system, so no
need to have a larger done queue.
- generalization of the restart of CCB on special condition as
Abort, QUEUE FULL, CHECK CONDITION.
This has been called 'silly scheduler'.
- make all the profiling code conditionned by a config option.
This spare some PCI traffic and C code when this feature is not
needed.
- handle more cleanly the situation where direction is unknown.
The pointers patching is now performed by the SCRIPTS processor.
- remove some useless scripts instructions.
Ported from driver 2.5 series:
------------------------------
- Use FAST-5 instead of SLOW for slow scsi devices according to
new SPI-2 draft.
- Make some changes in order to accommodate with 875 rev <= 3
device errata listing 397. Minor consequences are:
. Leave use of PCI Write and Invalidate under user control.
Now, by default the driver does not enable PCI MWI and option
'specf:y' is required in order to enable this feature.
. Memory Read Line is not enabled for 875 and 875-like chips.
. Programmed burst length set to 64 DWORDS (instead of 128).
(Note: SYMBIOS uses 32 DWORDS for the SDMS BIOS)
- Add 'buschk' boot option.
This option enables checking of SCSI BUS data lines after SCSI
RESET (set by default). (Submitted by Richard Waltham).
- Update the README file.
- Dispatch CONDITION MET and RESERVATION CONFLICT scsi status
as OK driver status.
- Update the README file and the Symbios NVRAM format definition
with removable media flags values (available with SDMS 4.09).
- Several PCI configuration registers fix-ups for powerpc.
(Patch sent by Cort).

593
Documentation/scsi/ChangeLog.sym53c8xx Normal file
View file

@ -0,0 +1,593 @@
Sat May 12 12:00 2001 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.3c
- Ensure LEDC bit in GPCNTL is cleared when reading the NVRAM.
Fix sent by Stig Telfer <stig@api-networks.com>.
- Backport from SYM-2 the work-around that allows to support
hardwares that fail PCI parity checking.
- Check that we received at least 8 bytes of INQUIRY response
for byte 7, that contains device capabilities, to be valid.
- Define scsi_set_pci_device() as nil for kernel < 2.4.4.
- + A couple of minor changes.
Sat Apr 7 19:30 2001 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.3b
- Fix an unaligned LOAD from scripts (was used as dummy read).
- In ncr_soft_reset(), only try to ABORT the current operation
for chips that support SRUN bit in ISTAT1 and if SCRIPTS are
currently running, as 896 and 1010 manuals suggest.
- In the CCB abort path, do not assume that the CCB is currently
queued to SCRIPTS. This is not always true, notably after a
QUEUE FULL status or when using untagged commands.
Sun Mar 4 18:30 2001 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.3a
- Fix an issue in the ncr_int_udc() (unexpected disconnect)
handling. If the DSA didn't match a CCB, a bad write to
memory could happen.
Mon Feb 12 22:30 2001 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.3
- Support for hppa.
Tiny patch sent to me by Robert Hirst.
- Tiny patch for ia64 sent to me by Pamela Delaney.
Tue Feb 6 13:30 2001 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.3-pre1
- Call pci_enable_device() as AC wants this to be done.
- Get both the BAR cookies used by CPU and actual PCI BAR
values used from SCRIPTS. Recent PCI chips are able to
access themselves using internal cycles, but they compare
BAR values to destination address to make decision.
Earlier chips simply use PCI transactions to access IO
registers from SCRIPTS.
The bus_dvma_to_mem() interface that reverses the actual
PCI BAR value from the BAR cookie is now useless.
This point had been discussed at the list and the solution
got approved by PCI code maintainer (Martin Mares).
- Merge changes for linux-2.4 that declare the host template
in the driver object also when the driver is statically
linked with the kernel.
- Increase SCSI message size up to 12 bytes, given that 8
bytes was not enough for the PPR message (fix).
- Add field 'maxoffs_st' (max offset for ST data transfers).
The C1010 supports offset 62 in DT mode but only 31 in
ST mode, to 2 different values for the max SCSI offset
are needed. Replace the obviously wrong masking of the
offset against 0x1f for ST mode by a lowering to
maxoffs_st of the SCSI offset in ST mode.
- Refine a work-around for the C1010-66. Revision 1 does
not requires extra cycles in DT DATA OUT phase.
- Add a missing endian-ization (abrt_tbl.addr).
- Minor clean-up in the np structure for fields accessed
from SCRIPTS that requires special alignments.
Sun Sep 24 21:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.2
- Remove the hack for PPC added in previous driver version.
- Add FE_DAC feature bit to distinguish between 64 bit PCI
addressing (FE_DAC) and 64 bit PCI interface (FE_64BIT).
- Get rid of the boot command line "ultra:" argument.
This parameter wasn't that clever since we can use "sync:"
for Ultra/Ultra2 settings, and for Ultra3 we may want to
pass PPR options (for now only DT clocking).
- Add FE_VARCLK feature bit that indicates that SCSI clock
frequency may vary depending on board design and thus,
the driver should try to evaluate the SCSI clock.
- Simplify the way the driver determine the SCSI clock:
ULTRA3 -> 160 MHz, ULTRA2 -> 80 MHz otherwise 40 MHz.
Measure the SCSI clock frequency if FE_VARCLK is set.
- Remove FE_CLK80 feature bit that got useless.
- Add support for the SYM53C875A (Pamela Delaney).
Wed Jul 26 23:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.1
- Provide OpenFirmware path through the proc FS on PPC.
- Download of on-chip SRAM using memcpy_toio() doesn't work
on PPC. Restore previous method (MEMORY MOVE from SCRIPTS).
- Remove trailing argument #2 from a couple of #undefs.
Sun Jul 09 16:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.7.0
- Remove the PROFILE C and SCRIPTS code.
This facility was not this useful and thus was not longer
desirable given the increasing complexity of the driver code.
- Merges from FreeBSD sym-1.6.2 driver:
* Clarify memory barriers needed by the driver for architectures
that implement a weak memory ordering.
* Simpler handling of illegal phases and data overrun from
SCRIPTS. These errors are now immediately reported to
the C code by an interrupt.
* Sync the residual handling code with sym-1.6.2 and now
report `resid' to user for linux version >= 2.3.99
- General cleanup:
Move definitions for barriers and IO/MMIO operations to the
sym53c8xx_defs.h header files. They are now shared by the
both drivers.
Remove unused options that claimed to optimize for the 896.
If fact, they were not this clever. :)
Use SCSI_NCR_IOMAPPED instead of NCR_IOMAPPED.
Remove a couple of unused fields from data structures.
Thu May 11 12:40 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-1.6b
- Merged version.
Mon Apr 24 12:00 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5m
- Return value 1 (instead of 0) from the driver setup routine.
- Do not enable PCI DAC cycles. This just broke support for
SYM534C896 on sparc64. Problem fixed by David S. Miller.
Fri Apr 14 9:00 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-1.6b-9
- Added 53C1010_66 support.
- Small fix to integrity checking code.
- Removed requirement for integrity checking if want to run
at ultra 3.
Sat Apr 1 12:00 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5l
- Tiny change for __sparc__ appeared in 2.3.99-pre4.1 that
applies to cache line size (? Probably from David S Miller).
- Make sure no data transfer will happen for Scsi_Cmnd requests
that supply SCSI_DATA_NONE direction (this avoids some BUG()
statement in the PCI code when a data buffer is also supplied).
Sat Mar 11 12:00 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.6b-5
- Test against expected data transfer direction from SCRIPTS.
- Add support for the new dynamic dma mapping kernel interface.
Requires Linux-2.3.47 (tested with pre-2.3.47-6).
Many thanks to David S. Miller for his preliminary changes
that have been useful guidelines.
- Get data transfer direction from the scsi command structure
(Scsi_Cmnd) with kernels that provide this information.
Mon Mar 6 23:30 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5k
- Test against expected data transfer direction from SCRIPTS.
- Revert the change in 'ncr_flush_done_cmds()' but unmap the
scsi dma buffer prior to queueing the command to our done
list.
- Miscellaneous (minor) fixes in the code added in driver
version 1.5j.
Mon Feb 14 4:00 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-pre-1.6b-2.
- Updated the SCRIPTS error handling of the SWIDE
condition - to remove any reads of the sbdl
register. Changes needed because the 896 and 1010
chips will check parity in some special circumstances.
This will cause a parity error interrupt if not in
data phase. Changes based on those made in the
FreeBSD driver version 1.3.2.
Sun Feb 20 11:00 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5j
- Add support for the new dynamic dma mapping kernel interface.
Requires Linux-2.3.47 (tested with pre-2.3.47-6).
Many thanks to David S. Miller for his preliminary changes
that have been useful guidelines, for having reviewed the
code and having tested this driver version on Ultra-Sparc.
- 2 tiny bugs fixed in the PCI wrapper that provides support
for early kernels without pci device structure.
- Get data transfer direction from the scsi command structure
(Scsi_Cmnd) with kernels that provide this information.
- Fix an old bug that only affected 896 rev. 1 when driver
profile support option was set in kernel configuration.
Fri Jan 14 14:00 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-pre-1.6b-1.
- Merge parallel driver series 1.61 and 1.5e
Tue Jan 11 14:00 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-1.61
- Added support for mounting disks on wide-narrow-wide
scsi configurations.
- Modified offset to be a maximum of 31 in ST mode,
62 in DT mode.
- Based off of 1.60
Mon Jan 10 10:00 2000 Pam Delaney (pam.delaney@lsil.com)
* version sym53c8xx-1.60
- Added capability to use the integrity checking code
in the kernel (optional).
- Added PPR negotiation.
- Added support for 53C1010 Ultra 3 part.
- Based off of 1.5f
Sat Jan 8 22:00 2000 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5h
- Add year 2000 copyright.
- Display correctly bus signals when bus is detected wrong.
- Some fix for Sparc from DSM that went directly to kernel tree.
Mon Dec 6 22:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5g
- Change messages written by the driver at initialisation and
through the /proc FS (rather cosmetic changes that consist in
printing out the PCI bus number and PCI device/function).
- Ensure the SCRIPTS processor is stopped while calibrating the
SCSI clock (the initialisation code has been a bit reworked).
Change moved to the FreeBSD sym_hipd driver).
- Some fixes in the MODIFY_DP/IGN_RESIDUE code and residual
calculation (moved from FreeBSD sym_hipd driver).
- Add NVRAM support for Tekram boards that use 24C16 EEPROM.
Code moved from the FreeBSD sym_hipd driver, since it has
been that one that got this feature first.
- Definitely disable overlapped PCI arbitration for all dual
function chips, since I cannot make sure for what chip revisions
it is actually safe.
- Add support for the SYM53C1510D (also for ncr53c8xx).
- Fix up properly the PCI latency timer when needed or asked for.
- Get rid of the old PCI bios interface, but preserve kernel 2.0
compatibility from a simple wrapper.
- Update the poor Tekram sync factor table.
- Fix in a tiny 'printk' bug that may oops in case of extended
errors (unrecovered parity error, data overrun, etc ...)
(Sent by Pamela Delaney from LSILOGIC)
- Remove the compilation condition about having to acquire the
io_request_lock since it seems to be a definite feature now.:)
- Change get_pages by GetPages since Linux >= 2.3.27 now wants
get_pages to ever be used as a kernel symbol (from 2.3.27).
- proc_dir structure no longer needed for kernel >= 2.3.27.
Sun Oct 3 19:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5f
- Change the way the driver checks the PCI clock frequency, so
that overclocked PCI BUS up to 48 MHz will not be refused.
The more the BUS is overclocked, the less the driver will
guarantee that its measure of the SCSI clock is correct.
- Backport some minor improvements of SCRIPTS from the sym_hipd
driver.
- Backport the code rewrite of the START QUEUE dequeuing (on
bad scsi status received) from the sym_hipd driver.
Sat Sep 11 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5e
- New linux-2.3.13 __setup scheme support added.
- Cleanup of the extended error status handling:
Use 1 bit per error type.
- Also save the extended error status prior to auto-sense.
- Add the FE_DIFF chip feature bit to indicate support of
diff probing from GPIO3 (825/825A/876/875).
- Remove the quirk handling that has been useless since day one.
- Work-around PCI chips being reported twice on some platforms.
- Add some redundant PCI reads in order to deal with common
bridge misbehaviour regarding posted write flushing.
- Add some other conditionnal code for people who have to deal
with really broken bridges (they will have to edit a source
file to try these options).
- Handle correctly (hopefully) jiffies wrap-around.
- Restore the entry used to detect 875 until revision 0xff.
(I removed it inadvertently, it seems :) )
- Replace __initfunc() which is deprecated stuff by __init which
is not yet so. ;-)
- Rewrite the MESSAGE IN scripts more generic by using a MOVE
table indirect. Extended messages of any size are accepted now.
(Size is limited to 8 for now, but a constant is just to be
increased if necessary)
- Fix some bug in the fully untested MDP handling:) and share
some code between MDP handling and residual calculation.
- Calculate the data transfer residual as the 2's complement
integer (A positive value in returned on data overrun, and
a negative one on underrun).
- Add support of some 'resource handling' for linux-2.3.13.
Basically the BARs have been changed to something more complex
in the pci_dev structure.
- Remove some deprecated code.
Sat Jun 5 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5c
- Do not negotiate on auto-sense if we are currently using 8 bit
async transfer for the target.
- Only check for SISL/RAID on i386 platforms.
(A problem has been reported on PPC with that code).
- On MSG REJECT for a negotiation, the driver attempted to restart
the SCRIPT processor when this one was already running.
Sat May 29 12:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5b
- Force negotiation prior auto-sense.
This ensures that the driver will be able to grab the sense data
from a device that has received a BUS DEVICE RESET message from
another initiator.
- Complete all disconnected CCBs for a logical UNIT if we are told
about a UNIT ATTENTION for a RESET condition by this target.
- Add the control command 'cleardev' that allows to send a ABORT
message to a logical UNIT (for test purpose).
Tue May 25 23:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5a
- Add support for task abort and bus device reset SCSI message
and implement proper synchonisation with SCRIPTS to handle
correctly task abortion without races.
- Send an ABORT message (if untagged) or ABORT TAG message (if tagged)
when the driver is told to abort a command that is disconnected and
complete the command with appropriate error.
If the aborted command is not yet started, remove it from the start
queue and complete it with error.
- Add the control command 'resetdev' that allows to send a BUS
DEVICE RESET message to a target (for test purpose).
- Clean-up some unused or useless code.
Fri May 21 23:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.5
- Add support for CHMOV with Wide controllers.
- Handling of the SWIDE (low byte residue at the end of a CHMOV
in DATA IN phase with WIDE transfer when the byte count gets odd).
- Handling of the IGNORE WIDE RESIDUE message.
Handled from SCRIPTS as possible with some optimizations when both
a wide device and the controller are odd at the same time (SWIDE
present and IGNORE WIDE RESIDUE message on the BUS at the same time).
- Check against data OVERRUN/UNDERRUN condition at the end of a data
transfer, whatever a SWIDE is present (OVERRUN in DATA IN phase)
or the SODL is full (UNDERRUN in DATA out phase).
- Handling of the MODIFY DATA POINTER message.
This one cannot be handled from SCRIPTS, but hopefully it will not
happen very often. :)
- Large rewrite of the SCSI MESSAGE handling.
Sun May 9 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.4
- Support for IMMEDIATE ARBITRATION.
See the README file for detailed information about this feature.
Requires both a compile option and a boot option.
- Minor SCRIPTS optimization in reselection pattern for LUN 0.
- Simpler algorithm to deal with SCSI command starvation.
Just use 2 tag counters in flip/flop and switch to the other
one every 3 seconds.
- Do some work in SCRIPTS after the SELECT instruction and prior
to testing for a PHASE. SYMBIOS say this feature is working fine.
(Btw, only problems with Toshiba 3401B had been reported).
- Measure the PCI clock speed and do not attach controllers if
result is greater than 37 MHz. Since the precision of the
algorithm (from Stefan Esser) is better than 2%, this should
be fine.
- Fix the misdetection of SYM53C875E (was detected as a 876).
- Fix the misdetection of SYM53C810 not A (was detected as a 810A).
- Support for up to 256 TAGS per LUN (CMD_PER_LUN).
Currently limited to 255 due to Linux limitation. :)
- Support for up to 508 active commands (CAN_QUEUE).
- Support for the 53C895A by Pamela Delaney <pam.delaney@lsil.com>
The 53C895A contains all of the features of the 896 but has only
one channel and has a 32 bit PCI bus. It does 64 bit PCI addressing
using dual cycle PCI data transfers.
- Miscellaneous minor fixes.
- Some additions to the README.ncr53c8xx file.
Tue Apr 15 10:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.3e
- Support for any number of LUNs (64) (SPI2-compliant).
(Btw, this may only be ever useful under linux-2.2 ;-))
Sun Apr 11 10:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.3d
- Add 'hostid:#id' boot option. This option allows to change the
default SCSI id the driver uses for controllers.
- Make SCRIPTS not use self-mastering for PCI.
There were still 2 places the driver used this feature of the
53C8XX family.
- Move some data structures (nvram layouts and driver set-up) to
the sym53c8xx_defs.h file. So, the both drivers will share them.
- Set MAX LUNS to 16 (instead of 8).
Sat Mar 20 21:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.3b
- Add support for NCR PQS PDS.
James Bottomley <James.Bottomley@columbiasc.ncr.com>
- Allow value 0 for host ID.
- Support more than 8 controllers (> 40 in fact :-) )
- Add 'excl=#ioaddr' boot option: exclude controller.
(Version 1.3a driver)
Thu Mar 11 23:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.3 (8xx-896 driver bundle)
- Equivalent changes as ncr53c8xx-3.2 due to the driver bundle.
(See Changelog.ncr53c8xx)
- Do a normal soft reset as first chip reset, since aborting current
operation may raise an interrupt we are not able to handle since
the interrupt handler is not yet established.
Sat Mar 6 11:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.2b
- Fix some oooold bug that hangs the bus if a device rejects a
negotiation. Btw, the corresponding stuff also needed some cleanup
and thus the change is a bit larger than it could have been.
- Still some typo that made compilation fail for 64 bit (trivial fix).
Sun Feb 21 20:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.2a
- The rewrite of the interrupt handling broke the SBMC interrupt
handling due to a 1 bit mask tiny error. Hopefully fixed.
- If INQUIRY came from a scatter list, the driver looked into
the scatterlist instead of the data.:) Since this should never
happen, we just discard the data if use_sg is not zero.
Fri Feb 12 23:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.2
- Major rewrite of the interrupt handling and recovery stuff for
the support of non compliant SCSI removal, insertion and all
kinds of screw-up that may happen on the SCSI BUS.
Hopefully, the driver is now unbreakable or may-be, it is just
quite brocken. :-)
Many thanks to Johnson Russel (Symbios) for having responded to
my questions and for his interesting advices and comments about
support of SCSI hot-plug.
- Add 'recovery' option to driver set-up.
- Negotiate SYNC data transfers with CCS devices.
- Deal correctly with 64 bit PCI address registers on Linux 2.2.
Pointed out by Leonard Zubkoff.
Sun Jan 31 18:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.1a
- Some 896 chip revisions (all for now :-)), may hang-up if the
soft reset bit is set at the wrong time while SCRIPTS are running.
We need to first abort the current SCRIPTS operation prior to
resetting the chip. This fix has been sent to me by SYMBIOS/LSI
and I just translated it into ncr53c8xx syntax.
Must be considered 100 % trustable, unless I did some mistake
when translating it. :-)
Sun Jan 24 18:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.1
- Major rewrite of the SCSI parity error handling.
The informations contained in the data manuals are incomplete about
this feature.
I asked SYMBIOS about and got in reply the explanations that are
_indeed_ missing in the data manuals.
- Allow to tune request_irq() flags from the boot command line using
ncr53c8xx=irqm:??, as follows:
a) If bit 0x10 is set in irqm, SA_SHIRQ flag is not used.
b) If bit 0x20 is set in irqm, SA_INTERRUPT flag is not used.
By default the driver uses both SA_SHIRQ and SA_INTERRUPT.
Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by
a 53C8XX adapter and a network board.
- Fix for 64 bit PCI address register calculation. (Lance Robinson)
- Fix for big-endian in phase mismatch handling. (Michal Jaegermann)
Fri Jan 1 20:00 1999 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.0a
- Waiting list look-up didn't work for the first command of the list.
Hopefully fixed, but tested on paper only. ;)
- Remove the most part of PPC specific code for Linux-2.2.
Thanks to Cort.
- Some other minors changes.
Sat Dec 19 21:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version sym53c8xx-1.0
- Define some new IO registers for the 896 (istat1, mbox0, mbox1)
- Revamp slightly the Symbios NVRAM lay-out based on the excerpt of
the header file I received from Symbios.
- Check the PCI bus number for the boot order (Using a fast
PCI controller behing a PCI-PCI bridge seems sub-optimal).
- Disable overlapped PCI arbitration for the 896 revision 1.
- Reduce a bit the number of IO register reads for phase mismatch
by reading DWORDS at a time instead of BYTES.
Thu Dec 3 24:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.18
- I received this afternoon a 896 from SYMBIOS and started testing
the driver with this beast. After having fixed 3 buglets, it worked
with all features enabled including the phase mismatch handling
from SCRIPTS. Since this feature is not yet tested enough, the
boot option 'ncr53c8xx=specf:1' is still required to enable the
driver to handle PM from SCRIPTS.
Sun Nov 29 18:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.17
- The SISL RAID change requires now remap_pci_mem() stuff to be
compiled for __i386__ when normal IOs are used.
- The PCI memory read from SCRIPTS that should ensure ordering
was in fact misplaced. BTW, this may explain why broken PCI
device drivers regarding ordering are working so well. ;-)
- Rewrite ncr53c8xx_setup (boot command line options) since the
binary code was a bit too bloated in my opinion.
- Make the code simpler in the wakeup_done routine.
Tue Nov 24 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.16
- Add SCSI_NCR_OPTIMIZE_896_1 compile option and 'optim' boot option.
When set, the driver unconditionnaly assumes that the interrupt
handler is called for command completion, then clears INTF, scans
the done queue and returns if some completed CCB is found. If no
completed CCB are found, interrupt handling will proceed normally.
With a 896 that handles MA from SCRIPTS, this can be a great win,
since the driver will never performs PCI read transactions, but
only PCI write transactions that may be posted.
If the driver haven't to also raise the SIGP this would be perfect.
Even with this penalty, I think that this will work great.
Obviously this optimization makes sense only if the IRQ is not
shared with another device.
- Still a buglet in the tags initial settings that needed to be fixed.
It was not possible to disable TGQ at system startup for devices
that claim TGQ support. The driver used at least 2 for the queue
depth but did'nt keep track of user settings for tags depth lower
than 2.
Thu Nov 19 23:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.15
- Add support for hardware LED control of the 896.
- Ignore chips that are driven by SISL RAID (DAC 960).
Change sent by Leonard Zubkoff and slightly reworked.
- Prevent 810A rev 11 and 860 rev 1 from using cache line based
transactions since those early chip revisions may use such on
LOAD/STORE instructions (work-around).
- Remove some useless and bloat code from the pci init stuff.
- Do not use the readX()/writeX() kernel functions for __i386__,
since they perform useless masking operations in order to deal
with broken driver in 2.1.X kernel.
Wed Nov 11 10:00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.14
- The driver was unhappy when configured with default_tags > MAX_TAGS
Hopefully doubly-fixed.
- Set PCI_PARITY in PCI_COMMAND register in not set (PCI fix-up).
- Print out some message if phase mismatch is handled from SCRIPTS.
Sun Nov 1 14H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.13
- Some rewrite of the device detection code. This code had been
patched too much and needed to be face-lifted a bit.
Remove all platform dependent fix-ups that was not needed or
conflicted with some other driver code as work-arounds.
Reread the NVRAM before the calling of ncr_attach(). This spares
stack space and so allows to handle more boards.
Handle 64 bit base addresses under linux-2.0.X.
Set MASTER bit in PCI COMMAND register if not set.
Wed Oct 30 22H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.12
- Damned! I just broke the driver for Alpha by leaving a stale
instruction in the source code. Hopefully fixed.
- Do not set PFEN when it is useless. Doing so we are sure that BOF
will be active, since the manual appears to be very unclear on what
feature is actually used by the chip when both PFEN and BOF are
set.
Sat Oct 24 16H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.11
- LOAD/STORE instructions were miscompiled for register offsets
beyond 0x7f. This broke accesses to 896' new registers.
- Disable by default Phase Mismatch handling from SCRIPTS, since
current 896 rev.1 seems not to operate safely with the driver
when this feature is enabled (and above LOAD/STORE fix applied).
I will change the default to 'enabled' when this problem will be
solved.
Using boot option 'ncr53c8xx=specf:1' enables this feature.
- Implement a work-around (DEL 472 - ITEM 5) that should allow the
driver to safely enable hardware phase mismatch with 896 rev. 1.
Tue Oct 20 22H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.10
- Add the 53c876 description to the chip table. This is only useful
for printing the right name of the controller.
- Add additional checking of INQUIRY data:
Check INQUIRY data received length is at least 7. Byte 7 of
inquiry data contains device features bits and the driver might
be confused by garbage. Also check peripheral qualifier.
- Use a 1,3,5,...MAXTAGS*2+1 tag numbering. Previous driver could
use any tag number from 1 to 253 and some non conformant devices
might have problems with large tag numbers.
- Use NAME53C and NAME53C8XX for chip name prefix chip family name.
Just give a try using "sym53c" and "sym53c8xx" instead of "ncr53c"
and "ncr53c8xx". :-)
Sun Oct 11 17H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.9
- DEL-441 Item 2 work-around for the 53c876 rev <= 5 (0x15).
- Break ncr_scatter() into 2 functions in order to guarantee best
possible code optimization for the case we get a scatter list.
- Add the code intended to support up to 1 tera-byte for 64 bit systems.
It is probably too early, but I wanted to complete the thing.
Sat Oct 3 14H00 1998 Gerard Roudier (groudier@club-internet.fr)
* version pre-sym53c8xx-0.8
- Do some testing with io_mapped and fix what needed to be so.
- Wait for SCSI selection to complete or time-out immediately after
the chip won arbitration, since executing SCRIPTS while the SCSI
core is performing SCSI selection breaks the selection procedure
at least for some chip revisions.
- Interrupt the SCRIPTS if a device does not go to MSG OUT phase after
having been selected with ATN. Such a situation is not recoverable,
better to fail when we are stuck.

144
Documentation/scsi/ChangeLog.sym53c8xx_2 Normal file
View file

@ -0,0 +1,144 @@
Sat Dec 30 21:30 2000 Gerard Roudier
* version sym-2.1.0-20001230
- Initial release of SYM-2.
Mon Jan 08 21:30 2001 Gerard Roudier
* version sym-2.1.1-20010108
- Change a couple of defines containing ncr or NCR by their
equivalent containing sym or SYM instead.
Sun Jan 14 22:30 2001 Gerard Roudier
* version sym-2.1.2-20010114
- Fix a couple of printfs:
* Add the target number to the display of transfer parameters.
* Make the display of TCQ and queue depth clearer.
Wed Jan 17 23:30 2001 Gerard Roudier
* version sym-2.1.3-20010117
- Wrong residual values were returned in some situations.
This broke cdrecord with linux-2.4.0, for example.
Sat Jan 20 18:00 2001 Gerard Roudier
* version sym-2.1.4-20010120
- Add year 2001 to Copyright.
- A tiny bug in the dma memory freeing path has been fixed.
(Driver unload failed with a bad address reference).
Wed Jan 24 21:00 2001 Gerard Roudier
* version sym-2.1.5-20010124
- Make the driver work under Linux-2.4.x when statically linked
with the kernel.
- Check against memory allocation failure for SCRIPTZ and add the
missing free of this memory on instance detach.
- Check against GPIO3 pulled low for HVD controllers (driver did
just the opposite).
Misdetection of BUS mode was triggered on module reload only,
since BIOS settings were trusted instead on first load.
Wed Feb 7 21:00 2001 Gerard Roudier
* version sym-2.1.6-20010207
- Call pci_enable_device() as wished by kernel maintainers.
- Change the sym_queue_scsiio() interface.
This is intended to simplify portability.
- Move the code intended to deal with the dowloading of SCRIPTS
from SCRIPTS :) in the patch method (was wrongly placed in
the SCRIPTS setup method).
- Add a missing cpu_to_scr() (np->abort_tbl.addr)
- Remove a wrong cpu_to_scr() (np->targtbl_ba)
- Cleanup a bit the PPR failure recovery code.
Sat Mar 3 21:00 2001 Gerard Roudier
- Add option SYM_OPT_ANNOUNCE_TRANSFER_RATE and move the
corresponding code to file sym_misc.c.
Also move the code that sniffes INQUIRY to sym_misc.c.
This allows to share the corresponding code with NetBSD
without polluating the core driver source (sym_hipd.c).
- Add optionnal code that handles IO timeouts from the driver.
(not used under Linux, but required for NetBSD)
- Donnot assume any longer that PAGE_SHIFT and PAGE_SIZE are
defined at compile time, as at least NetBSD uses variables
in memory for that.
- Refine a work-around for the C1010-33 that consists in
disabling internal LOAD/STORE. Was applied up to revision 1.
Is now only applied to revision 0.
- Some code reorganisations due to code moves between files.
Tues Apr 10 21:00 2001 Gerard Roudier
* version sym-2.1.9-20010412
- Reset 53C896 and 53C1010 chip according to the manual.
(i.e.: set the ABRT bit in ISTAT if SCRIPTS are running)
- Set #LUN in request sense only if scsi version <= 2 and
#LUN <= 7.
- Set busy_itl in LCB to 1 if the LCB is allocated and a
SCSI command is active. This is a simplification.
- In sym_hcb_free(), do not scan the free_ccbq if no CCBs
has been allocated. This fixes a panic if attach failed.
- Add DT/ST (double/simple transition) in the transfer
negotiation announce.
- Forces the max number of tasks per LUN to at least 64.
- Use pci_set_dma_mask() for linux-2.4.3 and above.
- A couple of comments fixes.
Wed May 22:00 2001 Gerard Roudier
* version sym-2.1.10-20010509
- Mask GPCNTL against 0x1c (was 0xfc) for the reading of the NVRAM.
This ensure LEDC bit will not be set on 896 and later chips.
Fix sent by Chip Salzenberg <chip@perlsupport.com>.
- Define the number of PQS BUSes supported.
Fix sent by Stig Telfer <stig@api-networks.com>
- Miscellaneous common code rearrangements due to NetBSD accel
ioctl support, without impact on Linux (hopefully).
Mon July 2 12:00 2001 Gerard Roudier
* version sym-2.1.11-20010702
- Add Tekram 390 U2B/U2W SCSI LED handling.
Submitted by Chip Salzenberg <chip@valinux.com>
- Add call to scsi_set_pci_device() for kernels >= 2.4.4.
- Check pci dma mapping failures and complete the IO with some
error when such mapping fails.
- Fill in instance->max_cmd_len for kernels > 2.4.0.
- A couple of tiny fixes ...
Sun Sep 9 18:00 2001 Gerard Roudier
* version sym-2.1.12-20010909
- Change my email address.
- Add infrastructure for the forthcoming 64 bit DMA addressing support.
(Based on PCI 64 bit patch from David S. Miller)
- Donnot use anymore vm_offset_t type.
Sat Sep 15 20:00 2001 Gerard Roudier
* version sym-2.1.13-20010916
- Add support for 64 bit DMA addressing using segment registers.
16 registers for up to 4 GB x 16 -> 64 GB.
Sat Sep 22 12:00 2001 Gerard Roudier
* version sym-2.1.14-20010922
- Complete rewrite of the eh handling. The driver is now using a
semaphore in order to behave synchronously as required by the eh
threads. A timer is also used to prevent from waiting indefinitely.
Sun Sep 30 17:00 2001 Gerard Roudier
* version sym-2.1.15-20010930
- Include <linux/module.h> unconditionnaly as expected by latest
kernels.
- Use del_timer_sync() for recent kernels to kill the driver timer
on module release.
Sun Oct 28 15:00 2001 Gerard Roudier
* version sym-2.1.16-20011028
- Slightly simplify driver configuration.
- Prepare a new patch against linux-2.4.13.
Sat Nov 17 10:00 2001 Gerard Roudier
* version sym-2.1.17
- Fix a couple of gcc/gcc3 warnings.
- Allocate separately from the HCB the array for CCBs hashed by DSA.
All driver memory allocations are now not greater than 1 PAGE
even on PPC64 / 4KB PAGE surprising setup.
Sat Dec 01 18:00 2001 Gerard Roudier
* version sym-2.1.17a
- Use u_long instead of U32 for the IO base cookie. This is more
consistent with what archs are expecting.
- Use MMIO per default for Power PC instead of some fake normal IO,
as Paul Mackerras stated that MMIO works fine now on this arch.

163
Documentation/scsi/FlashPoint.txt Normal file
View file

@ -0,0 +1,163 @@
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://sourceforge.net/projects/dandelion/.
"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/.
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 its
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

60
Documentation/scsi/LICENSE.FlashPoint Normal file
View file

@ -0,0 +1,60 @@
FlashPoint Driver Developer's Kit
Version 1.0
Copyright 1995-1996 by Mylex Corporation
All Rights Reserved
This program is free software; you may redistribute and/or modify it under
the terms of either:
a) the GNU General Public License as published by the Free Software
Foundation; either version 2, or (at your option) any later version,
or
b) the "BSD-style License" included below.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY, without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See either the GNU General Public
License or the BSD-style License below for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
The BSD-style License is as follows:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain this LICENSE.FlashPoint
file, without modification, this list of conditions, and the following
disclaimer. The following copyright notice must appear immediately at
the beginning of all source files:
Copyright 1995-1996 by Mylex Corporation. All Rights Reserved
This file is available under both the GNU General Public License
and a BSD-style copyright; see LICENSE.FlashPoint for details.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name of Mylex Corporation may not be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY MYLEX CORP. ``AS IS'' 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 THE AUTHOR OR CONTRIBUTORS 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 INTERRUPTION) 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 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

290
Documentation/scsi/LICENSE.qla2xxx Normal file
View file

@ -0,0 +1,290 @@
Copyright (c) 2003-2014 QLogic Corporation
QLogic Linux FC-FCoE Driver
This program includes a device driver for Linux 3.x.
You may modify and redistribute the device driver code under the
GNU General Public License (a copy of which is attached hereto as
Exhibit A) published by the Free Software Foundation (version 2).
EXHIBIT A
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

289
Documentation/scsi/LICENSE.qla4xxx Normal file
View file

@ -0,0 +1,289 @@
Copyright (c) 2003-2013 QLogic Corporation
QLogic Linux iSCSI Driver
This program includes a device driver for Linux 3.x.
You may modify and redistribute the device driver code under the
GNU General Public License (a copy of which is attached hereto as
Exhibit A) published by the Free Software Foundation (version 2).
EXHIBIT A
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

5
Documentation/scsi/Mylex.txt Normal file
View file

@ -0,0 +1,5 @@
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://sourceforge.net/projects/dandelion for further information on the DAC960 driver.

128
Documentation/scsi/NinjaSCSI.txt Normal file
View file

@ -0,0 +1,128 @@
WorkBiT NinjaSCSI-3/32Bi driver for Linux
1. Comment
This is Workbit corp.'s(http://www.workbit.co.jp/) NinjaSCSI-3
for Linux.
2. My Linux environment
Linux kernel: 2.4.7 / 2.2.19
pcmcia-cs: 3.1.27
gcc: gcc-2.95.4
PC card: I-O data PCSC-F (NinjaSCSI-3)
I-O data CBSC-II in 16 bit mode (NinjaSCSI-32Bi)
SCSI device: I-O data CDPS-PX24 (CD-ROM drive)
Media Intelligent MMO-640GT (Optical disk drive)
3. Install
[1] Check your PC card is true "NinjaSCSI-3" card.
If you installed pcmcia-cs already, pcmcia reports your card as UNKNOWN
card, and write ["WBT", "NinjaSCSI-3", "R1.0"] or some other string to
your console or log file.
You can also use "cardctl" program (this program is in pcmcia-cs source
code) to get more info.
# cat /var/log/messages
...
Jan 2 03:45:06 lindberg cardmgr[78]: unsupported card in socket 1
Jan 2 03:45:06 lindberg cardmgr[78]: product info: "WBT", "NinjaSCSI-3", "R1.0"
...
# cardctl ident
Socket 0:
no product info available
Socket 1:
product info: "IO DATA", "CBSC16 ", "1"
[2] Get the Linux kernel source, and extract it to /usr/src.
Because the NinjaSCSI driver requires some SCSI header files in Linux
kernel source, I recommend rebuilding your kernel; this eliminates
some versioning problems.
$ cd /usr/src
$ tar -zxvf linux-x.x.x.tar.gz
$ cd linux
$ make config
...
[3] If you use this driver with Kernel 2.2, unpack pcmcia-cs in some directory
and make & install. This driver requires the pcmcia-cs header file.
$ cd /usr/src
$ tar zxvf cs-pcmcia-cs-3.x.x.tar.gz
...
[4] Extract this driver's archive somewhere, and edit Makefile, then do make.
$ tar -zxvf nsp_cs-x.x.tar.gz
$ cd nsp_cs-x.x
$ emacs Makefile
...
$ make
[5] Copy nsp_cs.ko to suitable place, like /lib/modules/<Kernel version>/pcmcia/ .
[6] Add these lines to /etc/pcmcia/config .
If you use pcmcia-cs-3.1.8 or later, we can use "nsp_cs.conf" file.
So, you don't need to edit file. Just copy to /etc/pcmcia/ .
-------------------------------------
device "nsp_cs"
class "scsi" module "nsp_cs"
card "WorkBit NinjaSCSI-3"
version "WBT", "NinjaSCSI-3", "R1.0"
bind "nsp_cs"
card "WorkBit NinjaSCSI-32Bi (16bit)"
version "WORKBIT", "UltraNinja-16", "1"
bind "nsp_cs"
# OEM
card "WorkBit NinjaSCSI-32Bi (16bit) / IO-DATA"
version "IO DATA", "CBSC16 ", "1"
bind "nsp_cs"
# OEM
card "WorkBit NinjaSCSI-32Bi (16bit) / KME-1"
version "KME ", "SCSI-CARD-001", "1"
bind "nsp_cs"
card "WorkBit NinjaSCSI-32Bi (16bit) / KME-2"
version "KME ", "SCSI-CARD-002", "1"
bind "nsp_cs"
card "WorkBit NinjaSCSI-32Bi (16bit) / KME-3"
version "KME ", "SCSI-CARD-003", "1"
bind "nsp_cs"
card "WorkBit NinjaSCSI-32Bi (16bit) / KME-4"
version "KME ", "SCSI-CARD-004", "1"
bind "nsp_cs"
-------------------------------------
[7] Start (or restart) pcmcia-cs.
# /etc/rc.d/rc.pcmcia start (BSD style)
or
# /etc/init.d/pcmcia start (SYSV style)
4. History
See README.nin_cs .
5. Caution
If you eject card when doing some operation for your SCSI device or suspend
your computer, you encount some *BAD* error like disk crash.
It works good when I using this driver right way. But I'm not guarantee
your data. Please backup your data when you use this driver.
6. Known Bugs
In 2.4 kernel, you can't use 640MB Optical disk. This error comes from
high level SCSI driver.
7. Testing
Please send me some reports(bug reports etc..) of this software.
When you send report, please tell me these or more.
card name
kernel version
your SCSI device name(hard drive, CD-ROM, etc...)
8. Copyright
See GPL.
2001/08/08 yokota@netlab.is.tsukuba.ac.jp <YOKOTA Hiroshi>

150
Documentation/scsi/aacraid.txt Normal file
View file

@ -0,0 +1,150 @@
AACRAID Driver for Linux (take two)
Introduction
-------------------------
The aacraid driver adds support for Adaptec (http://www.adaptec.com)
RAID controllers. This is a major rewrite from the original
Adaptec supplied driver. It has significantly cleaned up both the code
and the running binary size (the module is less than half the size of
the original).
Supported Cards/Chipsets
-------------------------
PCI ID (pci.ids) OEM Product
9005:0285:9005:0285 Adaptec 2200S (Vulcan)
9005:0285:9005:0286 Adaptec 2120S (Crusader)
9005:0285:9005:0287 Adaptec 2200S (Vulcan-2m)
9005:0285:9005:0288 Adaptec 3230S (Harrier)
9005:0285:9005:0289 Adaptec 3240S (Tornado)
9005:0285:9005:028a Adaptec 2020ZCR (Skyhawk)
9005:0285:9005:028b Adaptec 2025ZCR (Terminator)
9005:0286:9005:028c Adaptec 2230S (Lancer)
9005:0286:9005:028c Adaptec 2230SLP (Lancer)
9005:0286:9005:028d Adaptec 2130S (Lancer)
9005:0285:9005:028e Adaptec 2020SA (Skyhawk)
9005:0285:9005:028f Adaptec 2025SA (Terminator)
9005:0285:9005:0290 Adaptec 2410SA (Jaguar)
9005:0285:103c:3227 Adaptec 2610SA (Bearcat HP release)
9005:0285:9005:0293 Adaptec 21610SA (Corsair-16)
9005:0285:9005:0296 Adaptec 2240S (SabreExpress)
9005:0285:9005:0292 Adaptec 2810SA (Corsair-8)
9005:0285:9005:0297 Adaptec 4005 (AvonPark)
9005:0285:9005:0298 Adaptec 4000 (BlackBird)
9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X)
9005:0285:9005:029a Adaptec 4805SAS (Marauder-E)
9005:0286:9005:029b Adaptec 2820SA (Intruder)
9005:0286:9005:029c Adaptec 2620SA (Intruder)
9005:0286:9005:029d Adaptec 2420SA (Intruder HP release)
9005:0286:9005:02ac Adaptec 1800 (Typhoon44)
9005:0285:9005:02b5 Adaptec 5445 (Voodoo44)
9005:0285:15d9:02b5 SMC AOC-USAS-S4i
9005:0285:9005:02b6 Adaptec 5805 (Voodoo80)
9005:0285:15d9:02b6 SMC AOC-USAS-S8i
9005:0285:9005:02b7 Adaptec 5085 (Voodoo08)
9005:0285:9005:02bb Adaptec 3405 (Marauder40LP)
9005:0285:9005:02bc Adaptec 3805 (Marauder80LP)
9005:0285:9005:02c7 Adaptec 3085 (Marauder08ELP)
9005:0285:9005:02bd Adaptec 31205 (Marauder120)
9005:0285:9005:02be Adaptec 31605 (Marauder160)
9005:0285:9005:02c3 Adaptec 51205 (Voodoo120)
9005:0285:9005:02c4 Adaptec 51605 (Voodoo160)
9005:0285:15d9:02c9 SMC AOC-USAS-S4iR
9005:0285:15d9:02ca SMC AOC-USAS-S8iR
9005:0285:9005:02ce Adaptec 51245 (Voodoo124)
9005:0285:9005:02cf Adaptec 51645 (Voodoo164)
9005:0285:9005:02d0 Adaptec 52445 (Voodoo244)
9005:0285:9005:02d1 Adaptec 5405 (Voodoo40)
9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP
9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP
9005:0285:9005:02d4 Adaptec ASR-2045 (Voodoo04 Lite)
9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite)
9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite)
9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite)
9005:0285:9005:02d8 Adaptec 5405Z (Voodoo40 BLBU)
9005:0285:9005:02d9 Adaptec 5445Z (Voodoo44 BLBU)
9005:0285:9005:02da Adaptec 5805Z (Voodoo80 BLBU)
1011:0046:9005:0364 Adaptec 5400S (Mustang)
1011:0046:9005:0365 Adaptec 5400S (Mustang)
9005:0287:9005:0800 Adaptec Themisto (Jupiter)
9005:0200:9005:0200 Adaptec Themisto (Jupiter)
9005:0286:9005:0800 Adaptec Callisto (Jupiter)
1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang)
1011:0046:9005:1365 Dell PERC 2/QC (Quad Channel, Mustang)
1028:0001:1028:0001 Dell PERC 2/Si (Iguana)
1028:0003:1028:0003 Dell PERC 3/Si (SlimFast)
1028:0002:1028:0002 Dell PERC 3/Di (Opal)
1028:0004:1028:0004 Dell PERC 3/SiF (Iguana)
1028:0004:1028:00d0 Dell PERC 3/DiF (Iguana)
1028:0002:1028:00d1 Dell PERC 3/DiV (Viper)
1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus)
1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar)
1028:000a:1028:011b Dell PERC 3/DiD (Dagger)
1028:000a:1028:0121 Dell PERC 3/DiB (Boxster)
9005:0285:1028:0287 Dell PERC 320/DC (Vulcan)
9005:0285:1028:0291 Dell CERC 2 (DellCorsair)
1011:0046:103c:10c2 HP NetRAID-4M (Mustang)
9005:0285:17aa:0286 Legend S220 (Crusader)
9005:0285:17aa:0287 Legend S230 (Vulcan)
9005:0285:9005:0290 IBM ServeRAID 7t (Jaguar)
9005:0285:1014:02F2 IBM ServeRAID 8i (AvonPark)
9005:0286:1014:9540 IBM ServeRAID 8k/8k-l4 (AuroraLite)
9005:0286:1014:9580 IBM ServeRAID 8k/8k-l8 (Aurora)
9005:0285:1014:034d IBM ServeRAID 8s (Marauder-E)
9005:0286:9005:029e ICP ICP9024RO (Lancer)
9005:0286:9005:029f ICP ICP9014RO (Lancer)
9005:0286:9005:02a0 ICP ICP9047MA (Lancer)
9005:0286:9005:02a1 ICP ICP9087MA (Lancer)
9005:0285:9005:02a4 ICP ICP9085LI (Marauder-X)
9005:0285:9005:02a5 ICP ICP5085BR (Marauder-E)
9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6)
9005:0285:9005:02b2 ICP (Voodoo 8 internal 8 external)
9005:0285:9005:02b8 ICP ICP5445SL (Voodoo44)
9005:0285:9005:02b9 ICP ICP5085SL (Voodoo80)
9005:0285:9005:02ba ICP ICP5805SL (Voodoo08)
9005:0285:9005:02bf ICP ICP5045BL (Marauder40LP)
9005:0285:9005:02c0 ICP ICP5085BL (Marauder80LP)
9005:0285:9005:02c8 ICP ICP5805BL (Marauder08ELP)
9005:0285:9005:02c1 ICP ICP5125BR (Marauder120)
9005:0285:9005:02c2 ICP ICP5165BR (Marauder160)
9005:0285:9005:02c5 ICP ICP5125SL (Voodoo120)
9005:0285:9005:02c6 ICP ICP5165SL (Voodoo160)
9005:0286:9005:02ab (Typhoon40)
9005:0286:9005:02ad (Aurora ARK)
9005:0286:9005:02ae (Aurora Lite ARK)
9005:0285:9005:02b0 (Sunrise Lake ARK)
9005:0285:9005:02b1 Adaptec (Voodoo 8 internal 8 external)
9005:0285:108e:7aac SUN STK RAID REM (Voodoo44 Coyote)
9005:0285:108e:0286 SUN STK RAID INT (Cougar)
9005:0285:108e:0287 SUN STK RAID EXT (Prometheus)
9005:0285:108e:7aae SUN STK RAID EM (Narvi)
People
-------------------------
Alan Cox <alan@lxorguk.ukuu.org.uk>
Christoph Hellwig <hch@infradead.org> (updates for new-style PCI probing and SCSI host registration,
small cleanups/fixes)
Matt Domsch <matt_domsch@dell.com> (revision ioctl, adapter messages)
Deanna Bonds (non-DASD support, PAE fibs and 64 bit, added new adaptec controllers
added new ioctls, changed scsi interface to use new error handler,
increased the number of fibs and outstanding commands to a container)
(fixed 64bit and 64G memory model, changed confusing naming convention
where fibs that go to the hardware are consistently called hw_fibs and
not just fibs like the name of the driver tracking structure)
Mark Salyzyn <Mark_Salyzyn@adaptec.com> Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations.
Achim Leubner <Achim_Leubner@adaptec.com>
Original Driver
-------------------------
Adaptec Unix OEM Product Group
Mailing List
-------------------------
linux-scsi@vger.kernel.org (Interested parties troll here)
Also note this is very different to Brian's original driver
so don't expect him to support it.
Adaptec does support this driver. Contact Adaptec tech support or
aacraid@adaptec.com
Original by Brian Boerner February 2001
Rewritten by Alan Cox, November 2001

243
Documentation/scsi/advansys.txt Normal file
View file

@ -0,0 +1,243 @@
AdvanSys (Advanced System Products, Inc.) manufactures the following
RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow
(8-bit transfer) SCSI Host Adapters for the ISA, EISA, VL, and PCI
buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit
transfer) SCSI Host Adapters for the PCI bus.
The CDB counts below indicate the number of SCSI CDB (Command
Descriptor Block) requests that can be stored in the RISC chip
cache and board LRAM. A CDB is a single SCSI command. The driver
detect routine will display the number of CDBs available for each
adapter detected. The number of CDBs used by the driver can be
lowered in the BIOS by changing the 'Host Queue Size' adapter setting.
Laptop Products:
ABP-480 - Bus-Master CardBus (16 CDB)
Connectivity Products:
ABP510/5150 - Bus-Master ISA (240 CDB)
ABP5140 - Bus-Master ISA PnP (16 CDB)
ABP5142 - Bus-Master ISA PnP with floppy (16 CDB)
ABP902/3902 - Bus-Master PCI (16 CDB)
ABP3905 - Bus-Master PCI (16 CDB)
ABP915 - Bus-Master PCI (16 CDB)
ABP920 - Bus-Master PCI (16 CDB)
ABP3922 - Bus-Master PCI (16 CDB)
ABP3925 - Bus-Master PCI (16 CDB)
ABP930 - Bus-Master PCI (16 CDB)
ABP930U - Bus-Master PCI Ultra (16 CDB)
ABP930UA - Bus-Master PCI Ultra (16 CDB)
ABP960 - Bus-Master PCI MAC/PC (16 CDB)
ABP960U - Bus-Master PCI MAC/PC Ultra (16 CDB)
Single Channel Products:
ABP542 - Bus-Master ISA with floppy (240 CDB)
ABP742 - Bus-Master EISA (240 CDB)
ABP842 - Bus-Master VL (240 CDB)
ABP940 - Bus-Master PCI (240 CDB)
ABP940U - Bus-Master PCI Ultra (240 CDB)
ABP940UA/3940UA - Bus-Master PCI Ultra (240 CDB)
ABP970 - Bus-Master PCI MAC/PC (240 CDB)
ABP970U - Bus-Master PCI MAC/PC Ultra (240 CDB)
ABP3960UA - Bus-Master PCI MAC/PC Ultra (240 CDB)
ABP940UW/3940UW - Bus-Master PCI Ultra-Wide (253 CDB)
ABP970UW - Bus-Master PCI MAC/PC Ultra-Wide (253 CDB)
ABP3940U2W - Bus-Master PCI LVD/Ultra2-Wide (253 CDB)
Multi-Channel Products:
ABP752 - Dual Channel Bus-Master EISA (240 CDB Per Channel)
ABP852 - Dual Channel Bus-Master VL (240 CDB Per Channel)
ABP950 - Dual Channel Bus-Master PCI (240 CDB Per Channel)
ABP950UW - Dual Channel Bus-Master PCI Ultra-Wide (253 CDB Per Channel)
ABP980 - Four Channel Bus-Master PCI (240 CDB Per Channel)
ABP980U - Four Channel Bus-Master PCI Ultra (240 CDB Per Channel)
ABP980UA/3980UA - Four Channel Bus-Master PCI Ultra (16 CDB Per Chan.)
ABP3950U2W - Bus-Master PCI LVD/Ultra2-Wide and Ultra-Wide (253 CDB)
ABP3950U3W - Bus-Master PCI Dual LVD2/Ultra3-Wide (253 CDB)
Driver Compile Time Options and Debugging
The following constants can be defined in the source file.
1. ADVANSYS_ASSERT - Enable driver assertions (Def: Enabled)
Enabling this option adds assertion logic statements to the
driver. If an assertion fails a message will be displayed to
the console, but the system will continue to operate. Any
assertions encountered should be reported to the person
responsible for the driver. Assertion statements may proactively
detect problems with the driver and facilitate fixing these
problems. Enabling assertions will add a small overhead to the
execution of the driver.
2. ADVANSYS_DEBUG - Enable driver debugging (Def: Disabled)
Enabling this option adds tracing functions to the driver and the
ability to set a driver tracing level at boot time. This option is
very useful for debugging the driver, but it will add to the size
of the driver execution image and add overhead to the execution of
the driver.
The amount of debugging output can be controlled with the global
variable 'asc_dbglvl'. The higher the number the more output. By
default the debug level is 0.
If the driver is loaded at boot time and the LILO Driver Option
is included in the system, the debug level can be changed by
specifying a 5th (ASC_NUM_IOPORT_PROBE + 1) I/O Port. The
first three hex digits of the pseudo I/O Port must be set to
'deb' and the fourth hex digit specifies the debug level: 0 - F.
The following command line will look for an adapter at 0x330
and set the debug level to 2.
linux advansys=0x330,0,0,0,0xdeb2
If the driver is built as a loadable module this variable can be
defined when the driver is loaded. The following insmod command
will set the debug level to one.
insmod advansys.o asc_dbglvl=1
Debugging Message Levels:
0: Errors Only
1: High-Level Tracing
2-N: Verbose Tracing
To enable debug output to console, please make sure that:
a. System and kernel logging is enabled (syslogd, klogd running).
b. Kernel messages are routed to console output. Check
/etc/syslog.conf for an entry similar to this:
kern.* /dev/console
c. klogd is started with the appropriate -c parameter
(e.g. klogd -c 8)
This will cause printk() messages to be be displayed on the
current console. Refer to the klogd(8) and syslogd(8) man pages
for details.
Alternatively you can enable printk() to console with this
program. However, this is not the 'official' way to do this.
Debug output is logged in /var/log/messages.
main()
{
syscall(103, 7, 0, 0);
}
Increasing LOG_BUF_LEN in kernel/printk.c to something like
40960 allows more debug messages to be buffered in the kernel
and written to the console or log file.
3. ADVANSYS_STATS - Enable statistics (Def: Enabled)
Enabling this option adds statistics collection and display
through /proc to the driver. The information is useful for
monitoring driver and device performance. It will add to the
size of the driver execution image and add minor overhead to
the execution of the driver.
Statistics are maintained on a per adapter basis. Driver entry
point call counts and transfer size counts are maintained.
Statistics are only available for kernels greater than or equal
to v1.3.0 with the CONFIG_PROC_FS (/proc) file system configured.
AdvanSys SCSI adapter files have the following path name format:
/proc/scsi/advansys/{0,1,2,3,...}
This information can be displayed with cat. For example:
cat /proc/scsi/advansys/0
When ADVANSYS_STATS is not defined the AdvanSys /proc files only
contain adapter and device configuration information.
Driver LILO Option
If init/main.c is modified as described in the 'Directions for Adding
the AdvanSys Driver to Linux' section (B.4.) above, the driver will
recognize the 'advansys' LILO command line and /etc/lilo.conf option.
This option can be used to either disable I/O port scanning or to limit
scanning to 1 - 4 I/O ports. Regardless of the option setting EISA and
PCI boards will still be searched for and detected. This option only
affects searching for ISA and VL boards.
Examples:
1. Eliminate I/O port scanning:
boot: linux advansys=
or
boot: linux advansys=0x0
2. Limit I/O port scanning to one I/O port:
boot: linux advansys=0x110
3. Limit I/O port scanning to four I/O ports:
boot: linux advansys=0x110,0x210,0x230,0x330
For a loadable module the same effect can be achieved by setting
the 'asc_iopflag' variable and 'asc_ioport' array when loading
the driver, e.g.
insmod advansys.o asc_iopflag=1 asc_ioport=0x110,0x330
If ADVANSYS_DEBUG is defined a 5th (ASC_NUM_IOPORT_PROBE + 1)
I/O Port may be added to specify the driver debug level. Refer to
the 'Driver Compile Time Options and Debugging' section above for
more information.
Credits (Chronological Order)
Bob Frey <bfrey@turbolinux.com.cn> wrote the AdvanSys SCSI driver
and maintained it up to 3.3F. He continues to answer questions
and help maintain the driver.
Nathan Hartwell <mage@cdc3.cdc.net> provided the directions and
basis for the Linux v1.3.X changes which were included in the
1.2 release.
Thomas E Zerucha <zerucha@shell.portal.com> pointed out a bug
in advansys_biosparam() which was fixed in the 1.3 release.
Erik Ratcliffe <erik@caldera.com> has done testing of the
AdvanSys driver in the Caldera releases.
Rik van Riel <H.H.vanRiel@fys.ruu.nl> provided a patch to
AscWaitTixISRDone() which he found necessary to make the
driver work with a SCSI-1 disk.
Mark Moran <mmoran@mmoran.com> has helped test Ultra-Wide
support in the 3.1A driver.
Doug Gilbert <dgilbert@interlog.com> has made changes and
suggestions to improve the driver and done a lot of testing.
Ken Mort <ken@mort.net> reported a DEBUG compile bug fixed
in 3.2K.
Tom Rini <trini@kernel.crashing.org> provided the CONFIG_ISA
patch and helped with PowerPC wide and narrow board support.
Philip Blundell <philb@gnu.org> provided an
advansys_interrupts_enabled patch.
Dave Jones <dave@denial.force9.co.uk> reported the compiler
warnings generated when CONFIG_PROC_FS was not defined in
the 3.2M driver.
Jerry Quinn <jlquinn@us.ibm.com> fixed PowerPC support (endian
problems) for wide cards.
Bryan Henderson <bryanh@giraffe-data.com> helped debug narrow
card error handling.
Manuel Veloso <veloso@pobox.com> worked hard on PowerPC narrow
board support and fixed a bug in AscGetEEPConfig().
Arnaldo Carvalho de Melo <acme@conectiva.com.br> made
save_flags/restore_flags changes.
Andy Kellner <AKellner@connectcom.net> continued the Advansys SCSI
driver development for ConnectCom (Version > 3.3F).
Ken Witherow for extensive testing during the development of version 3.4.

183
Documentation/scsi/aha152x.txt Normal file
View file

@ -0,0 +1,183 @@
$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 up to 255 heads, up to 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.

497
Documentation/scsi/aic79xx.txt Normal file
View file

@ -0,0 +1,497 @@
====================================================================
= Adaptec Ultra320 Family Manager Set =
= =
= README for =
= The Linux Operating System =
====================================================================
The following information is available in this file:
1. Supported Hardware
2. Version History
3. Command Line Options
4. Additional Notes
5. Contacting Adaptec
1. Supported Hardware
The following Adaptec SCSI Host Adapters are supported by this
driver set.
Ultra320 ASIC Description
----------------------------------------------------------------
AIC-7901A Single Channel 64-bit PCI-X 133MHz to
Ultra320 SCSI ASIC
AIC-7901B Single Channel 64-bit PCI-X 133MHz to
Ultra320 SCSI ASIC with Retained Training
AIC-7902A4 Dual Channel 64-bit PCI-X 133MHz to
Ultra320 SCSI ASIC
AIC-7902B Dual Channel 64-bit PCI-X 133MHz to
Ultra320 SCSI ASIC with Retained Training
Ultra320 Adapters Description ASIC
--------------------------------------------------------------------------
Adaptec SCSI Card 39320 Dual Channel 64-bit PCI-X 133MHz to 7902A4/7902B
Ultra320 SCSI Card (one external
68-pin, two internal 68-pin)
Adaptec SCSI Card 39320A Dual Channel 64-bit PCI-X 133MHz to 7902B
Ultra320 SCSI Card (one external
68-pin, two internal 68-pin)
Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4
Ultra320 SCSI Card (two external VHDC
and one internal 68-pin)
Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4
Ultra320 SCSI Card (two external VHDC
and one internal 68-pin) based on the
AIC-7902B ASIC
Adaptec SCSI Card 29320 Single Channel 64-bit PCI-X 133MHz to 7901A
Ultra320 SCSI Card (one external
68-pin, two internal 68-pin, one
internal 50-pin)
Adaptec SCSI Card 29320A Single Channel 64-bit PCI-X 133MHz to 7901B
Ultra320 SCSI Card (one external
68-pin, two internal 68-pin, one
internal 50-pin)
Adaptec SCSI Card 29320LP Single Channel 64-bit Low Profile 7901A
PCI-X 133MHz to Ultra320 SCSI Card
(One external VHDC, one internal
68-pin)
Adaptec SCSI Card 29320ALP Single Channel 64-bit Low Profile 7901B
PCI-X 133MHz to Ultra320 SCSI Card
(One external VHDC, one internal
68-pin)
2. Version History
3.0 (December 1st, 2005)
- Updated driver to use SCSI transport class infrastructure
- Upported sequencer and core fixes from adaptec released
version 2.0.15 of the driver.
1.3.11 (July 11, 2003)
- Fix several deadlock issues.
- Add 29320ALP and 39320B Id's.
1.3.10 (June 3rd, 2003)
- Align the SCB_TAG field on a 16byte boundary. This avoids
SCB corruption on some PCI-33 busses.
- Correct non-zero luns on Rev B. hardware.
- Update for change in 2.5.X SCSI proc FS interface.
- When negotiation async via an 8bit WDTR message, send
an SDTR with an offset of 0 to be sure the target
knows we are async. This works around a firmware defect
in the Quantum Atlas 10K.
- Implement controller suspend and resume.
- Clear PCI error state during driver attach so that we
don't disable memory mapped I/O due to a stray write
by some other driver probe that occurred before we
claimed the controller.
1.3.9 (May 22nd, 2003)
- Fix compiler errors.
- Remove S/G splitting for segments that cross a 4GB boundary.
This is guaranteed not to happen in Linux.
- Add support for scsi_report_device_reset() found in
2.5.X kernels.
- Add 7901B support.
- Simplify handling of the packetized lun Rev A workaround.
- Correct and simplify handling of the ignore wide residue
message. The previous code would fail to report a residual
if the transaction data length was even and we received
an IWR message.
1.3.8 (April 29th, 2003)
- Fix types accessed via the command line interface code.
- Perform a few firmware optimizations.
- Fix "Unexpected PKT busfree" errors.
- Use a sequencer interrupt to notify the host of
commands with bad status. We defer the notification
until there are no outstanding selections to ensure
that the host is interrupted for as short a time as
possible.
- Remove pre-2.2.X support.
- Add support for new 2.5.X interrupt API.
- Correct big-endian architecture support.
1.3.7 (April 16th, 2003)
- Use del_timer_sync() to ensure that no timeouts
are pending during controller shutdown.
- For pre-2.5.X kernels, carefully adjust our segment
list size to avoid SCSI malloc pool fragmentation.
- Cleanup channel display in our /proc output.
- Workaround duplicate device entries in the mid-layer
device list during add-single-device.
1.3.6 (March 28th, 2003)
- Correct a double free in the Domain Validation code.
- Correct a reference to free'ed memory during controller
shutdown.
- Reset the bus on an SE->LVD change. This is required
to reset our transceivers.
1.3.5 (March 24th, 2003)
- Fix a few register window mode bugs.
- Include read streaming in the PPR flags we display in
diagnostics as well as /proc.
- Add PCI hot plug support for 2.5.X kernels.
- Correct default precompensation value for RevA hardware.
- Fix Domain Validation thread shutdown.
- Add a firmware workaround to make the LED blink
brighter during packetized operations on the H2A4.
- Correct /proc display of user read streaming settings.
- Simplify driver locking by releasing the io_request_lock
upon driver entry from the mid-layer.
- Cleanup command line parsing and move much of this code
to aiclib.
1.3.4 (February 28th, 2003)
- Correct a race condition in our error recovery handler.
- Allow Test Unit Ready commands to take a full 5 seconds
during Domain Validation.
1.3.2 (February 19th, 2003)
- Correct a Rev B. regression due to the GEM318
compatibility fix included in 1.3.1.
1.3.1 (February 11th, 2003)
- Add support for the 39320A.
- Improve recovery for certain PCI-X errors.
- Fix handling of LQ/DATA/LQ/DATA for the
same write transaction that can occur without
interveining training.
- Correct compatibility issues with the GEM318
enclosure services device.
- Correct data corruption issue that occurred under
high tag depth write loads.
- Adapt to a change in the 2.5.X daemonize() API.
- Correct a "Missing case in ahd_handle_scsiint" panic.
1.3.0 (January 21st, 2003)
- Full regression testing for all U320 products completed.
- Added abort and target/lun reset error recovery handler and
interrupt coalescing.
1.2.0 (November 14th, 2002)
- Added support for Domain Validation
- Add support for the Hewlett-Packard version of the 39320D
and AIC-7902 adapters.
Support for previous adapters has not been fully tested and should
only be used at the customer's own risk.
1.1.1 (September 24th, 2002)
- Added support for the Linux 2.5.X kernel series
1.1.0 (September 17th, 2002)
- Added support for four additional SCSI products:
ASC-39320, ASC-29320, ASC-29320LP, AIC-7901.
1.0.0 (May 30th, 2002)
- Initial driver release.
2.1. Software/Hardware Features
- Support for the SPI-4 "Ultra320" standard:
- 320MB/s transfer rates
- Packetized SCSI Protocol at 160MB/s and 320MB/s
- Quick Arbitration Selection (QAS)
- Retained Training Information (Rev B. ASIC only)
- Interrupt Coalescing
- Initiator Mode (target mode not currently
supported)
- Support for the PCI-X standard up to 133MHz
- Support for the PCI v2.2 standard
- Domain Validation
2.2. Operating System Support:
- Redhat Linux 7.2, 7.3, 8.0, Advanced Server 2.1
- SuSE Linux 7.3, 8.0, 8.1, Enterprise Server 7
- only Intel and AMD x86 supported at this time
- >4GB memory configurations supported.
Refer to the User's Guide for more details on this.
3. Command Line Options
WARNING: ALTERING OR ADDING THESE DRIVER PARAMETERS
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
USE THEM WITH CAUTION.
Put a .conf file in the /etc/modprobe.d/ directory and add/edit a
line containing 'options aic79xx aic79xx=[command[,command...]]' where
'command' is one or more of the following:
-----------------------------------------------------------------
Option: verbose
Definition: enable additional informative messages during
driver operation.
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: debug:[value]
Definition: Enables various levels of debugging information
The bit definitions for the debugging mask can
be found in drivers/scsi/aic7xxx/aic79xx.h under
the "Debug" heading.
Possible Values: 0x0000 = no debugging, 0xffff = full debugging
Default Value: 0x0000
-----------------------------------------------------------------
Option: no_reset
Definition: Do not reset the bus during the initial probe
phase
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: extended
Definition: Force extended translation on the controller
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: periodic_otag
Definition: Send an ordered tag periodically to prevent
tag starvation. Needed for some older devices
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: reverse_scan
Definition: Probe the scsi bus in reverse order, starting
with target 15
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: global_tag_depth
Definition: Global tag depth for all targets on all busses.
This option sets the default tag depth which
may be selectively overridden vi the tag_info
option.
Possible Values: 1 - 253
Default Value: 32
-----------------------------------------------------------------
Option: tag_info:{{value[,value...]}[,{value[,value...]}...]}
Definition: Set the per-target tagged queue depth on a
per controller basis. Both controllers and targets
may be omitted indicating that they should retain
the default tag depth.
Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32}
On Controller 0
specifies a tag depth of 16 for target 0
specifies a tag depth of 64 for target 3
specifies a tag depth of 8 for targets 4 and 5
leaves target 6 at the default
specifies a tag depth of 32 for targets 1,2,7-15
All other targets retain the default depth.
tag_info:{{},{32,,32}}
On Controller 1
specifies a tag depth of 32 for targets 0 and 2
All other targets retain the default depth.
Possible Values: 1 - 253
Default Value: 32
-----------------------------------------------------------------
Option: rd_strm: {rd_strm_bitmask[,rd_strm_bitmask...]}
Definition: Enable read streaming on a per target basis.
The rd_strm_bitmask is a 16 bit hex value in which
each bit represents a target. Setting the target's
bit to '1' enables read streaming for that
target. Controllers may be omitted indicating that
they should retain the default read streaming setting.
Example: rd_strm:{0x0041}
On Controller 0
enables read streaming for targets 0 and 6.
disables read streaming for targets 1-5,7-15.
All other targets retain the default read
streaming setting.
Example: rd_strm:{0x0023,,0xFFFF}
On Controller 0
enables read streaming for targets 1,2, and 5.
disables read streaming for targets 3,4,6-15.
On Controller 2
enables read streaming for all targets.
All other targets retain the default read
streaming setting.
Possible Values: 0x0000 - 0xffff
Default Value: 0x0000
-----------------------------------------------------------------
Option: dv: {value[,value...]}
Definition: Set Domain Validation Policy on a per-controller basis.
Controllers may be omitted indicating that
they should retain the default read streaming setting.
Example: dv:{-1,0,,1,1,0}
On Controller 0 leave DV at its default setting.
On Controller 1 disable DV.
Skip configuration on Controller 2.
On Controllers 3 and 4 enable DV.
On Controller 5 disable DV.
Possible Values: < 0 Use setting from serial EEPROM.
0 Disable DV
> 0 Enable DV
Default Value: DV Serial EEPROM configuration setting.
-----------------------------------------------------------------
Option: seltime:[value]
Definition: Specifies the selection timeout value
Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms
Default Value: 0
-----------------------------------------------------------------
*** The following three options should only be changed at ***
*** the direction of a technical support representative. ***
-----------------------------------------------------------------
Option: precomp: {value[,value...]}
Definition: Set IO Cell precompensation value on a per-controller
basis.
Controllers may be omitted indicating that
they should retain the default precompensation setting.
Example: precomp:{0x1}
On Controller 0 set precompensation to 1.
Example: precomp:{1,,7}
On Controller 0 set precompensation to 1.
On Controller 2 set precompensation to 8.
Possible Values: 0 - 7
Default Value: Varies based on chip revision
-----------------------------------------------------------------
Option: slewrate: {value[,value...]}
Definition: Set IO Cell slew rate on a per-controller basis.
Controllers may be omitted indicating that
they should retain the default slew rate setting.
Example: slewrate:{0x1}
On Controller 0 set slew rate to 1.
Example: slewrate :{1,,8}
On Controller 0 set slew rate to 1.
On Controller 2 set slew rate to 8.
Possible Values: 0 - 15
Default Value: Varies based on chip revision
-----------------------------------------------------------------
Option: amplitude: {value[,value...]}
Definition: Set IO Cell signal amplitude on a per-controller basis.
Controllers may be omitted indicating that
they should retain the default read streaming setting.
Example: amplitude:{0x1}
On Controller 0 set amplitude to 1.
Example: amplitude :{1,,7}
On Controller 0 set amplitude to 1.
On Controller 2 set amplitude to 7.
Possible Values: 1 - 7
Default Value: Varies based on chip revision
-----------------------------------------------------------------
Example: 'options aic79xx aic79xx=verbose,rd_strm:{{0x0041}}'
enables verbose output in the driver and turns read streaming on
for targets 0 and 6 of Controller 0.
4. Additional Notes
4.1. Known/Unresolved or FYI Issues
* Under SuSE Linux Enterprise 7, the driver may fail to operate
correctly due to a problem with PCI interrupt routing in the
Linux kernel. Please contact SuSE for an updated Linux
kernel.
4.2. Third-Party Compatibility Issues
* Adaptec only supports Ultra320 hard drives running
the latest firmware available. Please check with
your hard drive manufacturer to ensure you have the
latest version.
4.3. Operating System or Technology Limitations
* PCI Hot Plug is untested and may cause the operating system
to stop responding.
* Luns that are not numbered contiguously starting with 0 might not
be automatically probed during system startup. This is a limitation
of the OS. Please contact your Linux vendor for instructions on
manually probing non-contiguous luns.
* Using the Driver Update Disk version of this package during OS
installation under RedHat might result in two versions of this
driver being installed into the system module directory. This
might cause problems with the /sbin/mkinitrd program and/or
other RPM packages that try to install system modules. The best
way to correct this once the system is running is to install
the latest RPM package version of this driver, available from
http://www.adaptec.com.
5. Adaptec Customer Support
A Technical Support Identification (TSID) Number is required for
Adaptec technical support.
- The 12-digit TSID can be found on the white barcode-type label
included inside the box with your product. The TSID helps us
provide more efficient service by accurately identifying your
product and support status.
Support Options
- Search the Adaptec Support Knowledgebase (ASK) at
http://ask.adaptec.com for articles, troubleshooting tips, and
frequently asked questions about your product.
- For support via Email, submit your question to Adaptec's
Technical Support Specialists at http://ask.adaptec.com/.
North America
- Visit our Web site at http://www.adaptec.com/.
- For information about Adaptec's support options, call
408-957-2550, 24 hours a day, 7 days a week.
- To speak with a Technical Support Specialist,
* For hardware products, call 408-934-7274,
Monday to Friday, 3:00 am to 5:00 pm, PDT.
* For RAID and Fibre Channel products, call 321-207-2000,
Monday to Friday, 3:00 am to 5:00 pm, PDT.
To expedite your service, have your computer with you.
- To order Adaptec products, including accessories and cables,
call 408-957-7274. To order cables online go to
http://www.adaptec.com/buy-cables/.
Europe
- Visit our Web site at http://www.adaptec.com/en-US/_common/world_index.
- To speak with a Technical Support Specialist, call, or email,
* German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET,
http://ask-de.adaptec.com/.
* French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET,
http://ask-fr.adaptec.com/.
* English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT,
http://ask.adaptec.com/.
- You can order Adaptec cables online at
http://www.adaptec.com/buy-cables/.
Japan
- Visit our web site at http://www.adaptec.co.jp/.
- To speak with a Technical Support Specialist, call
+81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m.,
1:00 p.m. to 6:00 p.m.
-------------------------------------------------------------------
/*
* Copyright (c) 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA.
* All rights reserved.
*
* You are permitted to redistribute, use and modify this README file in whole
* or in part in conjunction with redistribution of software governed by the
* General Public License, provided that the following conditions are met:
* 1. Redistributions of README file must retain the above copyright
* notice, this list of conditions, and the following disclaimer,
* without modification.
* 2. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
* 3. Modifications or new contributions must be attributed in a copyright
* notice identifying the author ("Contributor") and added below the
* original copyright notice. The copyright notice is for purposes of
* identifying contributors and should not be deemed as permission to alter
* the permissions given by Adaptec.
*
* THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY
* WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* ADAPTEC OR CONTRIBUTORS 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 INTERRUPTION) 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 README
* FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

394
Documentation/scsi/aic7xxx.txt Normal file
View file

@ -0,0 +1,394 @@
====================================================================
= Adaptec Aic7xxx Fast -> Ultra160 Family Manager Set v7.0 =
= README for =
= The Linux Operating System =
====================================================================
The following information is available in this file:
1. Supported Hardware
2. Version History
3. Command Line Options
4. Contacting Adaptec
1. Supported Hardware
The following Adaptec SCSI Chips and Host Adapters are supported by
the aic7xxx driver.
Chip MIPS Host Bus MaxSync MaxWidth SCBs Notes
---------------------------------------------------------------
aic7770 10 EISA/VL 10MHz 16Bit 4 1
aic7850 10 PCI/32 10MHz 8Bit 3
aic7855 10 PCI/32 10MHz 8Bit 3
aic7856 10 PCI/32 10MHz 8Bit 3
aic7859 10 PCI/32 20MHz 8Bit 3
aic7860 10 PCI/32 20MHz 8Bit 3
aic7870 10 PCI/32 10MHz 16Bit 16
aic7880 10 PCI/32 20MHz 16Bit 16
aic7890 20 PCI/32 40MHz 16Bit 16 3 4 5 6 7 8
aic7891 20 PCI/64 40MHz 16Bit 16 3 4 5 6 7 8
aic7892 20 PCI/64-66 80MHz 16Bit 16 3 4 5 6 7 8
aic7895 15 PCI/32 20MHz 16Bit 16 2 3 4 5
aic7895C 15 PCI/32 20MHz 16Bit 16 2 3 4 5 8
aic7896 20 PCI/32 40MHz 16Bit 16 2 3 4 5 6 7 8
aic7897 20 PCI/64 40MHz 16Bit 16 2 3 4 5 6 7 8
aic7899 20 PCI/64-66 80MHz 16Bit 16 2 3 4 5 6 7 8
1. Multiplexed Twin Channel Device - One controller servicing two
busses.
2. Multi-function Twin Channel Device - Two controllers on one chip.
3. Command Channel Secondary DMA Engine - Allows scatter gather list
and SCB prefetch.
4. 64 Byte SCB Support - Allows disconnected, untagged request table
for all possible target/lun combinations.
5. Block Move Instruction Support - Doubles the speed of certain
sequencer operations.
6. `Bayonet' style Scatter Gather Engine - Improves S/G prefetch
performance.
7. Queuing Registers - Allows queuing of new transactions without
pausing the sequencer.
8. Multiple Target IDs - Allows the controller to respond to selection
as a target on multiple SCSI IDs.
Controller Chip Host-Bus Int-Connectors Ext-Connectors Notes
--------------------------------------------------------------------------
AHA-274X[A] aic7770 EISA SE-50M SE-HD50F
AHA-274X[A]W aic7770 EISA SE-HD68F SE-HD68F
SE-50M
AHA-274X[A]T aic7770 EISA 2 X SE-50M SE-HD50F
AHA-2842 aic7770 VL SE-50M SE-HD50F
AHA-2940AU aic7860 PCI/32 SE-50M SE-HD50F
AVA-2902I aic7860 PCI/32 SE-50M
AVA-2902E aic7860 PCI/32 SE-50M
AVA-2906 aic7856 PCI/32 SE-50M SE-DB25F
APC-7850 aic7850 PCI/32 SE-50M 1
AVA-2940 aic7860 PCI/32 SE-50M
AHA-2920B aic7860 PCI/32 SE-50M
AHA-2930B aic7860 PCI/32 SE-50M
AHA-2920C aic7856 PCI/32 SE-50M SE-HD50F
AHA-2930C aic7860 PCI/32 SE-50M
AHA-2930C aic7860 PCI/32 SE-50M
AHA-2910C aic7860 PCI/32 SE-50M
AHA-2915C aic7860 PCI/32 SE-50M
AHA-2940AU/CN aic7860 PCI/32 SE-50M SE-HD50F
AHA-2944W aic7870 PCI/32 HVD-HD68F HVD-HD68F
HVD-50M
AHA-3940W aic7870 PCI/32 2 X SE-HD68F SE-HD68F 2
AHA-2940UW aic7880 PCI/32 SE-HD68F
SE-50M SE-HD68F
AHA-2940U aic7880 PCI/32 SE-50M SE-HD50F
AHA-2940D aic7880 PCI/32
aHA-2940 A/T aic7880 PCI/32
AHA-2940D A/T aic7880 PCI/32
AHA-3940UW aic7880 PCI/32 2 X SE-HD68F SE-HD68F 3
AHA-3940UWD aic7880 PCI/32 2 X SE-HD68F 2 X SE-VHD68F 3
AHA-3940U aic7880 PCI/32 2 X SE-50M SE-HD50F 3
AHA-2944UW aic7880 PCI/32 HVD-HD68F HVD-HD68F
HVD-50M
AHA-3944UWD aic7880 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F 3
AHA-4944UW aic7880 PCI/32
AHA-2930UW aic7880 PCI/32
AHA-2940UW Pro aic7880 PCI/32 SE-HD68F SE-HD68F 4
SE-50M
AHA-2940UW/CN aic7880 PCI/32
AHA-2940UDual aic7895 PCI/32
AHA-2940UWDual aic7895 PCI/32
AHA-3940UWD aic7895 PCI/32
AHA-3940AUW aic7895 PCI/32
AHA-3940AUWD aic7895 PCI/32
AHA-3940AU aic7895 PCI/32
AHA-3944AUWD aic7895 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F
AHA-2940U2B aic7890 PCI/32 LVD-HD68F LVD-HD68F
AHA-2940U2 OEM aic7891 PCI/64
AHA-2940U2W aic7890 PCI/32 LVD-HD68F LVD-HD68F
SE-HD68F
SE-50M
AHA-2950U2B aic7891 PCI/64 LVD-HD68F LVD-HD68F
AHA-2930U2 aic7890 PCI/32 LVD-HD68F SE-HD50F
SE-50M
AHA-3950U2B aic7897 PCI/64
AHA-3950U2D aic7897 PCI/64
AHA-29160 aic7892 PCI/64-66
AHA-29160 CPQ aic7892 PCI/64-66
AHA-29160N aic7892 PCI/32 LVD-HD68F SE-HD50F
SE-50M
AHA-29160LP aic7892 PCI/64-66
AHA-19160 aic7892 PCI/64-66
AHA-29150LP aic7892 PCI/64-66
AHA-29130LP aic7892 PCI/64-66
AHA-3960D aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F
LVD-50M
AHA-3960D CPQ aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F
LVD-50M
AHA-39160 aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F
LVD-50M
1. No BIOS support
2. DEC21050 PCI-PCI bridge with multiple controller chips on secondary bus
3. DEC2115X PCI-PCI bridge with multiple controller chips on secondary bus
4. All three SCSI connectors may be used simultaneously without
SCSI "stub" effects.
2. Version History
7.0 (4th August, 2005)
- Updated driver to use SCSI transport class infrastructure
- Upported sequencer and core fixes from last adaptec released
version of the driver.
6.2.36 (June 3rd, 2003)
- Correct code that disables PCI parity error checking.
- Correct and simplify handling of the ignore wide residue
message. The previous code would fail to report a residual
if the transaction data length was even and we received
an IWR message.
- Add support for the 2.5.X EISA framework.
- Update for change in 2.5.X SCSI proc FS interface.
- Correct Domain Validation command-line option parsing.
- When negotiation async via an 8bit WDTR message, send
an SDTR with an offset of 0 to be sure the target
knows we are async. This works around a firmware defect
in the Quantum Atlas 10K.
- Clear PCI error state during driver attach so that we
don't disable memory mapped I/O due to a stray write
by some other driver probe that occurred before we
claimed the controller.
6.2.35 (May 14th, 2003)
- Fix a few GCC 3.3 compiler warnings.
- Correct operation on EISA Twin Channel controller.
- Add support for 2.5.X's scsi_report_device_reset().
6.2.34 (May 5th, 2003)
- Fix locking regression introduced in 6.2.29 that
could cause a lock order reversal between the io_request_lock
and our per-softc lock. This was only possible on RH9,
SuSE, and kernel.org 2.4.X kernels.
6.2.33 (April 30th, 2003)
- Dynamically disable PCI parity error reporting after
10 errors are reported to the user. These errors are
the result of some other device issuing PCI transactions
with bad parity. Once the user has been informed of the
problem, continuing to report the errors just degrades
our performance.
6.2.32 (March 28th, 2003)
- Dynamically sized S/G lists to avoid SCSI malloc
pool fragmentation and SCSI mid-layer deadlock.
6.2.28 (January 20th, 2003)
- Domain Validation Fixes
- Add ability to disable PCI parity error checking.
- Enhanced Memory Mapped I/O probe
6.2.20 (November 7th, 2002)
- Added Domain Validation.
3. Command Line Options
WARNING: ALTERING OR ADDING THESE DRIVER PARAMETERS
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
USE THEM WITH CAUTION.
Put a .conf file in the /etc/modprobe.d directory and add/edit a
line containing 'options aic7xxx aic7xxx=[command[,command...]]' where
'command' is one or more of the following:
-----------------------------------------------------------------
Option: verbose
Definition: enable additional informative messages during
driver operation.
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: debug:[value]
Definition: Enables various levels of debugging information
Possible Values: 0x0000 = no debugging, 0xffff = full debugging
Default Value: 0x0000
-----------------------------------------------------------------
Option: no_probe
Option: probe_eisa_vl
Definition: Do not probe for EISA/VLB controllers.
This is a toggle. If the driver is compiled
to not probe EISA/VLB controllers by default,
specifying "no_probe" will enable this probing.
If the driver is compiled to probe EISA/VLB
controllers by default, specifying "no_probe"
will disable this probing.
Possible Values: This option is a toggle
Default Value: EISA/VLB probing is disabled by default.
-----------------------------------------------------------------
Option: pci_parity
Definition: Toggles the detection of PCI parity errors.
On many motherboards with VIA chipsets,
PCI parity is not generated correctly on the
PCI bus. It is impossible for the hardware to
differentiate between these "spurious" parity
errors and real parity errors. The symptom of
this problem is a stream of the message:
"scsi0: Data Parity Error Detected during address or write data phase"
output by the driver.
Possible Values: This option is a toggle
Default Value: PCI Parity Error reporting is disabled
-----------------------------------------------------------------
Option: no_reset
Definition: Do not reset the bus during the initial probe
phase
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: extended
Definition: Force extended translation on the controller
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: periodic_otag
Definition: Send an ordered tag periodically to prevent
tag starvation. Needed for some older devices
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: reverse_scan
Definition: Probe the scsi bus in reverse order, starting
with target 15
Possible Values: This option is a flag
Default Value: disabled
-----------------------------------------------------------------
Option: global_tag_depth:[value]
Definition: Global tag depth for all targets on all busses.
This option sets the default tag depth which
may be selectively overridden vi the tag_info
option.
Possible Values: 1 - 253
Default Value: 32
-----------------------------------------------------------------
Option: tag_info:{{value[,value...]}[,{value[,value...]}...]}
Definition: Set the per-target tagged queue depth on a
per controller basis. Both controllers and targets
may be omitted indicating that they should retain
the default tag depth.
Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32}
On Controller 0
specifies a tag depth of 16 for target 0
specifies a tag depth of 64 for target 3
specifies a tag depth of 8 for targets 4 and 5
leaves target 6 at the default
specifies a tag depth of 32 for targets 1,2,7-15
All other targets retain the default depth.
tag_info:{{},{32,,32}}
On Controller 1
specifies a tag depth of 32 for targets 0 and 2
All other targets retain the default depth.
Possible Values: 1 - 253
Default Value: 32
-----------------------------------------------------------------
Option: seltime:[value]
Definition: Specifies the selection timeout value
Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms
Default Value: 0
-----------------------------------------------------------------
Option: dv: {value[,value...]}
Definition: Set Domain Validation Policy on a per-controller basis.
Controllers may be omitted indicating that
they should retain the default read streaming setting.
Example: dv:{-1,0,,1,1,0}
On Controller 0 leave DV at its default setting.
On Controller 1 disable DV.
Skip configuration on Controller 2.
On Controllers 3 and 4 enable DV.
On Controller 5 disable DV.
Possible Values: < 0 Use setting from serial EEPROM.
0 Disable DV
> 0 Enable DV
Default Value: SCSI-Select setting on controllers with a SCSI Select
option for DV. Otherwise, on for controllers supporting
U160 speeds and off for all other controller types.
-----------------------------------------------------------------
Example:
'options aic7xxx aic7xxx=verbose,no_probe,tag_info:{{},{,,10}},seltime:1'
enables verbose logging, Disable EISA/VLB probing,
and set tag depth on Controller 1/Target 2 to 10 tags.
4. Adaptec Customer Support
A Technical Support Identification (TSID) Number is required for
Adaptec technical support.
- The 12-digit TSID can be found on the white barcode-type label
included inside the box with your product. The TSID helps us
provide more efficient service by accurately identifying your
product and support status.
Support Options
- Search the Adaptec Support Knowledgebase (ASK) at
http://ask.adaptec.com for articles, troubleshooting tips, and
frequently asked questions about your product.
- For support via Email, submit your question to Adaptec's
Technical Support Specialists at http://ask.adaptec.com/.
North America
- Visit our Web site at http://www.adaptec.com/.
- For information about Adaptec's support options, call
408-957-2550, 24 hours a day, 7 days a week.
- To speak with a Technical Support Specialist,
* For hardware products, call 408-934-7274,
Monday to Friday, 3:00 am to 5:00 pm, PDT.
* For RAID and Fibre Channel products, call 321-207-2000,
Monday to Friday, 3:00 am to 5:00 pm, PDT.
To expedite your service, have your computer with you.
- To order Adaptec products, including accessories and cables,
call 408-957-7274. To order cables online go to
http://www.adaptec.com/buy-cables/.
Europe
- Visit our Web site at http://www.adaptec.com/en-US/_common/world_index.
- To speak with a Technical Support Specialist, call, or email,
* German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET,
http://ask-de.adaptec.com/.
* French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET,
http://ask-fr.adaptec.com/.
* English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT,
http://ask.adaptec.com/.
- You can order Adaptec cables online at
http://www.adaptec.com/buy-cables/.
Japan
- Visit our web site at http://www.adaptec.co.jp/.
- To speak with a Technical Support Specialist, call
+81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m.,
1:00 p.m. to 6:00 p.m.
-------------------------------------------------------------------
/*
* Copyright (c) 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA.
* All rights reserved.
*
* You are permitted to redistribute, use and modify this README file in whole
* or in part in conjunction with redistribution of software governed by the
* General Public License, provided that the following conditions are met:
* 1. Redistributions of README file must retain the above copyright
* notice, this list of conditions, and the following disclaimer,
* without modification.
* 2. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
* 3. Modifications or new contributions must be attributed in a copyright
* notice identifying the author ("Contributor") and added below the
* original copyright notice. The copyright notice is for purposes of
* identifying contributors and should not be deemed as permission to alter
* the permissions given by Adaptec.
*
* THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY
* WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* ADAPTEC OR CONTRIBUTORS 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 INTERRUPTION) 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 README
* FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

574
Documentation/scsi/arcmsr_spec.txt Normal file
View file

@ -0,0 +1,574 @@
*******************************************************************************
** ARECA FIRMWARE SPEC
*******************************************************************************
** Usage of IOP331 adapter
** (All In/Out is in IOP331's view)
** 1. Message 0 --> InitThread message and return code
** 2. Doorbell is used for RS-232 emulation
** inDoorBell : bit0 -- data in ready
** (DRIVER DATA WRITE OK)
** bit1 -- data out has been read
** (DRIVER DATA READ OK)
** outDooeBell: bit0 -- data out ready
** (IOP331 DATA WRITE OK)
** bit1 -- data in has been read
** (IOP331 DATA READ OK)
** 3. Index Memory Usage
** offset 0xf00 : for RS232 out (request buffer)
** offset 0xe00 : for RS232 in (scratch buffer)
** offset 0xa00 : for inbound message code message_rwbuffer
** (driver send to IOP331)
** offset 0xa00 : for outbound message code message_rwbuffer
** (IOP331 send to driver)
** 4. RS-232 emulation
** Currently 128 byte buffer is used
** 1st uint32_t : Data length (1--124)
** Byte 4--127 : Max 124 bytes of data
** 5. PostQ
** All SCSI Command must be sent through postQ:
** (inbound queue port) Request frame must be 32 bytes aligned
** #bit27--bit31 => flag for post ccb
** #bit0--bit26 => real address (bit27--bit31) of post arcmsr_cdb
** bit31 :
** 0 : 256 bytes frame
** 1 : 512 bytes frame
** bit30 :
** 0 : normal request
** 1 : BIOS request
** bit29 : reserved
** bit28 : reserved
** bit27 : reserved
** ---------------------------------------------------------------------------
** (outbount queue port) Request reply
** #bit27--bit31
** => flag for reply
** #bit0--bit26
** => real address (bit27--bit31) of reply arcmsr_cdb
** bit31 : must be 0 (for this type of reply)
** bit30 : reserved for BIOS handshake
** bit29 : reserved
** bit28 :
** 0 : no error, ignore AdapStatus/DevStatus/SenseData
** 1 : Error, error code in AdapStatus/DevStatus/SenseData
** bit27 : reserved
** 6. BIOS request
** All BIOS request is the same with request from PostQ
** Except :
** Request frame is sent from configuration space
** offset: 0x78 : Request Frame (bit30 == 1)
** offset: 0x18 : writeonly to generate
** IRQ to IOP331
** Completion of request:
** (bit30 == 0, bit28==err flag)
** 7. Definition of SGL entry (structure)
** 8. Message1 Out - Diag Status Code (????)
** 9. Message0 message code :
** 0x00 : NOP
** 0x01 : Get Config
** ->offset 0xa00 :for outbound message code message_rwbuffer
** (IOP331 send to driver)
** Signature 0x87974060(4)
** Request len 0x00000200(4)
** numbers of queue 0x00000100(4)
** SDRAM Size 0x00000100(4)-->256 MB
** IDE Channels 0x00000008(4)
** vendor 40 bytes char
** model 8 bytes char
** FirmVer 16 bytes char
** Device Map 16 bytes char
** FirmwareVersion DWORD <== Added for checking of
** new firmware capability
** 0x02 : Set Config
** ->offset 0xa00 :for inbound message code message_rwbuffer
** (driver send to IOP331)
** Signature 0x87974063(4)
** UPPER32 of Request Frame (4)-->Driver Only
** 0x03 : Reset (Abort all queued Command)
** 0x04 : Stop Background Activity
** 0x05 : Flush Cache
** 0x06 : Start Background Activity
** (re-start if background is halted)
** 0x07 : Check If Host Command Pending
** (Novell May Need This Function)
** 0x08 : Set controller time
** ->offset 0xa00 : for inbound message code message_rwbuffer
** (driver to IOP331)
** byte 0 : 0xaa <-- signature
** byte 1 : 0x55 <-- signature
** byte 2 : year (04)
** byte 3 : month (1..12)
** byte 4 : date (1..31)
** byte 5 : hour (0..23)
** byte 6 : minute (0..59)
** byte 7 : second (0..59)
*******************************************************************************
*******************************************************************************
** RS-232 Interface for Areca Raid Controller
** The low level command interface is exclusive with VT100 terminal
** --------------------------------------------------------------------
** 1. Sequence of command execution
** --------------------------------------------------------------------
** (A) Header : 3 bytes sequence (0x5E, 0x01, 0x61)
** (B) Command block : variable length of data including length,
** command code, data and checksum byte
** (C) Return data : variable length of data
** --------------------------------------------------------------------
** 2. Command block
** --------------------------------------------------------------------
** (A) 1st byte : command block length (low byte)
** (B) 2nd byte : command block length (high byte)
** note ..command block length shouldn't > 2040 bytes,
** length excludes these two bytes
** (C) 3rd byte : command code
** (D) 4th and following bytes : variable length data bytes
** depends on command code
** (E) last byte : checksum byte (sum of 1st byte until last data byte)
** --------------------------------------------------------------------
** 3. Command code and associated data
** --------------------------------------------------------------------
** The following are command code defined in raid controller Command
** code 0x10--0x1? are used for system level management,
** no password checking is needed and should be implemented in separate
** well controlled utility and not for end user access.
** Command code 0x20--0x?? always check the password,
** password must be entered to enable these command.
** enum
** {
** GUI_SET_SERIAL=0x10,
** GUI_SET_VENDOR,
** GUI_SET_MODEL,
** GUI_IDENTIFY,
** GUI_CHECK_PASSWORD,
** GUI_LOGOUT,
** GUI_HTTP,
** GUI_SET_ETHERNET_ADDR,
** GUI_SET_LOGO,
** GUI_POLL_EVENT,
** GUI_GET_EVENT,
** GUI_GET_HW_MONITOR,
** // GUI_QUICK_CREATE=0x20, (function removed)
** GUI_GET_INFO_R=0x20,
** GUI_GET_INFO_V,
** GUI_GET_INFO_P,
** GUI_GET_INFO_S,
** GUI_CLEAR_EVENT,
** GUI_MUTE_BEEPER=0x30,
** GUI_BEEPER_SETTING,
** GUI_SET_PASSWORD,
** GUI_HOST_INTERFACE_MODE,
** GUI_REBUILD_PRIORITY,
** GUI_MAX_ATA_MODE,
** GUI_RESET_CONTROLLER,
** GUI_COM_PORT_SETTING,
** GUI_NO_OPERATION,
** GUI_DHCP_IP,
** GUI_CREATE_PASS_THROUGH=0x40,
** GUI_MODIFY_PASS_THROUGH,
** GUI_DELETE_PASS_THROUGH,
** GUI_IDENTIFY_DEVICE,
** GUI_CREATE_RAIDSET=0x50,
** GUI_DELETE_RAIDSET,
** GUI_EXPAND_RAIDSET,
** GUI_ACTIVATE_RAIDSET,
** GUI_CREATE_HOT_SPARE,
** GUI_DELETE_HOT_SPARE,
** GUI_CREATE_VOLUME=0x60,
** GUI_MODIFY_VOLUME,
** GUI_DELETE_VOLUME,
** GUI_START_CHECK_VOLUME,
** GUI_STOP_CHECK_VOLUME
** };
** Command description :
** GUI_SET_SERIAL : Set the controller serial#
** byte 0,1 : length
** byte 2 : command code 0x10
** byte 3 : password length (should be 0x0f)
** byte 4-0x13 : should be "ArEcATecHnoLogY"
** byte 0x14--0x23 : Serial number string (must be 16 bytes)
** GUI_SET_VENDOR : Set vendor string for the controller
** byte 0,1 : length
** byte 2 : command code 0x11
** byte 3 : password length (should be 0x08)
** byte 4-0x13 : should be "ArEcAvAr"
** byte 0x14--0x3B : vendor string (must be 40 bytes)
** GUI_SET_MODEL : Set the model name of the controller
** byte 0,1 : length
** byte 2 : command code 0x12
** byte 3 : password length (should be 0x08)
** byte 4-0x13 : should be "ArEcAvAr"
** byte 0x14--0x1B : model string (must be 8 bytes)
** GUI_IDENTIFY : Identify device
** byte 0,1 : length
** byte 2 : command code 0x13
** return "Areca RAID Subsystem "
** GUI_CHECK_PASSWORD : Verify password
** byte 0,1 : length
** byte 2 : command code 0x14
** byte 3 : password length
** byte 4-0x?? : user password to be checked
** GUI_LOGOUT : Logout GUI (force password checking on next command)
** byte 0,1 : length
** byte 2 : command code 0x15
** GUI_HTTP : HTTP interface (reserved for Http proxy service)(0x16)
**
** GUI_SET_ETHERNET_ADDR : Set the ethernet MAC address
** byte 0,1 : length
** byte 2 : command code 0x17
** byte 3 : password length (should be 0x08)
** byte 4-0x13 : should be "ArEcAvAr"
** byte 0x14--0x19 : Ethernet MAC address (must be 6 bytes)
** GUI_SET_LOGO : Set logo in HTTP
** byte 0,1 : length
** byte 2 : command code 0x18
** byte 3 : Page# (0/1/2/3) (0xff --> clear OEM logo)
** byte 4/5/6/7 : 0x55/0xaa/0xa5/0x5a
** byte 8 : TITLE.JPG data (each page must be 2000 bytes)
** note page0 1st 2 byte must be
** actual length of the JPG file
** GUI_POLL_EVENT : Poll If Event Log Changed
** byte 0,1 : length
** byte 2 : command code 0x19
** GUI_GET_EVENT : Read Event
** byte 0,1 : length
** byte 2 : command code 0x1a
** byte 3 : Event Page (0:1st page/1/2/3:last page)
** GUI_GET_HW_MONITOR : Get HW monitor data
** byte 0,1 : length
** byte 2 : command code 0x1b
** byte 3 : # of FANs(example 2)
** byte 4 : # of Voltage sensor(example 3)
** byte 5 : # of temperature sensor(example 2)
** byte 6 : # of power
** byte 7/8 : Fan#0 (RPM)
** byte 9/10 : Fan#1
** byte 11/12 : Voltage#0 original value in *1000
** byte 13/14 : Voltage#0 value
** byte 15/16 : Voltage#1 org
** byte 17/18 : Voltage#1
** byte 19/20 : Voltage#2 org
** byte 21/22 : Voltage#2
** byte 23 : Temp#0
** byte 24 : Temp#1
** byte 25 : Power indicator (bit0 : power#0,
** bit1 : power#1)
** byte 26 : UPS indicator
** GUI_QUICK_CREATE : Quick create raid/volume set
** byte 0,1 : length
** byte 2 : command code 0x20
** byte 3/4/5/6 : raw capacity
** byte 7 : raid level
** byte 8 : stripe size
** byte 9 : spare
** byte 10/11/12/13: device mask (the devices to create raid/volume)
** This function is removed, application like
** to implement quick create function
** need to use GUI_CREATE_RAIDSET and GUI_CREATE_VOLUMESET function.
** GUI_GET_INFO_R : Get Raid Set Information
** byte 0,1 : length
** byte 2 : command code 0x20
** byte 3 : raidset#
** typedef struct sGUI_RAIDSET
** {
** BYTE grsRaidSetName[16];
** DWORD grsCapacity;
** DWORD grsCapacityX;
** DWORD grsFailMask;
** BYTE grsDevArray[32];
** BYTE grsMemberDevices;
** BYTE grsNewMemberDevices;
** BYTE grsRaidState;
** BYTE grsVolumes;
** BYTE grsVolumeList[16];
** BYTE grsRes1;
** BYTE grsRes2;
** BYTE grsRes3;
** BYTE grsFreeSegments;
** DWORD grsRawStripes[8];
** DWORD grsRes4;
** DWORD grsRes5; // Total to 128 bytes
** DWORD grsRes6; // Total to 128 bytes
** } sGUI_RAIDSET, *pGUI_RAIDSET;
** GUI_GET_INFO_V : Get Volume Set Information
** byte 0,1 : length
** byte 2 : command code 0x21
** byte 3 : volumeset#
** typedef struct sGUI_VOLUMESET
** {
** BYTE gvsVolumeName[16]; // 16
** DWORD gvsCapacity;
** DWORD gvsCapacityX;
** DWORD gvsFailMask;
** DWORD gvsStripeSize;
** DWORD gvsNewFailMask;
** DWORD gvsNewStripeSize;
** DWORD gvsVolumeStatus;
** DWORD gvsProgress; // 32
** sSCSI_ATTR gvsScsi;
** BYTE gvsMemberDisks;
** BYTE gvsRaidLevel; // 8
** BYTE gvsNewMemberDisks;
** BYTE gvsNewRaidLevel;
** BYTE gvsRaidSetNumber;
** BYTE gvsRes0; // 4
** BYTE gvsRes1[4]; // 64 bytes
** } sGUI_VOLUMESET, *pGUI_VOLUMESET;
** GUI_GET_INFO_P : Get Physical Drive Information
** byte 0,1 : length
** byte 2 : command code 0x22
** byte 3 : drive # (from 0 to max-channels - 1)
** typedef struct sGUI_PHY_DRV
** {
** BYTE gpdModelName[40];
** BYTE gpdSerialNumber[20];
** BYTE gpdFirmRev[8];
** DWORD gpdCapacity;
** DWORD gpdCapacityX; // Reserved for expansion
** BYTE gpdDeviceState;
** BYTE gpdPioMode;
** BYTE gpdCurrentUdmaMode;
** BYTE gpdUdmaMode;
** BYTE gpdDriveSelect;
** BYTE gpdRaidNumber; // 0xff if not belongs to a raid set
** sSCSI_ATTR gpdScsi;
** BYTE gpdReserved[40]; // Total to 128 bytes
** } sGUI_PHY_DRV, *pGUI_PHY_DRV;
** GUI_GET_INFO_S : Get System Information
** byte 0,1 : length
** byte 2 : command code 0x23
** typedef struct sCOM_ATTR
** {
** BYTE comBaudRate;
** BYTE comDataBits;
** BYTE comStopBits;
** BYTE comParity;
** BYTE comFlowControl;
** } sCOM_ATTR, *pCOM_ATTR;
** typedef struct sSYSTEM_INFO
** {
** BYTE gsiVendorName[40];
** BYTE gsiSerialNumber[16];
** BYTE gsiFirmVersion[16];
** BYTE gsiBootVersion[16];
** BYTE gsiMbVersion[16];
** BYTE gsiModelName[8];
** BYTE gsiLocalIp[4];
** BYTE gsiCurrentIp[4];
** DWORD gsiTimeTick;
** DWORD gsiCpuSpeed;
** DWORD gsiICache;
** DWORD gsiDCache;
** DWORD gsiScache;
** DWORD gsiMemorySize;
** DWORD gsiMemorySpeed;
** DWORD gsiEvents;
** BYTE gsiMacAddress[6];
** BYTE gsiDhcp;
** BYTE gsiBeeper;
** BYTE gsiChannelUsage;
** BYTE gsiMaxAtaMode;
** BYTE gsiSdramEcc; // 1:if ECC enabled
** BYTE gsiRebuildPriority;
** sCOM_ATTR gsiComA; // 5 bytes
** sCOM_ATTR gsiComB; // 5 bytes
** BYTE gsiIdeChannels;
** BYTE gsiScsiHostChannels;
** BYTE gsiIdeHostChannels;
** BYTE gsiMaxVolumeSet;
** BYTE gsiMaxRaidSet;
** BYTE gsiEtherPort; // 1:if ether net port supported
** BYTE gsiRaid6Engine; // 1:Raid6 engine supported
** BYTE gsiRes[75];
** } sSYSTEM_INFO, *pSYSTEM_INFO;
** GUI_CLEAR_EVENT : Clear System Event
** byte 0,1 : length
** byte 2 : command code 0x24
** GUI_MUTE_BEEPER : Mute current beeper
** byte 0,1 : length
** byte 2 : command code 0x30
** GUI_BEEPER_SETTING : Disable beeper
** byte 0,1 : length
** byte 2 : command code 0x31
** byte 3 : 0->disable, 1->enable
** GUI_SET_PASSWORD : Change password
** byte 0,1 : length
** byte 2 : command code 0x32
** byte 3 : pass word length ( must <= 15 )
** byte 4 : password (must be alpha-numerical)
** GUI_HOST_INTERFACE_MODE : Set host interface mode
** byte 0,1 : length
** byte 2 : command code 0x33
** byte 3 : 0->Independent, 1->cluster
** GUI_REBUILD_PRIORITY : Set rebuild priority
** byte 0,1 : length
** byte 2 : command code 0x34
** byte 3 : 0/1/2/3 (low->high)
** GUI_MAX_ATA_MODE : Set maximum ATA mode to be used
** byte 0,1 : length
** byte 2 : command code 0x35
** byte 3 : 0/1/2/3 (133/100/66/33)
** GUI_RESET_CONTROLLER : Reset Controller
** byte 0,1 : length
** byte 2 : command code 0x36
** *Response with VT100 screen (discard it)
** GUI_COM_PORT_SETTING : COM port setting
** byte 0,1 : length
** byte 2 : command code 0x37
** byte 3 : 0->COMA (term port),
** 1->COMB (debug port)
** byte 4 : 0/1/2/3/4/5/6/7
** (1200/2400/4800/9600/19200/38400/57600/115200)
** byte 5 : data bit
** (0:7 bit, 1:8 bit : must be 8 bit)
** byte 6 : stop bit (0:1, 1:2 stop bits)
** byte 7 : parity (0:none, 1:off, 2:even)
** byte 8 : flow control
** (0:none, 1:xon/xoff, 2:hardware => must use none)
** GUI_NO_OPERATION : No operation
** byte 0,1 : length
** byte 2 : command code 0x38
** GUI_DHCP_IP : Set DHCP option and local IP address
** byte 0,1 : length
** byte 2 : command code 0x39
** byte 3 : 0:dhcp disabled, 1:dhcp enabled
** byte 4/5/6/7 : IP address
** GUI_CREATE_PASS_THROUGH : Create pass through disk
** byte 0,1 : length
** byte 2 : command code 0x40
** byte 3 : device #
** byte 4 : scsi channel (0/1)
** byte 5 : scsi id (0-->15)
** byte 6 : scsi lun (0-->7)
** byte 7 : tagged queue (1 : enabled)
** byte 8 : cache mode (1 : enabled)
** byte 9 : max speed (0/1/2/3/4,
** async/20/40/80/160 for scsi)
** (0/1/2/3/4, 33/66/100/133/150 for ide )
** GUI_MODIFY_PASS_THROUGH : Modify pass through disk
** byte 0,1 : length
** byte 2 : command code 0x41
** byte 3 : device #
** byte 4 : scsi channel (0/1)
** byte 5 : scsi id (0-->15)
** byte 6 : scsi lun (0-->7)
** byte 7 : tagged queue (1 : enabled)
** byte 8 : cache mode (1 : enabled)
** byte 9 : max speed (0/1/2/3/4,
** async/20/40/80/160 for scsi)
** (0/1/2/3/4, 33/66/100/133/150 for ide )
** GUI_DELETE_PASS_THROUGH : Delete pass through disk
** byte 0,1 : length
** byte 2 : command code 0x42
** byte 3 : device# to be deleted
** GUI_IDENTIFY_DEVICE : Identify Device
** byte 0,1 : length
** byte 2 : command code 0x43
** byte 3 : Flash Method
** (0:flash selected, 1:flash not selected)
** byte 4/5/6/7 : IDE device mask to be flashed
** note .... no response data available
** GUI_CREATE_RAIDSET : Create Raid Set
** byte 0,1 : length
** byte 2 : command code 0x50
** byte 3/4/5/6 : device mask
** byte 7-22 : raidset name (if byte 7 == 0:use default)
** GUI_DELETE_RAIDSET : Delete Raid Set
** byte 0,1 : length
** byte 2 : command code 0x51
** byte 3 : raidset#
** GUI_EXPAND_RAIDSET : Expand Raid Set
** byte 0,1 : length
** byte 2 : command code 0x52
** byte 3 : raidset#
** byte 4/5/6/7 : device mask for expansion
** byte 8/9/10 : (8:0 no change, 1 change, 0xff:terminate,
** 9:new raid level,
** 10:new stripe size
** 0/1/2/3/4/5->4/8/16/32/64/128K )
** byte 11/12/13 : repeat for each volume in the raidset
** GUI_ACTIVATE_RAIDSET : Activate incomplete raid set
** byte 0,1 : length
** byte 2 : command code 0x53
** byte 3 : raidset#
** GUI_CREATE_HOT_SPARE : Create hot spare disk
** byte 0,1 : length
** byte 2 : command code 0x54
** byte 3/4/5/6 : device mask for hot spare creation
** GUI_DELETE_HOT_SPARE : Delete hot spare disk
** byte 0,1 : length
** byte 2 : command code 0x55
** byte 3/4/5/6 : device mask for hot spare deletion
** GUI_CREATE_VOLUME : Create volume set
** byte 0,1 : length
** byte 2 : command code 0x60
** byte 3 : raidset#
** byte 4-19 : volume set name
** (if byte4 == 0, use default)
** byte 20-27 : volume capacity (blocks)
** byte 28 : raid level
** byte 29 : stripe size
** (0/1/2/3/4/5->4/8/16/32/64/128K)
** byte 30 : channel
** byte 31 : ID
** byte 32 : LUN
** byte 33 : 1 enable tag
** byte 34 : 1 enable cache
** byte 35 : speed
** (0/1/2/3/4->async/20/40/80/160 for scsi)
** (0/1/2/3/4->33/66/100/133/150 for IDE )
** byte 36 : 1 to select quick init
**
** GUI_MODIFY_VOLUME : Modify volume Set
** byte 0,1 : length
** byte 2 : command code 0x61
** byte 3 : volumeset#
** byte 4-19 : new volume set name
** (if byte4 == 0, not change)
** byte 20-27 : new volume capacity (reserved)
** byte 28 : new raid level
** byte 29 : new stripe size
** (0/1/2/3/4/5->4/8/16/32/64/128K)
** byte 30 : new channel
** byte 31 : new ID
** byte 32 : new LUN
** byte 33 : 1 enable tag
** byte 34 : 1 enable cache
** byte 35 : speed
** (0/1/2/3/4->async/20/40/80/160 for scsi)
** (0/1/2/3/4->33/66/100/133/150 for IDE )
** GUI_DELETE_VOLUME : Delete volume set
** byte 0,1 : length
** byte 2 : command code 0x62
** byte 3 : volumeset#
** GUI_START_CHECK_VOLUME : Start volume consistency check
** byte 0,1 : length
** byte 2 : command code 0x63
** byte 3 : volumeset#
** GUI_STOP_CHECK_VOLUME : Stop volume consistency check
** byte 0,1 : length
** byte 2 : command code 0x64
** ---------------------------------------------------------------------
** 4. Returned data
** ---------------------------------------------------------------------
** (A) Header : 3 bytes sequence (0x5E, 0x01, 0x61)
** (B) Length : 2 bytes
** (low byte 1st, excludes length and checksum byte)
** (C) status or data :
** <1> If length == 1 ==> 1 byte status code
** #define GUI_OK 0x41
** #define GUI_RAIDSET_NOT_NORMAL 0x42
** #define GUI_VOLUMESET_NOT_NORMAL 0x43
** #define GUI_NO_RAIDSET 0x44
** #define GUI_NO_VOLUMESET 0x45
** #define GUI_NO_PHYSICAL_DRIVE 0x46
** #define GUI_PARAMETER_ERROR 0x47
** #define GUI_UNSUPPORTED_COMMAND 0x48
** #define GUI_DISK_CONFIG_CHANGED 0x49
** #define GUI_INVALID_PASSWORD 0x4a
** #define GUI_NO_DISK_SPACE 0x4b
** #define GUI_CHECKSUM_ERROR 0x4c
** #define GUI_PASSWORD_REQUIRED 0x4d
** <2> If length > 1 ==>
** data block returned from controller
** and the contents depends on the command code
** (E) Checksum : checksum of length and status or data byte
**************************************************************************

82
Documentation/scsi/bfa.txt Normal file
View file

@ -0,0 +1,82 @@
Linux driver for Brocade FC/FCOE adapters
Supported Hardware
------------------
bfa 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of
adapter models with corresponding PCIIDs.
PCIID Model
1657:0013:1657:0014 425 4Gbps dual port FC HBA
1657:0013:1657:0014 825 8Gbps PCIe dual port FC HBA
1657:0013:103c:1742 HP 82B 8Gbps PCIedual port FC HBA
1657:0013:103c:1744 HP 42B 4Gbps dual port FC HBA
1657:0017:1657:0014 415 4Gbps single port FC HBA
1657:0017:1657:0014 815 8Gbps single port FC HBA
1657:0017:103c:1741 HP 41B 4Gbps single port FC HBA
1657:0017:103c 1743 HP 81B 8Gbps single port FC HBA
1657:0021:103c:1779 804 8Gbps FC HBA for HP Bladesystem c-class
1657:0014:1657:0014 1010 10Gbps single port CNA - FCOE
1657:0014:1657:0014 1020 10Gbps dual port CNA - FCOE
1657:0014:1657:0014 1007 10Gbps dual port CNA - FCOE
1657:0014:1657:0014 1741 10Gbps dual port CNA - FCOE
1657:0022:1657:0024 1860 16Gbps FC HBA
1657:0022:1657:0022 1860 10Gbps CNA - FCOE
Firmware download
-----------------
The latest Firmware package for 3.0.2.2 bfa driver can be found at:
http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page
and then click following respective util package link:
Version Link
v3.0.0.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2
Configuration & Management utility download
-------------------------------------------
The latest driver configuration & management utility for 3.0.2.2 bfa driver can
be found at:
http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page
and then click following respective util pacakge link
Version Link
v3.0.2.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2
Documentation
-------------
The latest Administration's Guide, Installation and Reference Manual,
Troubleshooting Guide, and Release Notes for the corresponding out-of-box
driver can be found at:
http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page
and use the following inbox and out-of-box driver version mapping to find
the corresponding documentation:
Inbox Version Out-of-box Version
v3.0.2.2 v3.0.0.0
Support
-------
For general product and support info, go to the Brocade website at:
http://www.brocade.com/services-support/index.page

75
Documentation/scsi/bnx2fc.txt Normal file
View file

@ -0,0 +1,75 @@
Operating FCoE using bnx2fc
===========================
Broadcom FCoE offload through bnx2fc is full stateful hardware offload that
cooperates with all interfaces provided by the Linux ecosystem for FC/FCoE and
SCSI controllers. As such, FCoE functionality, once enabled is largely
transparent. Devices discovered on the SAN will be registered and unregistered
automatically with the upper storage layers.
Despite the fact that the Broadcom's FCoE offload is fully offloaded, it does
depend on the state of the network interfaces to operate. As such, the network
interface (e.g. eth0) associated with the FCoE offload initiator must be 'up'.
It is recommended that the network interfaces be configured to be brought up
automatically at boot time.
Furthermore, the Broadcom FCoE offload solution creates VLAN interfaces to
support the VLANs that have been discovered for FCoE operation (e.g.
eth0.1001-fcoe). Do not delete or disable these interfaces or FCoE operation
will be disrupted.
Driver Usage Model:
===================
1. Ensure that fcoe-utils package is installed.
2. Configure the interfaces on which bnx2fc driver has to operate on.
Here are the steps to configure:
a. cd /etc/fcoe
b. copy cfg-ethx to cfg-eth5 if FCoE has to be enabled on eth5.
c. Repeat this for all the interfaces where FCoE has to be enabled.
d. Edit all the cfg-eth files to set "no" for DCB_REQUIRED** field, and
"yes" for AUTO_VLAN.
e. Other configuration parameters should be left as default
3. Ensure that "bnx2fc" is in SUPPORTED_DRIVERS list in /etc/fcoe/config.
4. Start fcoe service. (service fcoe start). If Broadcom devices are present in
the system, bnx2fc driver would automatically claim the interfaces, starts vlan
discovery and log into the targets.
5. "Symbolic Name" in 'fcoeadm -i' output would display if bnx2fc has claimed
the interface.
Eg:
[root@bh2 ~]# fcoeadm -i
Description: NetXtreme II BCM57712 10 Gigabit Ethernet
Revision: 01
Manufacturer: Broadcom Corporation
Serial Number: 0010186FD558
Driver: bnx2x 1.70.00-0
Number of Ports: 2
Symbolic Name: bnx2fc v1.0.5 over eth5.4
OS Device Name: host11
Node Name: 0x10000010186FD559
Port Name: 0x20000010186FD559
FabricName: 0x2001000DECB3B681
Speed: 10 Gbit
Supported Speed: 10 Gbit
MaxFrameSize: 2048
FC-ID (Port ID): 0x0F0377
State: Online
6. Verify the vlan discovery is performed by running ifconfig and notice
<INTERFACE>.<VLAN>-fcoe interfaces are automatically created.
Refer to fcoeadm manpage for more information on fcoeadm operations to
create/destroy interfaces or to display lun/target information.
NOTE:
====
** Broadcom FCoE capable devices implement a DCBX/LLDP client on-chip. Only one
LLDP client is allowed per interface. For proper operation all host software
based DCBX/LLDP clients (e.g. lldpad) must be disabled. To disable lldpad on a
given interface, run the following command:
lldptool set-lldp -i <interface_name> adminStatus=disabled

84
Documentation/scsi/cxgb3i.txt Normal file
View file

@ -0,0 +1,84 @@
Chelsio S3 iSCSI Driver for Linux
Introduction
============
The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc.
series of products) support iSCSI acceleration and iSCSI Direct Data Placement
(DDP) where the hardware handles the expensive byte touching operations, such
as CRC computation and verification, and direct DMA to the final host memory
destination:
- iSCSI PDU digest generation and verification
On transmitting, Chelsio S3 h/w computes and inserts the Header and
Data digest into the PDUs.
On receiving, Chelsio S3 h/w computes and verifies the Header and
Data digest of the PDUs.
- Direct Data Placement (DDP)
S3 h/w can directly place the iSCSI Data-In or Data-Out PDU's
payload into pre-posted final destination host-memory buffers based
on the Initiator Task Tag (ITT) in Data-In or Target Task Tag (TTT)
in Data-Out PDUs.
- PDU Transmit and Recovery
On transmitting, S3 h/w accepts the complete PDU (header + data)
from the host driver, computes and inserts the digests, decomposes
the PDU into multiple TCP segments if necessary, and transmit all
the TCP segments onto the wire. It handles TCP retransmission if
needed.
On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP
segments, separating the header and data, calculating and verifying
the digests, then forwarding the header to the host. The payload data,
if possible, will be directly placed into the pre-posted host DDP
buffer. Otherwise, the payload data will be sent to the host too.
The cxgb3i driver interfaces with open-iscsi initiator and provides the iSCSI
acceleration through Chelsio hardware wherever applicable.
Using the cxgb3i Driver
=======================
The following steps need to be taken to accelerates the open-iscsi initiator:
1. Load the cxgb3i driver: "modprobe cxgb3i"
The cxgb3i module registers a new transport class "cxgb3i" with open-iscsi.
* in the case of recompiling the kernel, the cxgb3i selection is located at
Device Drivers
SCSI device support --->
[*] SCSI low-level drivers --->
<M> Chelsio S3xx iSCSI support
2. Create an interface file located under /etc/iscsi/ifaces/ for the new
transport class "cxgb3i".
The content of the file should be in the following format:
iface.transport_name = cxgb3i
iface.net_ifacename = <ethX>
iface.ipaddress = <iscsi ip address>
* if iface.ipaddress is specified, <iscsi ip address> needs to be either the
same as the ethX's ip address or an address on the same subnet. Make
sure the ip address is unique in the network.
3. edit /etc/iscsi/iscsid.conf
The default setting for MaxRecvDataSegmentLength (131072) is too big;
replace with a value no bigger than 15360 (for example 8192):
node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192
* The login would fail for a normal session if MaxRecvDataSegmentLength is
too big. A error message in the format of
"cxgb3i: ERR! MaxRecvSegmentLength <X> too big. Need to be <= <Y>."
would be logged to dmesg.
4. To direct open-iscsi traffic to go through cxgb3i's accelerated path,
"-I <iface file name>" option needs to be specified with most of the
iscsiadm command. <iface file name> is the transport interface file created
in step 2.

102
Documentation/scsi/dc395x.txt Normal file
View file

@ -0,0 +1,102 @@
README file for the dc395x SCSI driver
==========================================
Status
------
The driver has been tested with CD-R and CD-R/W drives. These should
be safe to use. Testing with hard disks has not been done to any
great degree and caution should be exercised if you want to attempt
to use this driver with hard disks.
This is a 2.5 only driver. For a 2.4 driver please see the original
driver (which this driver started from) at
http://www.garloff.de/kurt/linux/dc395/
Problems, questions and patches should be submitted to the mailing
list. Details on the list, including archives, are available at
http://lists.twibble.org/mailman/listinfo/dc395x/
Parameters
----------
The driver uses the settings from the EEPROM set in the SCSI BIOS
setup. If there is no EEPROM, the driver uses default values.
Both can be overridden by command line parameters (module or kernel
parameters).
The following parameters are available:
- safe
Default: 0, Acceptable values: 0 or 1
If safe is set to 1 then the adapter will use conservative
("safe") default settings. This sets:
shortcut for dc395x=7,4,9,15,2,10
- adapter_id
Default: 7, Acceptable values: 0 to 15
Sets the host adapter SCSI ID.
- max_speed
Default: 1, Acceptable value: 0 to 7
0 = 20 Mhz
1 = 12.2 Mhz
2 = 10 Mhz
3 = 8 Mhz
4 = 6.7 Mhz
5 = 5.8 Hhz
6 = 5 Mhz
7 = 4 Mhz
- dev_mode
Bitmap for device configuration
DevMode bit definition:
Bit Val(hex) Val(dec) Meaning
*0 0x01 1 Parity check
*1 0x02 2 Synchronous Negotiation
*2 0x04 4 Disconnection
*3 0x08 8 Send Start command on startup. (Not used)
*4 0x10 16 Tagged Command Queueing
*5 0x20 32 Wide Negotiation
- adapter_mode
Bitmap for adapter configuration
AdaptMode bit definition
Bit Val(hex) Val(dec) Meaning
*0 0x01 1 Support more than two drives. (Not used)
*1 0x02 2 Use DOS compatible mapping for HDs greater than 1GB.
*2 0x04 4 Reset SCSI Bus on startup.
*3 0x08 8 Active Negation: Improves SCSI Bus noise immunity.
4 0x10 16 Immediate return on BIOS seek command. (Not used)
(*)5 0x20 32 Check for LUNs >= 1.
- tags
Default: 3, Acceptable values: 0-5
The number of tags is 1<<x, if x has been specified
- reset_delay
Default: 1, Acceptable values: 0-180
The seconds to not accept commands after a SCSI Reset
For the built in driver the parameters should be prefixed with
dc395x. (eg "dc395x.safe=1")
Copyright
---------
The driver is free software. It is protected by the GNU General Public
License (GPL). Please read it, before using this driver. It should be
included in your kernel sources and with your distribution. It carries the
filename COPYING. If you don't have it, please ask me to send you one by
email.
Note: The GNU GPL says also something about warranty and liability.
Please be aware the following: While we do my best to provide a working and
reliable driver, there is a chance, that it will kill your valuable data.
We refuse to take any responsibility for that. The driver is provided as-is
and YOU USE IT AT YOUR OWN RESPONSIBILITY.

83
Documentation/scsi/dpti.txt Normal file
View file

@ -0,0 +1,83 @@
/* 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 conditions
* 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 Adaptec's management 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.
*
*/

43
Documentation/scsi/dtc3x80.txt Normal file
View file

@ -0,0 +1,43 @@
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.
Its 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.

63
Documentation/scsi/g_NCR5380.txt Normal file
View file

@ -0,0 +1,63 @@
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

130
Documentation/scsi/hpsa.txt Normal file
View file

@ -0,0 +1,130 @@
HPSA - Hewlett Packard Smart Array driver
-----------------------------------------
This file describes the hpsa SCSI driver for HP Smart Array controllers.
The hpsa driver is intended to supplant the cciss driver for newer
Smart Array controllers. The hpsa driver is a SCSI driver, while the
cciss driver is a "block" driver. Actually cciss is both a block
driver (for logical drives) AND a SCSI driver (for tape drives). This
"split-brained" design of the cciss driver is a source of excess
complexity and eliminating that complexity is one of the reasons
for hpsa to exist.
Supported devices:
------------------
Smart Array P212
Smart Array P410
Smart Array P410i
Smart Array P411
Smart Array P812
Smart Array P712m
Smart Array P711m
StorageWorks P1210m
Additionally, older Smart Arrays may work with the hpsa driver if the kernel
boot parameter "hpsa_allow_any=1" is specified, however these are not tested
nor supported by HP with this driver. For older Smart Arrays, the cciss
driver should still be used.
The "hpsa_simple_mode=1" boot parameter may be used to prevent the driver from
putting the controller into "performant" mode. The difference is that with simple
mode, each command completion requires an interrupt, while with "performant mode"
(the default, and ordinarily better performing) it is possible to have multiple
command completions indicated by a single interrupt.
HPSA specific entries in /sys
-----------------------------
In addition to the generic SCSI attributes available in /sys, hpsa supports
the following attributes:
HPSA specific host attributes:
------------------------------
/sys/class/scsi_host/host*/rescan
/sys/class/scsi_host/host*/firmware_revision
/sys/class/scsi_host/host*/resettable
/sys/class/scsi_host/host*/transport_mode
the host "rescan" attribute is a write only attribute. Writing to this
attribute will cause the driver to scan for new, changed, or removed devices
(e.g. hot-plugged tape drives, or newly configured or deleted logical drives,
etc.) and notify the SCSI midlayer of any changes detected. Normally this is
triggered automatically by HP's Array Configuration Utility (either the GUI or
command line variety) so for logical drive changes, the user should not
normally have to use this. It may be useful when hot plugging devices like
tape drives, or entire storage boxes containing pre-configured logical drives.
The "firmware_revision" attribute contains the firmware version of the Smart Array.
For example:
root@host:/sys/class/scsi_host/host4# cat firmware_revision
7.14
The transport_mode indicates whether the controller is in "performant"
or "simple" mode. This is controlled by the "hpsa_simple_mode" module
parameter.
The "resettable" read-only attribute indicates whether a particular
controller is able to honor the "reset_devices" kernel parameter. If the
device is resettable, this file will contain a "1", otherwise, a "0". This
parameter is used by kdump, for example, to reset the controller at driver
load time to eliminate any outstanding commands on the controller and get the
controller into a known state so that the kdump initiated i/o will work right
and not be disrupted in any way by stale commands or other stale state
remaining on the controller from the previous kernel. This attribute enables
kexec tools to warn the user if they attempt to designate a device which is
unable to honor the reset_devices kernel parameter as a dump device.
HPSA specific disk attributes:
------------------------------
/sys/class/scsi_disk/c:b:t:l/device/unique_id
/sys/class/scsi_disk/c:b:t:l/device/raid_level
/sys/class/scsi_disk/c:b:t:l/device/lunid
(where c:b:t:l are the controller, bus, target and lun of the device)
For example:
root@host:/sys/class/scsi_disk/4:0:0:0/device# cat unique_id
600508B1001044395355323037570F77
root@host:/sys/class/scsi_disk/4:0:0:0/device# cat lunid
0x0000004000000000
root@host:/sys/class/scsi_disk/4:0:0:0/device# cat raid_level
RAID 0
HPSA specific ioctls:
---------------------
For compatibility with applications written for the cciss driver, many, but
not all of the ioctls supported by the cciss driver are also supported by the
hpsa driver. The data structures used by these are described in
include/linux/cciss_ioctl.h
CCISS_DEREGDISK
CCISS_REGNEWDISK
CCISS_REGNEWD
The above three ioctls all do exactly the same thing, which is to cause the driver
to rescan for new devices. This does exactly the same thing as writing to the
hpsa specific host "rescan" attribute.
CCISS_GETPCIINFO
Returns PCI domain, bus, device and function and "board ID" (PCI subsystem ID).
CCISS_GETDRIVVER
Returns driver version in three bytes encoded as:
(major_version << 16) | (minor_version << 8) | (subminor_version)
CCISS_PASSTHRU
CCISS_BIG_PASSTHRU
Allows "BMIC" and "CISS" commands to be passed through to the Smart Array.
These are used extensively by the HP Array Configuration Utility, SNMP storage
agents, etc. See cciss_vol_status at http://cciss.sf.net for some examples.

184
Documentation/scsi/hptiop.txt Normal file
View file

@ -0,0 +1,184 @@
HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop)
Controller Register Map
-------------------------
For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2:
BAR0 offset Register
0x11C5C Link Interface IRQ Set
0x11C60 Link Interface IRQ Clear
BAR2 offset Register
0x10 Inbound Message Register 0
0x14 Inbound Message Register 1
0x18 Outbound Message Register 0
0x1C Outbound Message Register 1
0x20 Inbound Doorbell Register
0x24 Inbound Interrupt Status Register
0x28 Inbound Interrupt Mask Register
0x30 Outbound Interrupt Status Register
0x34 Outbound Interrupt Mask Register
0x40 Inbound Queue Port
0x44 Outbound Queue Port
For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0:
BAR0 offset Register
0x10 Inbound Message Register 0
0x14 Inbound Message Register 1
0x18 Outbound Message Register 0
0x1C Outbound Message Register 1
0x20 Inbound Doorbell Register
0x24 Inbound Interrupt Status Register
0x28 Inbound Interrupt Mask Register
0x30 Outbound Interrupt Status Register
0x34 Outbound Interrupt Mask Register
0x40 Inbound Queue Port
0x44 Outbound Queue Port
For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
BAR0 offset Register
0x20400 Inbound Doorbell Register
0x20404 Inbound Interrupt Mask Register
0x20408 Outbound Doorbell Register
0x2040C Outbound Interrupt Mask Register
BAR1 offset Register
0x0 Inbound Queue Head Pointer
0x4 Inbound Queue Tail Pointer
0x8 Outbound Queue Head Pointer
0xC Outbound Queue Tail Pointer
0x10 Inbound Message Register
0x14 Outbound Message Register
0x40-0x1040 Inbound Queue
0x1040-0x2040 Outbound Queue
For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
BAR0 offset Register
0x0 IOP configuration information.
BAR1 offset Register
0x4000 Inbound List Base Address Low
0x4004 Inbound List Base Address High
0x4018 Inbound List Write Pointer
0x402C Inbound List Configuration and Control
0x4050 Outbound List Base Address Low
0x4054 Outbound List Base Address High
0x4058 Outbound List Copy Pointer Shadow Base Address Low
0x405C Outbound List Copy Pointer Shadow Base Address High
0x4088 Outbound List Interrupt Cause
0x408C Outbound List Interrupt Enable
0x1020C PCIe Function 0 Interrupt Enable
0x10400 PCIe Function 0 to CPU Message A
0x10420 CPU to PCIe Function 0 Message A
0x10480 CPU to PCIe Function 0 Doorbell
0x10484 CPU to PCIe Function 0 Doorbell Enable
I/O Request Workflow of Not Marvell Frey
------------------------------------------
All queued requests are handled via inbound/outbound queue port.
A request packet can be allocated in either IOP or host memory.
To send a request to the controller:
- Get a free request packet by reading the inbound queue port or
allocate a free request in host DMA coherent memory.
The value returned from the inbound queue port is an offset
relative to the IOP BAR0.
Requests allocated in host memory must be aligned on 32-bytes boundary.
- Fill the packet.
- Post the packet to IOP by writing it to inbound queue. For requests
allocated in IOP memory, write the offset to inbound queue port. For
requests allocated in host memory, write (0x80000000|(bus_addr>>5))
to the inbound queue port.
- The IOP process the request. When the request is completed, it
will be put into outbound queue. An outbound interrupt will be
generated.
For requests allocated in IOP memory, the request offset is posted to
outbound queue.
For requests allocated in host memory, (0x80000000|(bus_addr>>5))
is posted to the outbound queue. If IOP_REQUEST_FLAG_OUTPUT_CONTEXT
flag is set in the request, the low 32-bit context value will be
posted instead.
- The host read the outbound queue and complete the request.
For requests allocated in IOP memory, the host driver free the request
by writing it to the outbound queue.
Non-queued requests (reset/flush etc) can be sent via inbound message
register 0. An outbound message with the same value indicates the completion
of an inbound message.
I/O Request Workflow of Marvell Frey
--------------------------------------
All queued requests are handled via inbound/outbound list.
To send a request to the controller:
- Allocate a free request in host DMA coherent memory.
Requests allocated in host memory must be aligned on 32-bytes boundary.
- Fill the request with index of the request in the flag.
Fill a free inbound list unit with the physical address and the size of
the request.
Set up the inbound list write pointer with the index of previous unit,
round to 0 if the index reaches the supported count of requests.
- Post the inbound list writer pointer to IOP.
- The IOP process the request. When the request is completed, the flag of
the request with or-ed IOPMU_QUEUE_MASK_HOST_BITS will be put into a
free outbound list unit and the index of the outbound list unit will be
put into the copy pointer shadow register. An outbound interrupt will be
generated.
- The host read the outbound list copy pointer shadow register and compare
with previous saved read pointer N. If they are different, the host will
read the (N+1)th outbound list unit.
The host get the index of the request from the (N+1)th outbound list
unit and complete the request.
Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe
Function 0 to CPU Message A register. The CPU to PCIe Function 0 Message register
with the same value indicates the completion of message.
User-level Interface
---------------------
The driver exposes following sysfs attributes:
NAME R/W Description
driver-version R driver version string
firmware-version R firmware version string
-----------------------------------------------------------------------------
Copyright (C) 2006-2012 HighPoint Technologies, Inc. All Rights Reserved.
This file is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
linux@highpoint-tech.com
http://www.highpoint-tech.com

202
Documentation/scsi/in2000.txt Normal file
View file

@ -0,0 +1,202 @@
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 LUNs 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

469
Documentation/scsi/libsas.txt Normal file
View file

@ -0,0 +1,469 @@
SAS Layer
---------
The SAS Layer is a management infrastructure which manages
SAS LLDDs. It sits between SCSI Core and SAS LLDDs. The
layout is as follows: while SCSI Core is concerned with
SAM/SPC issues, and a SAS LLDD+sequencer is concerned with
phy/OOB/link management, the SAS layer is concerned with:
* SAS Phy/Port/HA event management (LLDD generates,
SAS Layer processes),
* SAS Port management (creation/destruction),
* SAS Domain discovery and revalidation,
* SAS Domain device management,
* SCSI Host registration/unregistration,
* Device registration with SCSI Core (SAS) or libata
(SATA), and
* Expander management and exporting expander control
to user space.
A SAS LLDD is a PCI device driver. It is concerned with
phy/OOB management, and vendor specific tasks and generates
events to the SAS layer.
The SAS Layer does most SAS tasks as outlined in the SAS 1.1
spec.
The sas_ha_struct describes the SAS LLDD to the SAS layer.
Most of it is used by the SAS Layer but a few fields need to
be initialized by the LLDDs.
After initializing your hardware, from the probe() function
you call sas_register_ha(). It will register your LLDD with
the SCSI subsystem, creating a SCSI host and it will
register your SAS driver with the sysfs SAS tree it creates.
It will then return. Then you enable your phys to actually
start OOB (at which point your driver will start calling the
notify_* event callbacks).
Structure descriptions:
struct sas_phy --------------------
Normally this is statically embedded to your driver's
phy structure:
struct my_phy {
blah;
struct sas_phy sas_phy;
bleh;
};
And then all the phys are an array of my_phy in your HA
struct (shown below).
Then as you go along and initialize your phys you also
initialize the sas_phy struct, along with your own
phy structure.
In general, the phys are managed by the LLDD and the ports
are managed by the SAS layer. So the phys are initialized
and updated by the LLDD and the ports are initialized and
updated by the SAS layer.
There is a scheme where the LLDD can RW certain fields,
and the SAS layer can only read such ones, and vice versa.
The idea is to avoid unnecessary locking.
enabled -- must be set (0/1)
id -- must be set [0,MAX_PHYS)
class, proto, type, role, oob_mode, linkrate -- must be set
oob_mode -- you set this when OOB has finished and then notify
the SAS Layer.
sas_addr -- this normally points to an array holding the sas
address of the phy, possibly somewhere in your my_phy
struct.
attached_sas_addr -- set this when you (LLDD) receive an
IDENTIFY frame or a FIS frame, _before_ notifying the SAS
layer. The idea is that sometimes the LLDD may want to fake
or provide a different SAS address on that phy/port and this
allows it to do this. At best you should copy the sas
address from the IDENTIFY frame or maybe generate a SAS
address for SATA directly attached devices. The Discover
process may later change this.
frame_rcvd -- this is where you copy the IDENTIFY/FIS frame
when you get it; you lock, copy, set frame_rcvd_size and
unlock the lock, and then call the event. It is a pointer
since there's no way to know your hw frame size _exactly_,
so you define the actual array in your phy struct and let
this pointer point to it. You copy the frame from your
DMAable memory to that area holding the lock.
sas_prim -- this is where primitives go when they're
received. See sas.h. Grab the lock, set the primitive,
release the lock, notify.
port -- this points to the sas_port if the phy belongs
to a port -- the LLDD only reads this. It points to the
sas_port this phy is part of. Set by the SAS Layer.
ha -- may be set; the SAS layer sets it anyway.
lldd_phy -- you should set this to point to your phy so you
can find your way around faster when the SAS layer calls one
of your callbacks and passes you a phy. If the sas_phy is
embedded you can also use container_of -- whatever you
prefer.
struct sas_port --------------------
The LLDD doesn't set any fields of this struct -- it only
reads them. They should be self explanatory.
phy_mask is 32 bit, this should be enough for now, as I
haven't heard of a HA having more than 8 phys.
lldd_port -- I haven't found use for that -- maybe other
LLDD who wish to have internal port representation can make
use of this.
struct sas_ha_struct --------------------
It normally is statically declared in your own LLDD
structure describing your adapter:
struct my_sas_ha {
blah;
struct sas_ha_struct sas_ha;
struct my_phy phys[MAX_PHYS];
struct sas_port sas_ports[MAX_PHYS]; /* (1) */
bleh;
};
(1) If your LLDD doesn't have its own port representation.
What needs to be initialized (sample function given below).
pcidev
sas_addr -- since the SAS layer doesn't want to mess with
memory allocation, etc, this points to statically
allocated array somewhere (say in your host adapter
structure) and holds the SAS address of the host
adapter as given by you or the manufacturer, etc.
sas_port
sas_phy -- an array of pointers to structures. (see
note above on sas_addr).
These must be set. See more notes below.
num_phys -- the number of phys present in the sas_phy array,
and the number of ports present in the sas_port
array. There can be a maximum num_phys ports (one per
port) so we drop the num_ports, and only use
num_phys.
The event interface:
/* LLDD calls these to notify the class of an event. */
void (*notify_ha_event)(struct sas_ha_struct *, enum ha_event);
void (*notify_port_event)(struct sas_phy *, enum port_event);
void (*notify_phy_event)(struct sas_phy *, enum phy_event);
When sas_register_ha() returns, those are set and can be
called by the LLDD to notify the SAS layer of such events
the SAS layer.
The port notification:
/* The class calls these to notify the LLDD of an event. */
void (*lldd_port_formed)(struct sas_phy *);
void (*lldd_port_deformed)(struct sas_phy *);
If the LLDD wants notification when a port has been formed
or deformed it sets those to a function satisfying the type.
A SAS LLDD should also implement at least one of the Task
Management Functions (TMFs) described in SAM:
/* Task Management Functions. Must be called from process context. */
int (*lldd_abort_task)(struct sas_task *);
int (*lldd_abort_task_set)(struct domain_device *, u8 *lun);
int (*lldd_clear_aca)(struct domain_device *, u8 *lun);
int (*lldd_clear_task_set)(struct domain_device *, u8 *lun);
int (*lldd_I_T_nexus_reset)(struct domain_device *);
int (*lldd_lu_reset)(struct domain_device *, u8 *lun);
int (*lldd_query_task)(struct sas_task *);
For more information please read SAM from T10.org.
Port and Adapter management:
/* Port and Adapter management */
int (*lldd_clear_nexus_port)(struct sas_port *);
int (*lldd_clear_nexus_ha)(struct sas_ha_struct *);
A SAS LLDD should implement at least one of those.
Phy management:
/* Phy management */
int (*lldd_control_phy)(struct sas_phy *, enum phy_func);
lldd_ha -- set this to point to your HA struct. You can also
use container_of if you embedded it as shown above.
A sample initialization and registration function
can look like this (called last thing from probe())
*but* before you enable the phys to do OOB:
static int register_sas_ha(struct my_sas_ha *my_ha)
{
int i;
static struct sas_phy *sas_phys[MAX_PHYS];
static struct sas_port *sas_ports[MAX_PHYS];
my_ha->sas_ha.sas_addr = &my_ha->sas_addr[0];
for (i = 0; i < MAX_PHYS; i++) {
sas_phys[i] = &my_ha->phys[i].sas_phy;
sas_ports[i] = &my_ha->sas_ports[i];
}
my_ha->sas_ha.sas_phy = sas_phys;
my_ha->sas_ha.sas_port = sas_ports;
my_ha->sas_ha.num_phys = MAX_PHYS;
my_ha->sas_ha.lldd_port_formed = my_port_formed;
my_ha->sas_ha.lldd_dev_found = my_dev_found;
my_ha->sas_ha.lldd_dev_gone = my_dev_gone;
my_ha->sas_ha.lldd_max_execute_num = lldd_max_execute_num; (1)
my_ha->sas_ha.lldd_queue_size = ha_can_queue;
my_ha->sas_ha.lldd_execute_task = my_execute_task;
my_ha->sas_ha.lldd_abort_task = my_abort_task;
my_ha->sas_ha.lldd_abort_task_set = my_abort_task_set;
my_ha->sas_ha.lldd_clear_aca = my_clear_aca;
my_ha->sas_ha.lldd_clear_task_set = my_clear_task_set;
my_ha->sas_ha.lldd_I_T_nexus_reset= NULL; (2)
my_ha->sas_ha.lldd_lu_reset = my_lu_reset;
my_ha->sas_ha.lldd_query_task = my_query_task;
my_ha->sas_ha.lldd_clear_nexus_port = my_clear_nexus_port;
my_ha->sas_ha.lldd_clear_nexus_ha = my_clear_nexus_ha;
my_ha->sas_ha.lldd_control_phy = my_control_phy;
return sas_register_ha(&my_ha->sas_ha);
}
(1) This is normally a LLDD parameter, something of the
lines of a task collector. What it tells the SAS Layer is
whether the SAS layer should run in Direct Mode (default:
value 0 or 1) or Task Collector Mode (value greater than 1).
In Direct Mode, the SAS Layer calls Execute Task as soon as
it has a command to send to the SDS, _and_ this is a single
command, i.e. not linked.
Some hardware (e.g. aic94xx) has the capability to DMA more
than one task at a time (interrupt) from host memory. Task
Collector Mode is an optional feature for HAs which support
this in their hardware. (Again, it is completely optional
even if your hardware supports it.)
In Task Collector Mode, the SAS Layer would do _natural_
coalescing of tasks and at the appropriate moment it would
call your driver to DMA more than one task in a single HA
interrupt. DMBS may want to use this by insmod/modprobe
setting the lldd_max_execute_num to something greater than
1.
(2) SAS 1.1 does not define I_T Nexus Reset TMF.
Events
------
Events are _the only way_ a SAS LLDD notifies the SAS layer
of anything. There is no other method or way a LLDD to tell
the SAS layer of anything happening internally or in the SAS
domain.
Phy events:
PHYE_LOSS_OF_SIGNAL, (C)
PHYE_OOB_DONE,
PHYE_OOB_ERROR, (C)
PHYE_SPINUP_HOLD.
Port events, passed on a _phy_:
PORTE_BYTES_DMAED, (M)
PORTE_BROADCAST_RCVD, (E)
PORTE_LINK_RESET_ERR, (C)
PORTE_TIMER_EVENT, (C)
PORTE_HARD_RESET.
Host Adapter event:
HAE_RESET
A SAS LLDD should be able to generate
- at least one event from group C (choice),
- events marked M (mandatory) are mandatory (only one),
- events marked E (expander) if it wants the SAS layer
to handle domain revalidation (only one such).
- Unmarked events are optional.
Meaning:
HAE_RESET -- when your HA got internal error and was reset.
PORTE_BYTES_DMAED -- on receiving an IDENTIFY/FIS frame
PORTE_BROADCAST_RCVD -- on receiving a primitive
PORTE_LINK_RESET_ERR -- timer expired, loss of signal, loss
of DWS, etc. (*)
PORTE_TIMER_EVENT -- DWS reset timeout timer expired (*)
PORTE_HARD_RESET -- Hard Reset primitive received.
PHYE_LOSS_OF_SIGNAL -- the device is gone (*)
PHYE_OOB_DONE -- OOB went fine and oob_mode is valid
PHYE_OOB_ERROR -- Error while doing OOB, the device probably
got disconnected. (*)
PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent.
(*) should set/clear the appropriate fields in the phy,
or alternatively call the inlined sas_phy_disconnected()
which is just a helper, from their tasklet.
The Execute Command SCSI RPC:
int (*lldd_execute_task)(struct sas_task *, int num,
unsigned long gfp_flags);
Used to queue a task to the SAS LLDD. @task is the tasks to
be executed. @num should be the number of tasks being
queued at this function call (they are linked listed via
task::list), @gfp_mask should be the gfp_mask defining the
context of the caller.
This function should implement the Execute Command SCSI RPC,
or if you're sending a SCSI Task as linked commands, you
should also use this function.
That is, when lldd_execute_task() is called, the command(s)
go out on the transport *immediately*. There is *no*
queuing of any sort and at any level in a SAS LLDD.
The use of task::list is two-fold, one for linked commands,
the other discussed below.
It is possible to queue up more than one task at a time, by
initializing the list element of struct sas_task, and
passing the number of tasks enlisted in this manner in num.
Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued;
0, the task(s) were queued.
If you want to pass num > 1, then either
A) you're the only caller of this function and keep track
of what you've queued to the LLDD, or
B) you know what you're doing and have a strategy of
retrying.
As opposed to queuing one task at a time (function call),
batch queuing of tasks, by having num > 1, greatly
simplifies LLDD code, sequencer code, and _hardware design_,
and has some performance advantages in certain situations
(DBMS).
The LLDD advertises if it can take more than one command at
a time at lldd_execute_task(), by setting the
lldd_max_execute_num parameter (controlled by "collector"
module parameter in aic94xx SAS LLDD).
You should leave this to the default 1, unless you know what
you're doing.
This is a function of the LLDD, to which the SAS layer can
cater to.
int lldd_queue_size
The host adapter's queue size. This is the maximum
number of commands the lldd can have pending to domain
devices on behalf of all upper layers submitting through
lldd_execute_task().
You really want to set this to something (much) larger than
1.
This _really_ has absolutely nothing to do with queuing.
There is no queuing in SAS LLDDs.
struct sas_task {
dev -- the device this task is destined to
list -- must be initialized (INIT_LIST_HEAD)
task_proto -- _one_ of enum sas_proto
scatter -- pointer to scatter gather list array
num_scatter -- number of elements in scatter
total_xfer_len -- total number of bytes expected to be transferred
data_dir -- PCI_DMA_...
task_done -- callback when the task has finished execution
};
DISCOVERY
---------
The sysfs tree has the following purposes:
a) It shows you the physical layout of the SAS domain at
the current time, i.e. how the domain looks in the
physical world right now.
b) Shows some device parameters _at_discovery_time_.
This is a link to the tree(1) program, very useful in
viewing the SAS domain:
ftp://mama.indstate.edu/linux/tree/
I expect user space applications to actually create a
graphical interface of this.
That is, the sysfs domain tree doesn't show or keep state if
you e.g., change the meaning of the READY LED MEANING
setting, but it does show you the current connection status
of the domain device.
Keeping internal device state changes is responsibility of
upper layers (Command set drivers) and user space.
When a device or devices are unplugged from the domain, this
is reflected in the sysfs tree immediately, and the device(s)
removed from the system.
The structure domain_device describes any device in the SAS
domain. It is completely managed by the SAS layer. A task
points to a domain device, this is how the SAS LLDD knows
where to send the task(s) to. A SAS LLDD only reads the
contents of the domain_device structure, but it never creates
or destroys one.
Expander management from User Space
-----------------------------------
In each expander directory in sysfs, there is a file called
"smp_portal". It is a binary sysfs attribute file, which
implements an SMP portal (Note: this is *NOT* an SMP port),
to which user space applications can send SMP requests and
receive SMP responses.
Functionality is deceptively simple:
1. Build the SMP frame you want to send. The format and layout
is described in the SAS spec. Leave the CRC field equal 0.
open(2)
2. Open the expander's SMP portal sysfs file in RW mode.
write(2)
3. Write the frame you built in 1.
read(2)
4. Read the amount of data you expect to receive for the frame you built.
If you receive different amount of data you expected to receive,
then there was some kind of error.
close(2)
All this process is shown in detail in the function do_smp_func()
and its callers, in the file "expander_conf.c".
The kernel functionality is implemented in the file
"sas_expander.c".
The program "expander_conf.c" implements this. It takes one
argument, the sysfs file name of the SMP portal to the
expander, and gives expander information, including routing
tables.
The SMP portal gives you complete control of the expander,
so please be careful.

19
Documentation/scsi/link_power_management_policy.txt Normal file
View file

@ -0,0 +1,19 @@
This parameter allows the user to set the link (interface) power management.
There are 3 possible options:
Value Effect
----------------------------------------------------------------------------
min_power Tell the controller to try to make the link use the
least possible power when possible. This may
sacrifice some performance due to increased latency
when coming out of lower power states.
max_performance Generally, this means no power management. Tell
the controller to have performance be a priority
over power management.
medium_power Tell the controller to enter a lower power state
when possible, but do not enter the lowest power
state, thus improving latency over min_power setting.

83
Documentation/scsi/lpfc.txt Normal file
View file

@ -0,0 +1,83 @@
LPFC Driver Release Notes:
=============================================================================
IMPORTANT:
Starting in the 8.0.17 release, the driver began to be targeted strictly
toward the upstream kernel. As such, we removed #ifdefs for older kernels
(pre 2.6.10). The 8.0.16 release should be used if the driver is to be
run on one of the older kernels.
The proposed modifications to the transport layer for FC remote ports
and extended attribute support is now part of the upstream kernel
as of 2.6.12. We no longer need to provide patches for this support,
nor a *full* version which has old an new kernel support.
The driver now requires a 2.6.12 (if pre-release, 2.6.12-rc1) or later
kernel.
Please heed these dependencies....
********************************************************************
The following information is provided for additional background on the
history of the driver as we push for upstream acceptance.
Cable pull and temporary device Loss:
In older revisions of the lpfc driver, the driver internally queued i/o
received from the midlayer. In the cases where a cable was pulled, link
jitter, or a device temporarily loses connectivity (due to its cable
being removed, a switch rebooting, or a device reboot), the driver could
hide the disappearance of the device from the midlayer. I/O's issued to
the LLDD would simply be queued for a short duration, allowing the device
to reappear or link come back alive, with no inadvertent side effects
to the system. If the driver did not hide these conditions, i/o would be
errored by the driver, the mid-layer would exhaust its retries, and the
device would be taken offline. Manual intervention would be required to
re-enable the device.
The community supporting kernel.org has driven an effort to remove
internal queuing from all LLDDs. The philosophy is that internal
queuing is unnecessary as the block layer already performs the
queuing. Removing the queues from the LLDD makes a more predictable
and more simple LLDD.
As a potential new addition to kernel.org, the 8.x driver was asked to
have all internal queuing removed. Emulex complied with this request.
In explaining the impacts of this change, Emulex has worked with the
community in modifying the behavior of the SCSI midlayer so that SCSI
devices can be temporarily suspended while transport events (such as
those described) can occur.
The proposed patch was posted to the linux-scsi mailing list. The patch
is contained in the 2.6.10-rc2 (and later) patch kits. As such, this
patch is part of the standard 2.6.10 kernel.
By default, the driver expects the patches for block/unblock interfaces
to be present in the kernel. No #define needs to be set to enable support.
Kernel Support
This source package is targeted for the upstream kernel only. (See notes
at the top of this file). It relies on interfaces that are slowing
migrating into the kernel.org kernel.
At this time, the driver requires the 2.6.12 (if pre-release, 2.6.12-rc1)
kernel.
If a driver is needed for older kernels please utilize the 8.0.16
driver sources.
Patches
Thankfully, at this time, patches are not needed.

70
Documentation/scsi/megaraid.txt Normal file
View file

@ -0,0 +1,70 @@
Notes on Management Module
~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
--------
Different classes of controllers from LSI Logic accept and respond to the
user applications in a similar way. They understand the same firmware control
commands. Furthermore, the applications also can treat different classes of
the controllers uniformly. Hence it is logical to have a single module that
interfaces with the applications on one side and all the low level drivers
on the other.
The advantages, though obvious, are listed for completeness:
i. Avoid duplicate code from the low level drivers.
ii. Unburden the low level drivers from having to export the
character node device and related handling.
iii. Implement any policy mechanisms in one place.
iv. Applications have to interface with only module instead of
multiple low level drivers.
Currently this module (called Common Management Module) is used only to issue
ioctl commands. But this module is envisioned to handle all user space level
interactions. So any 'proc', 'sysfs' implementations will be localized in this
common module.
Credits:
-------
"Shared code in a third module, a "library module", is an acceptable
solution. modprobe automatically loads dependent modules, so users
running "modprobe driver1" or "modprobe driver2" would automatically
load the shared library module."
- Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML
"As Jeff hinted, if your userspace<->driver API is consistent between
your new MPT-based RAID controllers and your existing megaraid driver,
then perhaps you need a single small helper module (lsiioctl or some
better name), loaded by both mptraid and megaraid automatically, which
handles registering the /dev/megaraid node dynamically. In this case,
both mptraid and megaraid would register with lsiioctl for each
adapter discovered, and lsiioctl would essentially be a switch,
redirecting userspace tool ioctls to the appropriate driver."
- Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML
Design:
------
The Common Management Module is implemented in megaraid_mm.[ch] files. This
module acts as a registry for low level hba drivers. The low level drivers
(currently only megaraid) register each controller with the common module.
The applications interface with the common module via the character device
node exported by the module.
The lower level drivers now understand only a new improved ioctl packet called
uioc_t. The management module converts the older ioctl packets from the older
applications into uioc_t. After driver handles the uioc_t, the common module
will convert that back into the old format before returning to applications.
As new applications evolve and replace the old ones, the old packet format
will be retired.
Common module dedicates one uioc_t packet to each controller registered. This
can easily be more than one. But since megaraid is the only low level driver
today, and it can handle only one ioctl, there is no reason to have more. But
as new controller classes get added, this will be tuned appropriately.

1849
Documentation/scsi/ncr53c8xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

197
Documentation/scsi/osd.txt Normal file
View file

@ -0,0 +1,197 @@
The OSD Standard
================
OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed
to provide efficient operation of input/output logical units that manage the
allocation, placement, and accessing of variable-size data-storage containers,
called objects. Objects are intended to contain operating system and application
constructs. Each object has associated attributes attached to it, which are
integral part of the object and provide metadata about the object. The standard
defines some common obligatory attributes, but user attributes can be added as
needed.
See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2
or search the web for "OSD SCSI"
OSD in the Linux Kernel
=======================
osd-initiator:
The main component of OSD in Kernel is the osd-initiator library. Its main
user is intended to be the pNFS-over-objects layout driver, which uses objects
as its back-end data storage. Other clients are the other osd parts listed below.
osd-uld:
This is a SCSI ULD that registers for OSD type devices and provides a testing
platform, both for the in-kernel initiator as well as connected targets. It
currently has no useful user-mode API, though it could have if need be.
exofs:
Is an OSD based Linux file system. It uses the osd-initiator and osd-uld,
to export a usable file system for users.
See Documentation/filesystems/exofs.txt for more details
osd target:
There are no current plans for an OSD target implementation in kernel. For all
needs, a user-mode target that is based on the scsi tgt target framework is
available from Ohio Supercomputer Center (OSC) at:
http://www.open-osd.org/bin/view/Main/OscOsdProject
There are several other target implementations. See http://open-osd.org for more
links.
Files and Folders
=================
This is the complete list of files included in this work:
include/scsi/
osd_initiator.h Main API for the initiator library
osd_types.h Common OSD types
osd_sec.h Security Manager API
osd_protocol.h Wire definitions of the OSD standard protocol
osd_attributes.h Wire definitions of OSD attributes
drivers/scsi/osd/
osd_initiator.c OSD-Initiator library implementation
osd_uld.c The OSD scsi ULD
osd_ktest.{h,c} In-kernel test suite (called by osd_uld)
osd_debug.h Some printk macros
Makefile For both in-tree and out-of-tree compilation
Kconfig Enables inclusion of the different pieces
osd_test.c User-mode application to call the kernel tests
The OSD-Initiator Library
=========================
osd_initiator is a low level implementation of an osd initiator encoder.
But even though, it should be intuitive and easy to use. Perhaps over time an
higher lever will form that automates some of the more common recipes.
init/fini:
- osd_dev_init() associates a scsi_device with an osd_dev structure
and initializes some global pools. This should be done once per scsi_device
(OSD LUN). The osd_dev structure is needed for calling osd_start_request().
- osd_dev_fini() cleans up before a osd_dev/scsi_device destruction.
OSD commands encoding, execution, and decoding of results:
struct osd_request's is used to iteratively encode an OSD command and carry
its state throughout execution. Each request goes through these stages:
a. osd_start_request() allocates the request.
b. Any of the osd_req_* methods is used to encode a request of the specified
type.
c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the
CDB. "List" or "Page" mode can be used exclusively. The attribute-list API
can be called multiple times on the same request. However, only one
attribute-page can be read, as mandated by the OSD standard.
d. osd_finalize_request() computes offsets into the data-in and data-out buffers
and signs the request using the provided capability key and integrity-
check parameters.
e. osd_execute_request() may be called to execute the request via the block
layer and wait for its completion. The request can be executed
asynchronously by calling the block layer API directly.
f. After execution, osd_req_decode_sense() can be called to decode the request's
sense information.
g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list()
values.
h. osd_end_request() must be called to deallocate the request and any resource
associated with it. Note that osd_end_request cleans up the request at any
stage and it must always be called after a successful osd_start_request().
osd_request's structure:
The OSD standard defines a complex structure of IO segments pointed to by
members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to
4 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with
associated get+set of attributes-lists. Other combinations very on the same
basic theme. From no-segments-used up to all-segments-used.
|________OSD-CDB__________|
| |
|read_len (offset=0) -|---------\
| | |
|get_attrs_list_length | |
|get_attrs_list_offset -|----\ |
| | | |
|retrieved_attrs_alloc_len| | |
|retrieved_attrs_offset -|----|----|-\
| | | | |
|set_attrs_list_length | | | |
|set_attrs_list_offset -|-\ | | |
| | | | | |
|in_data_integ_offset -|-|--|----|-|-\
|out_data_integ_offset -|-|--|--\ | | |
\_________________________/ | | | | | |
| | | | | |
|_______OUT-BUFFER________| | | | | | |
| Set attr list |</ | | | | |
| | | | | | |
|-------------------------| | | | | |
| Get attr descriptors |<---/ | | | |
| | | | | |
|-------------------------| | | | |
| Out-data integrity |<------/ | | |
| | | | |
\_________________________/ | | |
| | |
|________IN-BUFFER________| | | |
| In-Data read |<--------/ | |
| | | |
|-------------------------| | |
| Get attr list |<----------/ |
| | |
|-------------------------| |
| In-data integrity |<------------/
| |
\_________________________/
A block device request can carry bidirectional payload by means of associating
a bidi_read request with a main write-request. Each in/out request is described
by a chain of BIOs associated with each request.
The CDB is of a SCSI VARLEN CDB format, as described by OSD standard.
The OSD standard also mandates alignment restrictions at start of each segment.
In the code, in struct osd_request, there are two _osd_io_info structures to
describe the IN/OUT buffers above, two BIOs for the data payload and up to five
_osd_req_data_segment structures to hold the different segments allocation and
information.
Important: We have chosen to disregard the assumption that a BIO-chain (and
the resulting sg-list) describes a linear memory buffer. Meaning only first and
last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE.
For us, a scatter-gather-list, as its name implies and as used by the Networking
layer, is to describe a vector of buffers that will be transferred to/from the
wire. It works very well with current iSCSI transport. iSCSI is currently the
only deployed OSD transport. In the future we anticipate SAS and FC attached OSD
devices as well.
The OSD Testing ULD
===================
TODO: More user-mode control on tests.
Authors, Mailing list
=====================
Please communicate with us on any deployment of osd, whether using this code
or not.
Any problems, questions, bug reports, lonely OSD nights, please email:
OSD Dev List <osd-dev@open-osd.org>
More up-to-date information can be found on:
http://open-osd.org
Boaz Harrosh <ooo@electrozaur.com>
References
==========
Weber, R., "SCSI Object-Based Storage Device Commands",
T10/1355-D ANSI/INCITS 400-2004,
http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf
Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)"
T10/1729-D, Working Draft, rev. 3
http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf

218
Documentation/scsi/osst.txt Normal file
View file

@ -0,0 +1,218 @@
README file for the osst driver
===============================
(w) Kurt Garloff <garloff@suse.de> 12/2000
This file describes the osst driver as of version 0.8.x/0.9.x, the released
version of the osst driver.
It is intended to help advanced users to understand the role of osst and to
get them started using (and maybe debugging) it.
It won't address issues like "How do I compile a kernel?" or "How do I load
a module?", as these are too basic.
Once the OnStream got merged into the official kernel, the distro makers
will provide the OnStream support for those who are not familiar with
hacking their kernels.
Purpose
-------
The osst driver was developed, because the standard SCSI tape driver in
Linux, st, does not support the OnStream SC-x0 SCSI tape. The st is not to
blame for that, as the OnStream tape drives do not support the standard SCSI
command set for Serial Access Storage Devices (SASDs), which basically
corresponds to the QIC-157 spec.
Nevertheless, the OnStream tapes are nice pieces of hardware and therefore
the osst driver has been written to make these tape devs supported by Linux.
The driver is free software. It's released under the GNU GPL and planned to
be integrated into the mainstream kernel.
Implementation
--------------
The osst is a new high-level SCSI driver, just like st, sr, sd and sg. It
can be compiled into the kernel or loaded as a module.
As it represents a new device, it got assigned a new device node: /dev/osstX
are character devices with major no 206 and minor numbers like the /dev/stX
devices. If those are not present, you may create them by calling
Makedevs.sh as root (see below).
The driver started being a copy of st and as such, the osst devices'
behavior looks very much the same as st to the userspace applications.
History
-------
In the first place, osst shared its identity very much with st. That meant
that it used the same kernel structures and the same device node as st.
So you could only have either of them being present in the kernel. This has
been fixed by registering an own device, now.
st and osst can coexist, each only accessing the devices it can support by
themselves.
Installation
------------
osst got integrated into the linux kernel. Select it during kernel
configuration as module or compile statically into the kernel.
Compile your kernel and install the modules.
Now, your osst driver is inside the kernel or available as a module,
depending on your choice during kernel config. You may still need to create
the device nodes by calling the Makedevs.sh script (see below) manually.
To load your module, you may use the command
modprobe osst
as root. dmesg should show you, whether your OnStream tapes have been
recognized.
If you want to have the module autoloaded on access to /dev/osst, you may
add something like
alias char-major-206 osst
to a file under /etc/modprobe.d/ directory.
You may find it convenient to create a symbolic link
ln -s nosst0 /dev/tape
to make programs assuming a default name of /dev/tape more convenient to
use.
The device nodes for osst have to be created. Use the Makedevs.sh script
attached to this file.
Using it
--------
You may use the OnStream tape driver with your standard backup software,
which may be tar, cpio, amanda, arkeia, BRU, Lone Tar, ...
by specifying /dev/(n)osst0 as the tape device to use or using the above
symlink trick. The IOCTLs to control tape operation are also mostly
supported and you may try the mt (or mt_st) program to jump between
filemarks, eject the tape, ...
There's one limitation: You need to use a block size of 32kB.
(This limitation is worked on and will be fixed in version 0.8.8 of
this driver.)
If you just want to get started with standard software, here is an example
for creating and restoring a full backup:
# Backup
tar cvf - / --exclude /proc | buffer -s 32k -m 24M -B -t -o /dev/nosst0
# Restore
buffer -s 32k -m 8M -B -t -i /dev/osst0 | tar xvf - -C /
The buffer command has been used to buffer the data before it goes to the
tape (or the file system) in order to smooth out the data stream and prevent
the tape from needing to stop and rewind. The OnStream does have an internal
buffer and a variable speed which help this, but especially on writing, the
buffering still proves useful in most cases. It also pads the data to
guarantees the block size of 32k. (Otherwise you may pass the -b64 option to
tar.)
Expect something like 1.8MB/s for the SC-x0 drives and 0.9MB/s for the DI-30.
The USB drive will give you about 0.7MB/s.
On a fast machine, you may profit from software data compression (z flag for
tar).
USB and IDE
-----------
Via the SCSI emulation layers usb-storage and ide-scsi, you can also use the
osst driver to drive the USB-30 and the DI-30 drives. (Unfortunately, there
is no such layer for the parallel port, otherwise the DP-30 would work as
well.) For the USB support, you need the latest 2.4.0-test kernels and the
latest usb-storage driver from
http://www.linux-usb.org/
http://sourceforge.net/cvs/?group_id=3581
Note that the ide-tape driver as of 1.16f uses a slightly outdated on-tape
format and therefore is not completely interoperable with osst tapes.
The ADR-x0 line is fully SCSI-2 compliant and is supported by st, not osst.
The on-tape format is supposed to be compatible with the one used by osst.
Feedback and updates
--------------------
The driver development is coordinated through a mailing list
<osst@linux1.onstream.nl>
a CVS repository and some web pages.
The tester's pages which contain recent news and updated drivers to download
can be found on
http://sourceforge.net/projects/osst/
If you find any problems, please have a look at the tester's page in order
to see whether the problem is already known and solved. Otherwise, please
report it to the mailing list. Your feedback is welcome. (This holds also
for reports of successful usage, of course.)
In case of trouble, please do always provide the following info:
* driver and kernel version used (see syslog)
* driver messages (syslog)
* SCSI config and OnStream Firmware (/proc/scsi/scsi)
* description of error. Is it reproducible?
* software and commands used
You may subscribe to the mailing list, BTW, it's a majordomo list.
Status
------
0.8.0 was the first widespread BETA release. Since then a lot of reports
have been sent, but mostly reported success or only minor trouble.
All the issues have been addressed.
Check the web pages for more info about the current developments.
0.9.x is the tree for the 2.3/2.4 kernel.
Acknowledgments
----------------
The driver has been started by making a copy of Kai Makisara's st driver.
Most of the development has been done by Willem Riede. The presence of the
userspace program osg (onstreamsg) from Terry Hardie has been rather
helpful. The same holds for Gadi Oxman's ide-tape support for the DI-30.
I did add some patches to those drivers as well and coordinated things a
little bit.
Note that most of them did mostly spend their spare time for the creation of
this driver.
The people from OnStream, especially Jack Bombeeck did support this project
and always tried to answer HW or FW related questions. Furthermore, he
pushed the FW developers to do the right things.
SuSE did support this project by allowing me to work on it during my working
time for them and by integrating the driver into their distro.
More people did help by sending useful comments. Sorry to those who have
been forgotten. Thanks to all the GNU/FSF and Linux developers who made this
platform such an interesting, nice and stable platform.
Thanks go to those who tested the drivers and did send useful reports. Your
help is needed!
Makedevs.sh
-----------
#!/bin/sh
# Script to create OnStream SC-x0 device nodes (major 206)
# Usage: Makedevs.sh [nos [path to dev]]
# $Id: README.osst.kernel,v 1.4 2000/12/20 14:13:15 garloff Exp $
major=206
nrs=4
dir=/dev
test -z "$1" || nrs=$1
test -z "$2" || dir=$2
declare -i nr
nr=0
test -d $dir || mkdir -p $dir
while test $nr -lt $nrs; do
mknod $dir/osst$nr c $major $nr
chown 0.disk $dir/osst$nr; chmod 660 $dir/osst$nr;
mknod $dir/nosst$nr c $major $[nr+128]
chown 0.disk $dir/nosst$nr; chmod 660 $dir/nosst$nr;
mknod $dir/osst${nr}l c $major $[nr+32]
chown 0.disk $dir/osst${nr}l; chmod 660 $dir/osst${nr}l;
mknod $dir/nosst${nr}l c $major $[nr+160]
chown 0.disk $dir/nosst${nr}l; chmod 660 $dir/nosst${nr}l;
mknod $dir/osst${nr}m c $major $[nr+64]
chown 0.disk $dir/osst${nr}m; chmod 660 $dir/osst${nr}m;
mknod $dir/nosst${nr}m c $major $[nr+192]
chown 0.disk $dir/nosst${nr}m; chmod 660 $dir/nosst${nr}m;
mknod $dir/osst${nr}a c $major $[nr+96]
chown 0.disk $dir/osst${nr}a; chmod 660 $dir/osst${nr}a;
mknod $dir/nosst${nr}a c $major $[nr+224]
chown 0.disk $dir/nosst${nr}a; chmod 660 $dir/nosst${nr}a;
let nr+=1
done

14
Documentation/scsi/ppa.txt Normal file
View file

@ -0,0 +1,14 @@
-------- Terse where to get ZIP Drive help info --------
General Iomega ZIP drive page for Linux:
http://web.archive.org/web/*/http://www.torque.net/~campbell/
Driver archive for old drivers:
http://web.archive.org/web/*/http://www.torque.net/~campbell/ppa
Linux Parport page (parallel port)
http://web.archive.org/web/*/http://www.torque.net/parport/
Email list for Linux Parport
linux-parport@torque.net

78
Documentation/scsi/qlogicfas.txt Normal file
View file

@ -0,0 +1,78 @@
This driver supports the Qlogic FASXXX family of chips. This driver
only works with the ISA, VLB, and PCMCIA versions of the Qlogic
FastSCSI! cards as well as any other card based on the FASXX chip
(including the Control Concepts SCSI/IDE/SIO/PIO/FDC cards).
This driver does NOT support the PCI version. Support for these PCI
Qlogic boards:
* IQ-PCI
* IQ-PCI-10
* IQ-PCI-D
is provided by the qla1280 driver.
Nor does it support the PCI-Basic, which is supported by the
'am53c974' driver.
PCMCIA SUPPORT
This currently only works if the card is enabled first from DOS. This
means you will have to load your socket and card services, and
QL41DOS.SYS and QL40ENBL.SYS. These are a minimum, but loading the
rest of the modules won't interfere with the operation. The next
thing to do is load the kernel without resetting the hardware, which
can be a simple ctrl-alt-delete with a boot floppy, or by using
loadlin with the kernel image accessible from DOS. If you are using
the Linux PCMCIA driver, you will have to adjust it or otherwise stop
it from configuring the card.
I am working with the PCMCIA group to make it more flexible, but that
may take a while.
ALL CARDS
The top of the qlogic.c file has a number of defines that controls
configuration. As shipped, it provides a balance between speed and
function. If there are any problems, try setting SLOW_CABLE to 1, and
then try changing USE_IRQ and TURBO_PDMA to zero. If you are familiar
with SCSI, there are other settings which can tune the bus.
It may be a good idea to enable RESET_AT_START, especially if the
devices may not have been just powered up, or if you are restarting
after a crash, since they may be busy trying to complete the last
command or something. It comes up faster if this is set to zero, and
if you have reliable hardware and connections it may be more useful to
not reset things.
SOME TROUBLESHOOTING TIPS
Make sure it works properly under DOS. You should also do an initial FDISK
on a new drive if you want partitions.
Don't enable all the speedups first. If anything is wrong, they will make
any problem worse.
IMPORTANT
The best way to test if your cables, termination, etc. are good is to
copy a very big file (e.g. a doublespace container file, or a very
large executable or archive). It should be at least 5 megabytes, but
you can do multiple tests on smaller files. Then do a COMP to verify
that the file copied properly. (Turn off all caching when doing these
tests, otherwise you will test your RAM and not the files). Then do
10 COMPs, comparing the same file on the SCSI hard drive, i.e. "COMP
realbig.doc realbig.doc". Then do it after the computer gets warm.
I noticed my system which seems to work 100% would fail this test if
the computer was left on for a few hours. It was worse with longer
cables, and more devices on the SCSI bus. What seems to happen is
that it gets a false ACK causing an extra byte to be inserted into the
stream (and this is not detected). This can be caused by bad
termination (the ACK can be reflected), or by noise when the chips
work less well because of the heat, or when cables get too long for
the speed.
Remember, if it doesn't work under DOS, it probably won't work under
Linux.

180
Documentation/scsi/scsi-changer.txt Normal file
View file

@ -0,0 +1,180 @@
README for the SCSI media changer driver
========================================
This is a driver for SCSI Medium Changer devices, which are listed
with "Type: Medium Changer" in /proc/scsi/scsi.
This is for *real* Jukeboxes. It is *not* supported to work with
common small CD-ROM changers, neither one-lun-per-slot SCSI changers
nor IDE drives.
Userland tools available from here:
http://linux.bytesex.org/misc/changer.html
General Information
-------------------
First some words about how changers work: A changer has 2 (possibly
more) SCSI ID's. One for the changer device which controls the robot,
and one for the device which actually reads and writes the data. The
later may be anything, a MOD, a CD-ROM, a tape or whatever. For the
changer device this is a "don't care", he *only* shuffles around the
media, nothing else.
The SCSI changer model is complex, compared to - for example - IDE-CD
changers. But it allows to handle nearly all possible cases. It knows
4 different types of changer elements:
media transport - this one shuffles around the media, i.e. the
transport arm. Also known as "picker".
storage - a slot which can hold a media.
import/export - the same as above, but is accessible from outside,
i.e. there the operator (you !) can use this to
fill in and remove media from the changer.
Sometimes named "mailslot".
data transfer - this is the device which reads/writes, i.e. the
CD-ROM / Tape / whatever drive.
None of these is limited to one: A huge Jukebox could have slots for
123 CD-ROM's, 5 CD-ROM readers (and therefore 6 SCSI ID's: the changer
and each CD-ROM) and 2 transport arms. No problem to handle.
How it is implemented
---------------------
I implemented the driver as character device driver with a NetBSD-like
ioctl interface. Just grabbed NetBSD's header file and one of the
other linux SCSI device drivers as starting point. The interface
should be source code compatible with NetBSD. So if there is any
software (anybody knows ???) which supports a BSDish changer driver,
it should work with this driver too.
Over time a few more ioctls where added, volume tag support for example
wasn't covered by the NetBSD ioctl API.
Current State
-------------
Support for more than one transport arm is not implemented yet (and
nobody asked for it so far...).
I test and use the driver myself with a 35 slot cdrom jukebox from
Grundig. I got some reports telling it works ok with tape autoloaders
(Exabyte, HP and DEC). Some People use this driver with amanda. It
works fine with small (11 slots) and a huge (4 MOs, 88 slots)
magneto-optical Jukebox. Probably with lots of other changers too, most
(but not all :-) people mail me only if it does *not* work...
I don't have any device lists, neither black-list nor white-list. Thus
it is quite useless to ask me whenever a specific device is supported or
not. In theory every changer device which supports the SCSI-2 media
changer command set should work out-of-the-box with this driver. If it
doesn't, it is a bug. Either within the driver or within the firmware
of the changer device.
Using it
--------
This is a character device with major number is 86, so use
"mknod /dev/sch0 c 86 0" to create the special file for the driver.
If the module finds the changer, it prints some messages about the
device [ try "dmesg" if you don't see anything ] and should show up in
/proc/devices. If not.... some changers use ID ? / LUN 0 for the
device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
look for LUNs other than 0 as default, because there are too many
broken devices. So you can try:
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
(replace ID with the SCSI-ID of the device)
2) boot the kernel with "max_scsi_luns=1" on the command line
(append="max_scsi_luns=1" in lilo.conf should do the trick)
Trouble?
--------
If you insmod the driver with "insmod debug=1", it will be verbose and
prints a lot of stuff to the syslog. Compiling the kernel with
CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages a lot
because the kernel will translate the error codes into human-readable
strings then.
You can display these messages with the dmesg command (or check the
logfiles). If you email me some question because of a problem with the
driver, please include these messages.
Insmod options
--------------
debug=0/1
Enable debug messages (see above, default: 0).
verbose=0/1
Be verbose (default: 1).
init=0/1
Send INITIALIZE ELEMENT STATUS command to the changer
at insmod time (default: 1).
timeout_init=<seconds>
timeout for the INITIALIZE ELEMENT STATUS command
(default: 3600).
timeout_move=<seconds>
timeout for all other commands (default: 120).
dt_id=<id1>,<id2>,...
dt_lun=<lun1>,<lun2>,...
These two allow to specify the SCSI ID and LUN for the data
transfer elements. You likely don't need this as the jukebox
should provide this information. But some devices don't ...
vendor_firsts=
vendor_counts=
vendor_labels=
These insmod options can be used to tell the driver that there
are some vendor-specific element types. Grundig for example
does this. Some jukeboxes have a printer to label fresh burned
CDs, which is addressed as element 0xc000 (type 5). To tell the
driver about this vendor-specific element, use this:
$ insmod ch \
vendor_firsts=0xc000 \
vendor_counts=1 \
vendor_labels=printer
All three insmod options accept up to four comma-separated
values, this way you can configure the element types 5-8.
You likely need the SCSI specs for the device in question to
find the correct values as they are not covered by the SCSI-2
standard.
Credits
-------
I wrote this driver using the famous mailing-patches-around-the-world
method. With (more or less) help from:
Daniel Moehwald <moehwald@hdg.de>
Dane Jasper <dane@sonic.net>
R. Scott Bailey <sbailey@dsddi.eds.com>
Jonathan Corbet <corbet@lwn.net>
Special thanks go to
Martin Kuehne <martin.kuehne@bnbt.de>
for a old, second-hand (but full functional) cdrom jukebox which I use
to develop/test driver and tools now.
Have fun,
Gerd
--
Gerd Knorr <kraxel@bytesex.org>

101
Documentation/scsi/scsi-generic.txt Normal file
View file

@ -0,0 +1,101 @@
Notes on Linux SCSI Generic (sg) driver
---------------------------------------
20020126
Introduction
============
The SCSI Generic driver (sg) is one of the four "high level" SCSI device
drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg
is more generalized (but lower level) than its siblings and tends to be
used on SCSI devices that don't fit into the already serviced categories.
Thus sg is used for scanners, CD writers and reading audio CDs digitally
amongst other things.
Rather than document the driver's interface here, version information
is provided plus pointers (i.e. URLs) where to find documentation
and examples.
Major versions of the sg driver
===============================
There are three major versions of sg found in the linux kernel (lk):
- sg version 1 (original) from 1992 to early 1999 (lk 2.2.5) .
It is based in the sg_header interface structure.
- sg version 2 from lk 2.2.6 in the 2.2 series. It is based on
an extended version of the sg_header interface structure.
- sg version 3 found in the lk 2.4 series (and the lk 2.5 series).
It adds the sg_io_hdr interface structure.
Sg driver documentation
=======================
The most recent documentation of the sg driver is kept at the Linux
Documentation Project's (LDP) site:
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO
This describes the sg version 3 driver found in the lk 2.4 series.
The LDP renders documents in single and multiple page HTML, postscript
and pdf. This document can also be found at:
http://sg.danny.cz/sg/p/sg_v3_ho.html
Documentation for the version 2 sg driver found in the lk 2.2 series can
be found at http://sg.danny.cz/sg/. A larger version
is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt.
The original documentation for the sg driver (prior to lk 2.2.6) can be
found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt
and in the LDP archives.
A changelog with brief notes can be found in the
/usr/src/linux/include/scsi/sg.h file. Note that the glibc maintainers copy
and edit this file (removing its changelog for example) before placing it
in /usr/include/scsi/sg.h . Driver debugging information and other notes
can be found at the top of the /usr/src/linux/drivers/scsi/sg.c file.
A more general description of the Linux SCSI subsystem of which sg is a
part can be found at http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO .
Example code and utilities
==========================
There are two packages of sg utilities:
- sg3_utils for the sg version 3 driver found in lk 2.4
- sg_utils for the sg version 2 (and original) driver found in lk 2.2
and earlier
Both packages will work in the lk 2.4 series however sg3_utils offers more
capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and
freecode.com
Another approach is to look at the applications that use the sg driver.
These include cdrecord, cdparanoia, SANE and cdrdao.
Mapping of Linux kernel versions to sg driver versions
======================================================
Here is a list of linux kernels in the 2.4 series that had new version
of the sg driver:
lk 2.4.0 : sg version 3.1.17
lk 2.4.7 : sg version 3.1.19
lk 2.4.10 : sg version 3.1.20 **
lk 2.4.17 : sg version 3.1.22
** There were 3 changes to sg version 3.1.20 by third parties in the
next six linux kernel versions.
For reference here is a list of linux kernels in the 2.2 series that had
new version of the sg driver:
lk 2.2.0 : original sg version [with no version number]
lk 2.2.6 : sg version 2.1.31
lk 2.2.8 : sg version 2.1.32
lk 2.2.10 : sg version 2.1.34 [SG_GET_VERSION_NUM ioctl first appeared]
lk 2.2.14 : sg version 2.1.36
lk 2.2.16 : sg version 2.1.38
lk 2.2.17 : sg version 2.1.39
lk 2.2.20 : sg version 2.1.40
The lk 2.5 development series has recently commenced and it currently
contains sg version 3.5.23 which is functionally equivalent to sg
version 3.1.22 found in lk 2.4.17 .
Douglas Gilbert
26th January 2002
dgilbert@interlog.com

133
Documentation/scsi/scsi-parameters.txt Normal file
View file

@ -0,0 +1,133 @@
SCSI Kernel Parameters
~~~~~~~~~~~~~~~~~~~~~~
See Documentation/kernel-parameters.txt for general information on
specifying module parameters.
This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
module. Loadable modules, after being loaded into the running kernel, also
reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
parameters may be changed at runtime by the command
"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}".
advansys= [HW,SCSI]
See header of drivers/scsi/advansys.c.
aha152x= [HW,SCSI]
See Documentation/scsi/aha152x.txt.
aha1542= [HW,SCSI]
Format: <portbase>[,<buson>,<busoff>[,<dmaspeed>]]
aic7xxx= [HW,SCSI]
See Documentation/scsi/aic7xxx.txt.
aic79xx= [HW,SCSI]
See Documentation/scsi/aic79xx.txt.
atascsi= [HW,SCSI] Atari SCSI
BusLogic= [HW,SCSI]
See drivers/scsi/BusLogic.c, comment before function
BusLogic_ParseDriverOptions().
dtc3181e= [HW,SCSI]
eata= [HW,SCSI]
fdomain= [HW,SCSI]
See header of drivers/scsi/fdomain.c.
gdth= [HW,SCSI]
See header of drivers/scsi/gdth.c.
gvp11= [HW,SCSI]
in2000= [HW,SCSI]
See header of drivers/scsi/in2000.c.
ips= [HW,SCSI] Adaptec / IBM ServeRAID controller
See header of drivers/scsi/ips.c.
mac5380= [HW,SCSI] Format:
<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>
max_luns= [SCSI] Maximum number of LUNs to probe.
Should be between 1 and 2^32-1.
max_report_luns=
[SCSI] Maximum number of LUNs received.
Should be between 1 and 16384.
NCR_D700= [HW,SCSI]
See header of drivers/scsi/NCR_D700.c.
ncr5380= [HW,SCSI]
ncr53c400= [HW,SCSI]
ncr53c400a= [HW,SCSI]
ncr53c406a= [HW,SCSI]
ncr53c8xx= [HW,SCSI]
nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects.
osst= [HW,SCSI] SCSI Tape Driver
Format: <buffer_size>,<write_threshold>
See also Documentation/scsi/st.txt.
pas16= [HW,SCSI]
See header of drivers/scsi/pas16.c.
scsi_debug_*= [SCSI]
See drivers/scsi/scsi_debug.c.
scsi_default_dev_flags=
[SCSI] SCSI default device flags
Format: <integer>
scsi_dev_flags= [SCSI] Black/white list entry for vendor and model
Format: <vendor>:<model>:<flags>
(flags are integer value)
scsi_logging_level= [SCSI] a bit mask of logging levels
See drivers/scsi/scsi_logging.h for bits. Also
settable via sysctl at dev.scsi.logging_level
(/proc/sys/dev/scsi/logging_level).
There is also a nice 'scsi_logging_level' script in the
S390-tools package, available for download at
http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html
scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are
discovered. async scans them in kernel threads,
allowing boot to proceed. none ignores them, expecting
user space to do the scan.
sim710= [SCSI,HW]
See header of drivers/scsi/sim710.c.
st= [HW,SCSI] SCSI tape parameters (buffers, etc.)
See Documentation/scsi/st.txt.
sym53c416= [HW,SCSI]
See header of drivers/scsi/sym53c416.c.
t128= [HW,SCSI]
See header of drivers/scsi/t128.c.
tmscsim= [HW,SCSI]
See comment before function dc390_setup() in
drivers/scsi/tmscsim.c.
u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter
See header of drivers/scsi/u14-34f.c.
wd33c93= [HW,SCSI]
See header of drivers/scsi/wd33c93.c.
wd7000= [HW,SCSI]
See header of drivers/scsi/wd7000.c.

44
Documentation/scsi/scsi.txt Normal file
View file

@ -0,0 +1,44 @@
SCSI subsystem documentation
============================
The Linux Documentation Project (LDP) maintains a document describing
the SCSI subsystem in the Linux kernel (lk) 2.4 series. See:
http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single
and multiple page HTML renderings as well as postscript and pdf.
It can also be found at:
http://web.archive.org/web/*/http://www.torque.net/scsi/SCSI-2.4-HOWTO
Notes on using modules in the SCSI subsystem
============================================
The scsi support in the linux kernel can be modularized in a number of
different ways depending upon the needs of the end user. To understand
your options, we should first define a few terms.
The scsi-core (also known as the "mid level") contains the core of scsi
support. Without it you can do nothing with any of the other scsi drivers.
The scsi core support can be a module (scsi_mod.o), or it can be built into
the kernel. If the core is a module, it must be the first scsi module
loaded, and if you unload the modules, it will have to be the last one
unloaded. In practice the modprobe and rmmod commands (and "autoclean")
will enforce the correct ordering of loading and unloading modules in
the SCSI subsystem.
The individual upper and lower level drivers can be loaded in any order
once the scsi core is present in the kernel (either compiled in or loaded
as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o),
tape driver ** (st.o) and scsi generics driver (sg.o) represent the upper
level drivers to support the various assorted devices which can be
controlled. You can for example load the tape driver to use the tape drive,
and then unload it once you have no further need for the driver (and release
the associated memory).
The lower level drivers are the ones that support the individual cards that
are supported for the hardware platform that you are running under. Those
individual cards are often called Host Bus Adapters (HBAs). For example the
aic7xxx.o driver is used to control all recent SCSI controller cards from
Adaptec. Almost all lower level drivers can be built either as modules or
built into the kernel.
** There is a variant of the st driver for controlling OnStream tape
devices. Its module name is osst.o .

488
Documentation/scsi/scsi_eh.txt Normal file
View file

@ -0,0 +1,488 @@
SCSI EH
======================================
This document describes SCSI midlayer error handling infrastructure.
Please refer to Documentation/scsi/scsi_mid_low_api.txt for more
information regarding SCSI midlayer.
TABLE OF CONTENTS
[1] How SCSI commands travel through the midlayer and to EH
[1-1] struct scsi_cmnd
[1-2] How do scmd's get completed?
[1-2-1] Completing a scmd w/ scsi_done
[1-2-2] Completing a scmd w/ timeout
[1-3] How EH takes over
[2] How SCSI EH works
[2-1] EH through fine-grained callbacks
[2-1-1] Overview
[2-1-2] Flow of scmds through EH
[2-1-3] Flow of control
[2-2] EH through transportt->eh_strategy_handler()
[2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
[2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
[2-2-3] Things to consider
[1] How SCSI commands travel through the midlayer and to EH
[1-1] struct scsi_cmnd
Each SCSI command is represented with struct scsi_cmnd (== scmd). A
scmd has two list_head's to link itself into lists. The two are
scmd->list and scmd->eh_entry. The former is used for free list or
per-device allocated scmd list and not of much interest to this EH
discussion. The latter is used for completion and EH lists and unless
otherwise stated scmds are always linked using scmd->eh_entry in this
discussion.
[1-2] How do scmd's get completed?
Once LLDD gets hold of a scmd, either the LLDD will complete the
command by calling scsi_done callback passed from midlayer when
invoking hostt->queuecommand() or the block layer will time it out.
[1-2-1] Completing a scmd w/ scsi_done
For all non-EH commands, scsi_done() is the completion callback. It
just calls blk_complete_request() to delete the block layer timer and
raise SCSI_SOFTIRQ
SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to
determine what to do with the command. scsi_decide_disposition()
looks at the scmd->result value and sense data to determine what to do
with the command.
- SUCCESS
scsi_finish_command() is invoked for the command. The
function does some maintenance chores and then calls
scsi_io_completion() to finish the I/O.
scsi_io_completion() then notifies the block layer on
the completed request by calling blk_end_request and
friends or figures out what to do with the remainder
of the data in case of an error.
- NEEDS_RETRY
- ADD_TO_MLQUEUE
scmd is requeued to blk queue.
- otherwise
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
[1-3] for details of this function.
[1-2-2] Completing a scmd w/ timeout
The timeout handler is scsi_times_out(). When a timeout occurs, this
function
1. invokes optional hostt->eh_timed_out() callback. Return value can
be one of
- BLK_EH_HANDLED
This indicates that eh_timed_out() dealt with the timeout.
The command is passed back to the block layer and completed
via __blk_complete_requests().
*NOTE* After returning BLK_EH_HANDLED the SCSI layer is
assumed to be finished with the command, and no other
functions from the SCSI layer will be called. So this
should typically only be returned if the eh_timed_out()
handler raced with normal completion.
- BLK_EH_RESET_TIMER
This indicates that more time is required to finish the
command. Timer is restarted. This action is counted as a
retry and only allowed scmd->allowed + 1(!) times. Once the
limit is reached, action for BLK_EH_NOT_HANDLED is taken instead.
- BLK_EH_NOT_HANDLED
eh_timed_out() callback did not handle the command.
Step #2 is taken.
2. If the host supports asynchronous completion (as indicated by the
no_async_abort setting in the host template) scsi_abort_command()
is invoked to schedule an asynchrous abort. If that fails
Step #3 is taken.
2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the
command. See [1-3] for more information.
[1-3] Asynchronous command aborts
After a timeout occurs a command abort is scheduled from
scsi_abort_command(). If the abort is successful the command
will either be retried (if the number of retries is not exhausted)
or terminated with DID_TIME_OUT.
Otherwise scsi_eh_scmd_add() is invoked for the command.
See [1-4] for more information.
[1-4] How EH takes over
scmds enter EH via scsi_eh_scmd_add(), which does the following.
1. Turns on scmd->eh_eflags as requested. It's 0 for error
completions and SCSI_EH_CANCEL_CMD for timeouts.
2. Links scmd->eh_entry to shost->eh_cmd_q
3. Sets SHOST_RECOVERY bit in shost->shost_state
4. Increments shost->host_failed
5. Wakes up SCSI EH thread if shost->host_busy == shost->host_failed
As can be seen above, once any scmd is added to shost->eh_cmd_q,
SHOST_RECOVERY shost_state bit is turned on. This prevents any new
scmd to be issued from blk queue to the host; eventually, all scmds on
the host either complete normally, fail and get added to eh_cmd_q, or
time out and get added to shost->eh_cmd_q.
If all scmds either complete or fail, the number of in-flight scmds
becomes equal to the number of failed scmds - i.e. shost->host_busy ==
shost->host_failed. This wakes up SCSI EH thread. So, once woken up,
SCSI EH thread can expect that all in-flight commands have failed and
are linked on shost->eh_cmd_q.
Note that this does not mean lower layers are quiescent. If a LLDD
completed a scmd with error status, the LLDD and lower layers are
assumed to forget about the scmd at that point. However, if a scmd
has timed out, unless hostt->eh_timed_out() made lower layers forget
about the scmd, which currently no LLDD does, the command is still
active as long as lower layers are concerned and completion could
occur at any time. Of course, all such completions are ignored as the
timer has already expired.
We'll talk about how SCSI EH takes actions to abort - make LLDD
forget about - timed out scmds later.
[2] How SCSI EH works
LLDD's can implement SCSI EH actions in one of the following two
ways.
- Fine-grained EH callbacks
LLDD can implement fine-grained EH callbacks and let SCSI
midlayer drive error handling and call appropriate callbacks.
This will be discussed further in [2-1].
- eh_strategy_handler() callback
This is one big callback which should perform whole error
handling. As such, it should do all choirs SCSI midlayer
performs during recovery. This will be discussed in [2-2].
Once recovery is complete, SCSI EH resumes normal operation by
calling scsi_restart_operations(), which
1. Checks if door locking is needed and locks door.
2. Clears SHOST_RECOVERY shost_state bit
3. Wakes up waiters on shost->host_wait. This occurs if someone
calls scsi_block_when_processing_errors() on the host.
(*QUESTION* why is it needed? All operations will be blocked
anyway after it reaches blk queue.)
4. Kicks queues in all devices on the host in the asses
[2-1] EH through fine-grained callbacks
[2-1-1] Overview
If eh_strategy_handler() is not present, SCSI midlayer takes charge
of driving error handling. EH's goals are two - make LLDD, host and
device forget about timed out scmds and make them ready for new
commands. A scmd is said to be recovered if the scmd is forgotten by
lower layers and lower layers are ready to process or fail the scmd
again.
To achieve these goals, EH performs recovery actions with increasing
severity. Some actions are performed by issuing SCSI commands and
others are performed by invoking one of the following fine-grained
hostt EH callbacks. Callbacks may be omitted and omitted ones are
considered to fail always.
int (* eh_abort_handler)(struct scsi_cmnd *);
int (* eh_device_reset_handler)(struct scsi_cmnd *);
int (* eh_bus_reset_handler)(struct scsi_cmnd *);
int (* eh_host_reset_handler)(struct scsi_cmnd *);
Higher-severity actions are taken only when lower-severity actions
cannot recover some of failed scmds. Also, note that failure of the
highest-severity action means EH failure and results in offlining of
all unrecovered devices.
During recovery, the following rules are followed
- Recovery actions are performed on failed scmds on the to do list,
eh_work_q. If a recovery action succeeds for a scmd, recovered
scmds are removed from eh_work_q.
Note that single recovery action on a scmd can recover multiple
scmds. e.g. resetting a device recovers all failed scmds on the
device.
- Higher severity actions are taken iff eh_work_q is not empty after
lower severity actions are complete.
- EH reuses failed scmds to issue commands for recovery. For
timed-out scmds, SCSI EH ensures that LLDD forgets about a scmd
before reusing it for EH commands.
When a scmd is recovered, the scmd is moved from eh_work_q to EH
local eh_done_q using scsi_eh_finish_cmd(). After all scmds are
recovered (eh_work_q is empty), scsi_eh_flush_done_q() is invoked to
either retry or error-finish (notify upper layer of failure) recovered
scmds.
scmds are retried iff its sdev is still online (not offlined during
EH), REQ_FAILFAST is not set and ++scmd->retries is less than
scmd->allowed.
[2-1-2] Flow of scmds through EH
1. Error completion / time out
ACTION: scsi_eh_scmd_add() is invoked for scmd
- set scmd->eh_eflags
- add scmd to shost->eh_cmd_q
- set SHOST_RECOVERY
- shost->host_failed++
LOCKING: shost->host_lock
2. EH starts
ACTION: move all scmds to EH's local eh_work_q. shost->eh_cmd_q
is cleared.
LOCKING: shost->host_lock (not strictly necessary, just for
consistency)
3. scmd recovered
ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd
- shost->host_failed--
- clear scmd->eh_eflags
- scsi_setup_cmd_retry()
- move from local eh_work_q to local eh_done_q
LOCKING: none
4. EH completes
ACTION: scsi_eh_flush_done_q() retries scmds or notifies upper
layer of failure.
- scmd is removed from eh_done_q and scmd->eh_entry is cleared
- if retry is necessary, scmd is requeued using
scsi_queue_insert()
- otherwise, scsi_finish_command() is invoked for scmd
LOCKING: queue or finish function performs appropriate locking
[2-1-3] Flow of control
EH through fine-grained callbacks start from scsi_unjam_host().
<<scsi_unjam_host>>
1. Lock shost->host_lock, splice_init shost->eh_cmd_q into local
eh_work_q and unlock host_lock. Note that shost->eh_cmd_q is
cleared by this action.
2. Invoke scsi_eh_get_sense.
<<scsi_eh_get_sense>>
This action is taken for each error-completed
(!SCSI_EH_CANCEL_CMD) commands without valid sense data. Most
SCSI transports/LLDDs automatically acquire sense data on
command failures (autosense). Autosense is recommended for
performance reasons and as sense information could get out of
sync between occurrence of CHECK CONDITION and this action.
Note that if autosense is not supported, scmd->sense_buffer
contains invalid sense data when error-completing the scmd
with scsi_done(). scsi_decide_disposition() always returns
FAILED in such cases thus invoking SCSI EH. When the scmd
reaches here, sense data is acquired and
scsi_decide_disposition() is called again.
1. Invoke scsi_request_sense() which issues REQUEST_SENSE
command. If fails, no action. Note that taking no action
causes higher-severity recovery to be taken for the scmd.
2. Invoke scsi_decide_disposition() on the scmd
- SUCCESS
scmd->retries is set to scmd->allowed preventing
scsi_eh_flush_done_q() from retrying the scmd and
scsi_eh_finish_cmd() is invoked.
- NEEDS_RETRY
scsi_eh_finish_cmd() invoked
- otherwise
No action.
3. If !list_empty(&eh_work_q), invoke scsi_eh_abort_cmds().
<<scsi_eh_abort_cmds>>
This action is taken for each timed out command when
no_async_abort is enabled in the host template.
hostt->eh_abort_handler() is invoked for each scmd. The
handler returns SUCCESS if it has succeeded to make LLDD and
all related hardware forget about the scmd.
If a timedout scmd is successfully aborted and the sdev is
either offline or ready, scsi_eh_finish_cmd() is invoked for
the scmd. Otherwise, the scmd is left in eh_work_q for
higher-severity actions.
Note that both offline and ready status mean that the sdev is
ready to process new scmds, where processing also implies
immediate failing; thus, if a sdev is in one of the two
states, no further recovery action is needed.
Device readiness is tested using scsi_eh_tur() which issues
TEST_UNIT_READY command. Note that the scmd must have been
aborted successfully before reusing it for TEST_UNIT_READY.
4. If !list_empty(&eh_work_q), invoke scsi_eh_ready_devs()
<<scsi_eh_ready_devs>>
This function takes four increasingly more severe measures to
make failed sdevs ready for new commands.
1. Invoke scsi_eh_stu()
<<scsi_eh_stu>>
For each sdev which has failed scmds with valid sense data
of which scsi_check_sense()'s verdict is FAILED,
START_STOP_UNIT command is issued w/ start=1. Note that
as we explicitly choose error-completed scmds, it is known
that lower layers have forgotten about the scmd and we can
reuse it for STU.
If STU succeeds and the sdev is either offline or ready,
all failed scmds on the sdev are EH-finished with
scsi_eh_finish_cmd().
*NOTE* If hostt->eh_abort_handler() isn't implemented or
failed, we may still have timed out scmds at this point
and STU doesn't make lower layers forget about those
scmds. Yet, this function EH-finish all scmds on the sdev
if STU succeeds leaving lower layers in an inconsistent
state. It seems that STU action should be taken only when
a sdev has no timed out scmd.
2. If !list_empty(&eh_work_q), invoke scsi_eh_bus_device_reset().
<<scsi_eh_bus_device_reset>>
This action is very similar to scsi_eh_stu() except that,
instead of issuing STU, hostt->eh_device_reset_handler()
is used. Also, as we're not issuing SCSI commands and
resetting clears all scmds on the sdev, there is no need
to choose error-completed scmds.
3. If !list_empty(&eh_work_q), invoke scsi_eh_bus_reset()
<<scsi_eh_bus_reset>>
hostt->eh_bus_reset_handler() is invoked for each channel
with failed scmds. If bus reset succeeds, all failed
scmds on all ready or offline sdevs on the channel are
EH-finished.
4. If !list_empty(&eh_work_q), invoke scsi_eh_host_reset()
<<scsi_eh_host_reset>>
This is the last resort. hostt->eh_host_reset_handler()
is invoked. If host reset succeeds, all failed scmds on
all ready or offline sdevs on the host are EH-finished.
5. If !list_empty(&eh_work_q), invoke scsi_eh_offline_sdevs()
<<scsi_eh_offline_sdevs>>
Take all sdevs which still have unrecovered scmds offline
and EH-finish the scmds.
5. Invoke scsi_eh_flush_done_q().
<<scsi_eh_flush_done_q>>
At this point all scmds are recovered (or given up) and
put on eh_done_q by scsi_eh_finish_cmd(). This function
flushes eh_done_q by either retrying or notifying upper
layer of failure of the scmds.
[2-2] EH through transportt->eh_strategy_handler()
transportt->eh_strategy_handler() is invoked in the place of
scsi_unjam_host() and it is responsible for whole recovery process.
On completion, the handler should have made lower layers forget about
all failed scmds and either ready for new commands or offline. Also,
it should perform SCSI EH maintenance choirs to maintain integrity of
SCSI midlayer. IOW, of the steps described in [2-1-2], all steps
except for #1 must be implemented by eh_strategy_handler().
[2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
The following conditions are true on entry to the handler.
- Each failed scmd's eh_flags field is set appropriately.
- Each failed scmd is linked on scmd->eh_cmd_q by scmd->eh_entry.
- SHOST_RECOVERY is set.
- shost->host_failed == shost->host_busy
[2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
The following conditions must be true on exit from the handler.
- shost->host_failed is zero.
- Each scmd's eh_eflags field is cleared.
- Each scmd is in such a state that scsi_setup_cmd_retry() on the
scmd doesn't make any difference.
- shost->eh_cmd_q is cleared.
- Each scmd->eh_entry is cleared.
- Either scsi_queue_insert() or scsi_finish_command() is called on
each scmd. Note that the handler is free to use scmd->retries and
->allowed to limit the number of retries.
[2-2-3] Things to consider
- Know that timed out scmds are still active on lower layers. Make
lower layers forget about them before doing anything else with
those scmds.
- For consistency, when accessing/modifying shost data structure,
grab shost->host_lock.
- On completion, each failed sdev must have forgotten about all
active scmds.
- On completion, each failed sdev must be ready for new commands or
offline.
--
Tejun Heo
htejun@gmail.com
11th September 2005

496
Documentation/scsi/scsi_fc_transport.txt Normal file
View file

@ -0,0 +1,496 @@
SCSI FC Tansport
=============================================
Date: 11/18/2008
Kernel Revisions for features:
rports : <<TBS>>
vports : 2.6.22
bsg support : 2.6.30 (?TBD?)
Introduction
============
This file documents the features and components of the SCSI FC Transport.
It also provides documents the API between the transport and FC LLDDs.
The FC transport can be found at:
drivers/scsi/scsi_transport_fc.c
include/scsi/scsi_transport_fc.h
include/scsi/scsi_netlink_fc.h
include/scsi/scsi_bsg_fc.h
This file is found at Documentation/scsi/scsi_fc_transport.txt
FC Remote Ports (rports)
========================================================================
<< To Be Supplied >>
FC Virtual Ports (vports)
========================================================================
Overview:
-------------------------------
New FC standards have defined mechanisms which allows for a single physical
port to appear on as multiple communication ports. Using the N_Port Id
Virtualization (NPIV) mechanism, a point-to-point connection to a Fabric
can be assigned more than 1 N_Port_ID. Each N_Port_ID appears as a
separate port to other endpoints on the fabric, even though it shares one
physical link to the switch for communication. Each N_Port_ID can have a
unique view of the fabric based on fabric zoning and array lun-masking
(just like a normal non-NPIV adapter). Using the Virtual Fabric (VF)
mechanism, adding a fabric header to each frame allows the port to
interact with the Fabric Port to join multiple fabrics. The port will
obtain an N_Port_ID on each fabric it joins. Each fabric will have its
own unique view of endpoints and configuration parameters. NPIV may be
used together with VF so that the port can obtain multiple N_Port_IDs
on each virtual fabric.
The FC transport is now recognizing a new object - a vport. A vport is
an entity that has a world-wide unique World Wide Port Name (wwpn) and
World Wide Node Name (wwnn). The transport also allows for the FC4's to
be specified for the vport, with FCP_Initiator being the primary role
expected. Once instantiated by one of the above methods, it will have a
distinct N_Port_ID and view of fabric endpoints and storage entities.
The fc_host associated with the physical adapter will export the ability
to create vports. The transport will create the vport object within the
Linux device tree, and instruct the fc_host's driver to instantiate the
virtual port. Typically, the driver will create a new scsi_host instance
on the vport, resulting in a unique <H,C,T,L> namespace for the vport.
Thus, whether a FC port is based on a physical port or on a virtual port,
each will appear as a unique scsi_host with its own target and lun space.
Note: At this time, the transport is written to create only NPIV-based
vports. However, consideration was given to VF-based vports and it
should be a minor change to add support if needed. The remaining
discussion will concentrate on NPIV.
Note: World Wide Name assignment (and uniqueness guarantees) are left
up to an administrative entity controlling the vport. For example,
if vports are to be associated with virtual machines, a XEN mgmt
utility would be responsible for creating wwpn/wwnn's for the vport,
using its own naming authority and OUI. (Note: it already does this
for virtual MAC addresses).
Device Trees and Vport Objects:
-------------------------------
Today, the device tree typically contains the scsi_host object,
with rports and scsi target objects underneath it. Currently the FC
transport creates the vport object and places it under the scsi_host
object corresponding to the physical adapter. The LLDD will allocate
a new scsi_host for the vport and link its object under the vport.
The remainder of the tree under the vports scsi_host is the same
as the non-NPIV case. The transport is written currently to easily
allow the parent of the vport to be something other than the scsi_host.
This could be used in the future to link the object onto a vm-specific
device tree. If the vport's parent is not the physical port's scsi_host,
a symbolic link to the vport object will be placed in the physical
port's scsi_host.
Here's what to expect in the device tree :
The typical Physical Port's Scsi_Host:
/sys/devices/.../host17/
and it has the typical descendant tree:
/sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0:
and then the vport is created on the Physical Port:
/sys/devices/.../host17/vport-17:0-0
and the vport's Scsi_Host is then created:
/sys/devices/.../host17/vport-17:0-0/host18
and then the rest of the tree progresses, such as:
/sys/devices/.../host17/vport-17:0-0/host18/rport-18:0-0/target18:0:0/18:0:0:0:
Here's what to expect in the sysfs tree :
scsi_hosts:
/sys/class/scsi_host/host17 physical port's scsi_host
/sys/class/scsi_host/host18 vport's scsi_host
fc_hosts:
/sys/class/fc_host/host17 physical port's fc_host
/sys/class/fc_host/host18 vport's fc_host
fc_vports:
/sys/class/fc_vports/vport-17:0-0 the vport's fc_vport
fc_rports:
/sys/class/fc_remote_ports/rport-17:0-0 rport on the physical port
/sys/class/fc_remote_ports/rport-18:0-0 rport on the vport
Vport Attributes:
-------------------------------
The new fc_vport class object has the following attributes
node_name: Read_Only
The WWNN of the vport
port_name: Read_Only
The WWPN of the vport
roles: Read_Only
Indicates the FC4 roles enabled on the vport.
symbolic_name: Read_Write
A string, appended to the driver's symbolic port name string, which
is registered with the switch to identify the vport. For example,
a hypervisor could set this string to "Xen Domain 2 VM 5 Vport 2",
and this set of identifiers can be seen on switch management screens
to identify the port.
vport_delete: Write_Only
When written with a "1", will tear down the vport.
vport_disable: Write_Only
When written with a "1", will transition the vport to a disabled.
state. The vport will still be instantiated with the Linux kernel,
but it will not be active on the FC link.
When written with a "0", will enable the vport.
vport_last_state: Read_Only
Indicates the previous state of the vport. See the section below on
"Vport States".
vport_state: Read_Only
Indicates the state of the vport. See the section below on
"Vport States".
vport_type: Read_Only
Reflects the FC mechanism used to create the virtual port.
Only NPIV is supported currently.
For the fc_host class object, the following attributes are added for vports:
max_npiv_vports: Read_Only
Indicates the maximum number of NPIV-based vports that the
driver/adapter can support on the fc_host.
npiv_vports_inuse: Read_Only
Indicates how many NPIV-based vports have been instantiated on the
fc_host.
vport_create: Write_Only
A "simple" create interface to instantiate a vport on an fc_host.
A "<WWPN>:<WWNN>" string is written to the attribute. The transport
then instantiates the vport object and calls the LLDD to create the
vport with the role of FCP_Initiator. Each WWN is specified as 16
hex characters and may *not* contain any prefixes (e.g. 0x, x, etc).
vport_delete: Write_Only
A "simple" delete interface to teardown a vport. A "<WWPN>:<WWNN>"
string is written to the attribute. The transport will locate the
vport on the fc_host with the same WWNs and tear it down. Each WWN
is specified as 16 hex characters and may *not* contain any prefixes
(e.g. 0x, x, etc).
Vport States:
-------------------------------
Vport instantiation consists of two parts:
- Creation with the kernel and LLDD. This means all transport and
driver data structures are built up, and device objects created.
This is equivalent to a driver "attach" on an adapter, which is
independent of the adapter's link state.
- Instantiation of the vport on the FC link via ELS traffic, etc.
This is equivalent to a "link up" and successful link initialization.
Further information can be found in the interfaces section below for
Vport Creation.
Once a vport has been instantiated with the kernel/LLDD, a vport state
can be reported via the sysfs attribute. The following states exist:
FC_VPORT_UNKNOWN - Unknown
An temporary state, typically set only while the vport is being
instantiated with the kernel and LLDD.
FC_VPORT_ACTIVE - Active
The vport has been successfully been created on the FC link.
It is fully functional.
FC_VPORT_DISABLED - Disabled
The vport instantiated, but "disabled". The vport is not instantiated
on the FC link. This is equivalent to a physical port with the
link "down".
FC_VPORT_LINKDOWN - Linkdown
The vport is not operational as the physical link is not operational.
FC_VPORT_INITIALIZING - Initializing
The vport is in the process of instantiating on the FC link.
The LLDD will set this state just prior to starting the ELS traffic
to create the vport. This state will persist until the vport is
successfully created (state becomes FC_VPORT_ACTIVE) or it fails
(state is one of the values below). As this state is transitory,
it will not be preserved in the "vport_last_state".
FC_VPORT_NO_FABRIC_SUPP - No Fabric Support
The vport is not operational. One of the following conditions were
encountered:
- The FC topology is not Point-to-Point
- The FC port is not connected to an F_Port
- The F_Port has indicated that NPIV is not supported.
FC_VPORT_NO_FABRIC_RSCS - No Fabric Resources
The vport is not operational. The Fabric failed FDISC with a status
indicating that it does not have sufficient resources to complete
the operation.
FC_VPORT_FABRIC_LOGOUT - Fabric Logout
The vport is not operational. The Fabric has LOGO'd the N_Port_ID
associated with the vport.
FC_VPORT_FABRIC_REJ_WWN - Fabric Rejected WWN
The vport is not operational. The Fabric failed FDISC with a status
indicating that the WWN's are not valid.
FC_VPORT_FAILED - VPort Failed
The vport is not operational. This is a catchall for all other
error conditions.
The following state table indicates the different state transitions:
State Event New State
--------------------------------------------------------------------
n/a Initialization Unknown
Unknown: Link Down Linkdown
Link Up & Loop No Fabric Support
Link Up & no Fabric No Fabric Support
Link Up & FLOGI response No Fabric Support
indicates no NPIV support
Link Up & FDISC being sent Initializing
Disable request Disable
Linkdown: Link Up Unknown
Initializing: FDISC ACC Active
FDISC LS_RJT w/ no resources No Fabric Resources
FDISC LS_RJT w/ invalid Fabric Rejected WWN
pname or invalid nport_id
FDISC LS_RJT failed for Vport Failed
other reasons
Link Down Linkdown
Disable request Disable
Disable: Enable request Unknown
Active: LOGO received from fabric Fabric Logout
Link Down Linkdown
Disable request Disable
Fabric Logout: Link still up Unknown
The following 4 error states all have the same transitions:
No Fabric Support:
No Fabric Resources:
Fabric Rejected WWN:
Vport Failed:
Disable request Disable
Link goes down Linkdown
Transport <-> LLDD Interfaces :
-------------------------------
Vport support by LLDD:
The LLDD indicates support for vports by supplying a vport_create()
function in the transport template. The presence of this function will
cause the creation of the new attributes on the fc_host. As part of
the physical port completing its initialization relative to the
transport, it should set the max_npiv_vports attribute to indicate the
maximum number of vports the driver and/or adapter supports.
Vport Creation:
The LLDD vport_create() syntax is:
int vport_create(struct fc_vport *vport, bool disable)
where:
vport: Is the newly allocated vport object
disable: If "true", the vport is to be created in a disabled stated.
If "false", the vport is to be enabled upon creation.
When a request is made to create a new vport (via sgio/netlink, or the
vport_create fc_host attribute), the transport will validate that the LLDD
can support another vport (e.g. max_npiv_vports > npiv_vports_inuse).
If not, the create request will be failed. If space remains, the transport
will increment the vport count, create the vport object, and then call the
LLDD's vport_create() function with the newly allocated vport object.
As mentioned above, vport creation is divided into two parts:
- Creation with the kernel and LLDD. This means all transport and
driver data structures are built up, and device objects created.
This is equivalent to a driver "attach" on an adapter, which is
independent of the adapter's link state.
- Instantiation of the vport on the FC link via ELS traffic, etc.
This is equivalent to a "link up" and successful link initialization.
The LLDD's vport_create() function will not synchronously wait for both
parts to be fully completed before returning. It must validate that the
infrastructure exists to support NPIV, and complete the first part of
vport creation (data structure build up) before returning. We do not
hinge vport_create() on the link-side operation mainly because:
- The link may be down. It is not a failure if it is. It simply
means the vport is in an inoperable state until the link comes up.
This is consistent with the link bouncing post vport creation.
- The vport may be created in a disabled state.
- This is consistent with a model where: the vport equates to a
FC adapter. The vport_create is synonymous with driver attachment
to the adapter, which is independent of link state.
Note: special error codes have been defined to delineate infrastructure
failure cases for quicker resolution.
The expected behavior for the LLDD's vport_create() function is:
- Validate Infrastructure:
- If the driver or adapter cannot support another vport, whether
due to improper firmware, (a lie about) max_npiv, or a lack of
some other resource - return VPCERR_UNSUPPORTED.
- If the driver validates the WWN's against those already active on
the adapter and detects an overlap - return VPCERR_BAD_WWN.
- If the driver detects the topology is loop, non-fabric, or the
FLOGI did not support NPIV - return VPCERR_NO_FABRIC_SUPP.
- Allocate data structures. If errors are encountered, such as out
of memory conditions, return the respective negative Exxx error code.
- If the role is FCP Initiator, the LLDD is to :
- Call scsi_host_alloc() to allocate a scsi_host for the vport.
- Call scsi_add_host(new_shost, &vport->dev) to start the scsi_host
and bind it as a child of the vport device.
- Initializes the fc_host attribute values.
- Kick of further vport state transitions based on the disable flag and
link state - and return success (zero).
LLDD Implementers Notes:
- It is suggested that there be a different fc_function_templates for
the physical port and the virtual port. The physical port's template
would have the vport_create, vport_delete, and vport_disable functions,
while the vports would not.
- It is suggested that there be different scsi_host_templates
for the physical port and virtual port. Likely, there are driver
attributes, embedded into the scsi_host_template, that are applicable
for the physical port only (link speed, topology setting, etc). This
ensures that the attributes are applicable to the respective scsi_host.
Vport Disable/Enable:
The LLDD vport_disable() syntax is:
int vport_disable(struct fc_vport *vport, bool disable)
where:
vport: Is vport to be enabled or disabled
disable: If "true", the vport is to be disabled.
If "false", the vport is to be enabled.
When a request is made to change the disabled state on a vport, the
transport will validate the request against the existing vport state.
If the request is to disable and the vport is already disabled, the
request will fail. Similarly, if the request is to enable, and the
vport is not in a disabled state, the request will fail. If the request
is valid for the vport state, the transport will call the LLDD to
change the vport's state.
Within the LLDD, if a vport is disabled, it remains instantiated with
the kernel and LLDD, but it is not active or visible on the FC link in
any way. (see Vport Creation and the 2 part instantiation discussion).
The vport will remain in this state until it is deleted or re-enabled.
When enabling a vport, the LLDD reinstantiates the vport on the FC
link - essentially restarting the LLDD statemachine (see Vport States
above).
Vport Deletion:
The LLDD vport_delete() syntax is:
int vport_delete(struct fc_vport *vport)
where:
vport: Is vport to delete
When a request is made to delete a vport (via sgio/netlink, or via the
fc_host or fc_vport vport_delete attributes), the transport will call
the LLDD to terminate the vport on the FC link, and teardown all other
datastructures and references. If the LLDD completes successfully,
the transport will teardown the vport objects and complete the vport
removal. If the LLDD delete request fails, the vport object will remain,
but will be in an indeterminate state.
Within the LLDD, the normal code paths for a scsi_host teardown should
be followed. E.g. If the vport has a FCP Initiator role, the LLDD
will call fc_remove_host() for the vports scsi_host, followed by
scsi_remove_host() and scsi_host_put() for the vports scsi_host.
Other:
fc_host port_type attribute:
There is a new fc_host port_type value - FC_PORTTYPE_NPIV. This value
must be set on all vport-based fc_hosts. Normally, on a physical port,
the port_type attribute would be set to NPORT, NLPORT, etc based on the
topology type and existence of the fabric. As this is not applicable to
a vport, it makes more sense to report the FC mechanism used to create
the vport.
Driver unload:
FC drivers are required to call fc_remove_host() prior to calling
scsi_remove_host(). This allows the fc_host to tear down all remote
ports prior the scsi_host being torn down. The fc_remove_host() call
was updated to remove all vports for the fc_host as well.
Transport supplied functions
----------------------------
The following functions are supplied by the FC-transport for use by LLDs.
fc_vport_create - create a vport
fc_vport_terminate - detach and remove a vport
Details:
/**
* fc_vport_create - Admin App or LLDD requests creation of a vport
* @shost: scsi host the virtual port is connected to.
* @ids: The world wide names, FC4 port roles, etc for
* the virtual port.
*
* Notes:
* This routine assumes no locks are held on entry.
*/
struct fc_vport *
fc_vport_create(struct Scsi_Host *shost, struct fc_vport_identifiers *ids)
/**
* fc_vport_terminate - Admin App or LLDD requests termination of a vport
* @vport: fc_vport to be terminated
*
* Calls the LLDD vport_delete() function, then deallocates and removes
* the vport from the shost and object tree.
*
* Notes:
* This routine assumes no locks are held on entry.
*/
int
fc_vport_terminate(struct fc_vport *vport)
FC BSG support (CT & ELS passthru, and more)
========================================================================
<< To Be Supplied >>
Credits
=======
The following people have contributed to this document:
James Smart
james.smart@emulex.com

1441
Documentation/scsi/scsi_mid_low_api.txt Normal file
View file

File diff suppressed because it is too large Load diff

7
Documentation/scsi/scsi_transport_srp/Makefile Normal file
View file

@ -0,0 +1,7 @@
all: rport_state_diagram.svg rport_state_diagram.png
rport_state_diagram.svg: rport_state_diagram.dot
dot -Tsvg -o $@ $<
rport_state_diagram.png: rport_state_diagram.dot
dot -Tpng -o $@ $<

26
Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot Normal file
View file

@ -0,0 +1,26 @@
digraph srp_initiator {
node [shape = doublecircle]; running lost;
node [shape = circle];
{
rank = min;
running_rta [ label = "running;\nreconnect\ntimer\nactive" ];
};
running [ label = "running;\nreconnect\ntimer\nstopped" ];
blocked;
failfast [ label = "fail I/O\nfast" ];
lost;
running -> running_rta [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nsrp_start_tl_fail_timers()" ];
running_rta -> running [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting succeeded" ];
running -> blocked [ label = "fast_io_fail_tmo >= 0 or\ndev_loss_tmo >= 0;\nsrp_start_tl_fail_timers()" ];
running -> failfast [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting failed\n" ];
blocked -> failfast [ label = "fast_io_fail_tmo\nexpired or\nreconnecting\nfailed" ];
blocked -> lost [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ];
failfast -> lost [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ];
blocked -> running [ label = "reconnecting\nsucceeded" ];
failfast -> failfast [ label = "reconnecting\nfailed" ];
failfast -> running [ label = "reconnecting\nsucceeded" ];
running -> lost [ label = "srp_stop_rport_timers()" ];
running_rta -> lost [ label = "srp_stop_rport_timers()" ];
}

524
Documentation/scsi/st.txt Normal file
View file

@ -0,0 +1,524 @@
This file contains brief information about the SCSI tape driver.
The driver is currently maintained by Kai Mäkisara (email
Kai.Makisara@kolumbus.fi)
Last modified: Sun Aug 29 18:25:47 2010 by kai.makisara
BASICS
The driver is generic, i.e., it does not contain any code tailored
to any specific tape drive. The tape parameters can be specified with
one of the following three methods:
1. Each user can specify the tape parameters he/she wants to use
directly with ioctls. This is administratively a very simple and
flexible method and applicable to single-user workstations. However,
in a multiuser environment the next user finds the tape parameters in
state the previous user left them.
2. The system manager (root) can define default values for some tape
parameters, like block size and density using the MTSETDRVBUFFER ioctl.
These parameters can be programmed to come into effect either when a
new tape is loaded into the drive or if writing begins at the
beginning of the tape. The second method is applicable if the tape
drive performs auto-detection of the tape format well (like some
QIC-drives). The result is that any tape can be read, writing can be
continued using existing format, and the default format is used if
the tape is rewritten from the beginning (or a new tape is written
for the first time). The first method is applicable if the drive
does not perform auto-detection well enough and there is a single
"sensible" mode for the device. An example is a DAT drive that is
used only in variable block mode (I don't know if this is sensible
or not :-).
The user can override the parameters defined by the system
manager. The changes persist until the defaults again come into
effect.
3. By default, up to four modes can be defined and selected using the minor
number (bits 5 and 6). The number of modes can be changed by changing
ST_NBR_MODE_BITS in st.h. Mode 0 corresponds to the defaults discussed
above. Additional modes are dormant until they are defined by the
system manager (root). When specification of a new mode is started,
the configuration of mode 0 is used to provide a starting point for
definition of the new mode.
Using the modes allows the system manager to give the users choices
over some of the buffering parameters not directly accessible to the
users (buffered and asynchronous writes). The modes also allow choices
between formats in multi-tape operations (the explicitly overridden
parameters are reset when a new tape is loaded).
If more than one mode is used, all modes should contain definitions
for the same set of parameters.
Many Unices contain internal tables that associate different modes to
supported devices. The Linux SCSI tape driver does not contain such
tables (and will not do that in future). Instead of that, a utility
program can be made that fetches the inquiry data sent by the device,
scans its database, and sets up the modes using the ioctls. Another
alternative is to make a small script that uses mt to set the defaults
tailored to the system.
The driver supports fixed and variable block size (within buffer
limits). Both the auto-rewind (minor equals device number) and
non-rewind devices (minor is 128 + device number) are implemented.
In variable block mode, the byte count in write() determines the size
of the physical block on tape. When reading, the drive reads the next
tape block and returns to the user the data if the read() byte count
is at least the block size. Otherwise, error ENOMEM is returned.
In fixed block mode, the data transfer between the drive and the
driver is in multiples of the block size. The write() byte count must
be a multiple of the block size. This is not required when reading but
may be advisable for portability.
Support is provided for changing the tape partition and partitioning
of the tape with one or two partitions. By default support for
partitioned tape is disabled for each driver and it can be enabled
with the ioctl MTSETDRVBUFFER.
By default the driver writes one filemark when the device is closed after
writing and the last operation has been a write. Two filemarks can be
optionally written. In both cases end of data is signified by
returning zero bytes for two consecutive reads.
Writing filemarks without the immediate bit set in the SCSI command block acts
as a synchronization point, i.e., all remaining data form the drive buffers is
written to tape before the command returns. This makes sure that write errors
are caught at that point, but this takes time. In some applications, several
consecutive files must be written fast. The MTWEOFI operation can be used to
write the filemarks without flushing the drive buffer. Writing filemark at
close() is always flushing the drive buffers. However, if the previous
operation is MTWEOFI, close() does not write a filemark. This can be used if
the program wants to close/open the tape device between files and wants to
skip waiting.
If rewind, offline, bsf, or seek is done and previous tape operation was
write, a filemark is written before moving tape.
The compile options are defined in the file linux/drivers/scsi/st_options.h.
4. If the open option O_NONBLOCK is used, open succeeds even if the
drive is not ready. If O_NONBLOCK is not used, the driver waits for
the drive to become ready. If this does not happen in ST_BLOCK_SECONDS
seconds, open fails with the errno value EIO. With O_NONBLOCK the
device can be opened for writing even if there is a write protected
tape in the drive (commands trying to write something return error if
attempted).
MINOR NUMBERS
The tape driver currently supports up to 2^17 drives if 4 modes for
each drive are used.
The minor numbers consist of the following bit fields:
dev_upper non-rew mode dev-lower
20 - 8 7 6 5 4 0
The non-rewind bit is always bit 7 (the uppermost bit in the lowermost
byte). The bits defining the mode are below the non-rewind bit. The
remaining bits define the tape device number. This numbering is
backward compatible with the numbering used when the minor number was
only 8 bits wide.
SYSFS SUPPORT
The driver creates the directory /sys/class/scsi_tape and populates it with
directories corresponding to the existing tape devices. There are autorewind
and non-rewind entries for each mode. The names are stxy and nstxy, where x
is the tape number and y a character corresponding to the mode (none, l, m,
a). For example, the directories for the first tape device are (assuming four
modes): st0 nst0 st0l nst0l st0m nst0m st0a nst0a.
Each directory contains the entries: default_blksize default_compression
default_density defined dev device driver. The file 'defined' contains 1
if the mode is defined and zero if not defined. The files 'default_*' contain
the defaults set by the user. The value -1 means the default is not set. The
file 'dev' contains the device numbers corresponding to this device. The links
'device' and 'driver' point to the SCSI device and driver entries.
Each directory also contains the entry 'options' which shows the currently
enabled driver and mode options. The value in the file is a bit mask where the
bit definitions are the same as those used with MTSETDRVBUFFER in setting the
options.
A link named 'tape' is made from the SCSI device directory to the class
directory corresponding to the mode 0 auto-rewind device (e.g., st0).
BSD AND SYS V SEMANTICS
The user can choose between these two behaviours of the tape driver by
defining the value of the symbol ST_SYSV. The semantics differ when a
file being read is closed. The BSD semantics leaves the tape where it
currently is whereas the SYS V semantics moves the tape past the next
filemark unless the filemark has just been crossed.
The default is BSD semantics.
BUFFERING
The driver tries to do transfers directly to/from user space. If this
is not possible, a driver buffer allocated at run-time is used. If
direct i/o is not possible for the whole transfer, the driver buffer
is used (i.e., bounce buffers for individual pages are not
used). Direct i/o can be impossible because of several reasons, e.g.:
- one or more pages are at addresses not reachable by the HBA
- the number of pages in the transfer exceeds the number of
scatter/gather segments permitted by the HBA
- one or more pages can't be locked into memory (should not happen in
any reasonable situation)
The size of the driver buffers is always at least one tape block. In fixed
block mode, the minimum buffer size is defined (in 1024 byte units) by
ST_FIXED_BUFFER_BLOCKS. With small block size this allows buffering of
several blocks and using one SCSI read or write to transfer all of the
blocks. Buffering of data across write calls in fixed block mode is
allowed if ST_BUFFER_WRITES is non-zero and direct i/o is not used.
Buffer allocation uses chunks of memory having sizes 2^n * (page
size). Because of this the actual buffer size may be larger than the
minimum allowable buffer size.
NOTE that if direct i/o is used, the small writes are not buffered. This may
cause a surprise when moving from 2.4. There small writes (e.g., tar without
-b option) may have had good throughput but this is not true any more with
2.6. Direct i/o can be turned off to solve this problem but a better solution
is to use bigger write() byte counts (e.g., tar -b 64).
Asynchronous writing. Writing the buffer contents to the tape is
started and the write call returns immediately. The status is checked
at the next tape operation. Asynchronous writes are not done with
direct i/o and not in fixed block mode.
Buffered writes and asynchronous writes may in some rare cases cause
problems in multivolume operations if there is not enough space on the
tape after the early-warning mark to flush the driver buffer.
Read ahead for fixed block mode (ST_READ_AHEAD). Filling the buffer is
attempted even if the user does not want to get all of the data at
this read command. Should be disabled for those drives that don't like
a filemark to truncate a read request or that don't like backspacing.
Scatter/gather buffers (buffers that consist of chunks non-contiguous
in the physical memory) are used if contiguous buffers can't be
allocated. To support all SCSI adapters (including those not
supporting scatter/gather), buffer allocation is using the following
three kinds of chunks:
1. The initial segment that is used for all SCSI adapters including
those not supporting scatter/gather. The size of this buffer will be
(PAGE_SIZE << ST_FIRST_ORDER) bytes if the system can give a chunk of
this size (and it is not larger than the buffer size specified by
ST_BUFFER_BLOCKS). If this size is not available, the driver halves
the size and tries again until the size of one page. The default
settings in st_options.h make the driver to try to allocate all of the
buffer as one chunk.
2. The scatter/gather segments to fill the specified buffer size are
allocated so that as many segments as possible are used but the number
of segments does not exceed ST_FIRST_SG.
3. The remaining segments between ST_MAX_SG (or the module parameter
max_sg_segs) and the number of segments used in phases 1 and 2
are used to extend the buffer at run-time if this is necessary. The
number of scatter/gather segments allowed for the SCSI adapter is not
exceeded if it is smaller than the maximum number of scatter/gather
segments specified. If the maximum number allowed for the SCSI adapter
is smaller than the number of segments used in phases 1 and 2,
extending the buffer will always fail.
EOM BEHAVIOUR WHEN WRITING
When the end of medium early warning is encountered, the current write
is finished and the number of bytes is returned. The next write
returns -1 and errno is set to ENOSPC. To enable writing a trailer,
the next write is allowed to proceed and, if successful, the number of
bytes is returned. After this, -1 and the number of bytes are
alternately returned until the physical end of medium (or some other
error) is encountered.
MODULE PARAMETERS
The buffer size, write threshold, and the maximum number of allocated buffers
are configurable when the driver is loaded as a module. The keywords are:
buffer_kbs=xxx the buffer size for fixed block mode is set
to xxx kilobytes
write_threshold_kbs=xxx the write threshold in kilobytes set to xxx
max_sg_segs=xxx the maximum number of scatter/gather
segments
try_direct_io=x try direct transfer between user buffer and
tape drive if this is non-zero
Note that if the buffer size is changed but the write threshold is not
set, the write threshold is set to the new buffer size - 2 kB.
BOOT TIME CONFIGURATION
If the driver is compiled into the kernel, the same parameters can be
also set using, e.g., the LILO command line. The preferred syntax is
to use the same keyword used when loading as module but prepended
with 'st.'. For instance, to set the maximum number of scatter/gather
segments, the parameter 'st.max_sg_segs=xx' should be used (xx is the
number of scatter/gather segments).
For compatibility, the old syntax from early 2.5 and 2.4 kernel
versions is supported. The same keywords can be used as when loading
the driver as module. If several parameters are set, the keyword-value
pairs are separated with a comma (no spaces allowed). A colon can be
used instead of the equal mark. The definition is prepended by the
string st=. Here is an example:
st=buffer_kbs:64,write_threshold_kbs:60
The following syntax used by the old kernel versions is also supported:
st=aa[,bb[,dd]]
where
aa is the buffer size for fixed block mode in 1024 byte units
bb is the write threshold in 1024 byte units
dd is the maximum number of scatter/gather segments
IOCTLS
The tape is positioned and the drive parameters are set with ioctls
defined in mtio.h The tape control program 'mt' uses these ioctls. Try
to find an mt that supports all of the Linux SCSI tape ioctls and
opens the device for writing if the tape contents will be modified
(look for a package mt-st* from the Linux ftp sites; the GNU mt does
not open for writing for, e.g., erase).
The supported ioctls are:
The following use the structure mtop:
MTFSF Space forward over count filemarks. Tape positioned after filemark.
MTFSFM As above but tape positioned before filemark.
MTBSF Space backward over count filemarks. Tape positioned before
filemark.
MTBSFM As above but ape positioned after filemark.
MTFSR Space forward over count records.
MTBSR Space backward over count records.
MTFSS Space forward over count setmarks.
MTBSS Space backward over count setmarks.
MTWEOF Write count filemarks.
MTWEOFI Write count filemarks with immediate bit set (i.e., does not
wait until data is on tape)
MTWSM Write count setmarks.
MTREW Rewind tape.
MTOFFL Set device off line (often rewind plus eject).
MTNOP Do nothing except flush the buffers.
MTRETEN Re-tension tape.
MTEOM Space to end of recorded data.
MTERASE Erase tape. If the argument is zero, the short erase command
is used. The long erase command is used with all other values
of the argument.
MTSEEK Seek to tape block count. Uses Tandberg-compatible seek (QFA)
for SCSI-1 drives and SCSI-2 seek for SCSI-2 drives. The file and
block numbers in the status are not valid after a seek.
MTSETBLK Set the drive block size. Setting to zero sets the drive into
variable block mode (if applicable).
MTSETDENSITY Sets the drive density code to arg. See drive
documentation for available codes.
MTLOCK and MTUNLOCK Explicitly lock/unlock the tape drive door.
MTLOAD and MTUNLOAD Explicitly load and unload the tape. If the
command argument x is between MT_ST_HPLOADER_OFFSET + 1 and
MT_ST_HPLOADER_OFFSET + 6, the number x is used sent to the
drive with the command and it selects the tape slot to use of
HP C1553A changer.
MTCOMPRESSION Sets compressing or uncompressing drive mode using the
SCSI mode page 15. Note that some drives other methods for
control of compression. Some drives (like the Exabytes) use
density codes for compression control. Some drives use another
mode page but this page has not been implemented in the
driver. Some drives without compression capability will accept
any compression mode without error.
MTSETPART Moves the tape to the partition given by the argument at the
next tape operation. The block at which the tape is positioned
is the block where the tape was previously positioned in the
new active partition unless the next tape operation is
MTSEEK. In this case the tape is moved directly to the block
specified by MTSEEK. MTSETPART is inactive unless
MT_ST_CAN_PARTITIONS set.
MTMKPART Formats the tape with one partition (argument zero) or two
partitions (the argument gives in megabytes the size of
partition 1 that is physically the first partition of the
tape). The drive has to support partitions with size specified
by the initiator. Inactive unless MT_ST_CAN_PARTITIONS set.
MTSETDRVBUFFER
Is used for several purposes. The command is obtained from count
with mask MT_SET_OPTIONS, the low order bits are used as argument.
This command is only allowed for the superuser (root). The
subcommands are:
0
The drive buffer option is set to the argument. Zero means
no buffering.
MT_ST_BOOLEANS
Sets the buffering options. The bits are the new states
(enabled/disabled) the following options (in the
parenthesis is specified whether the option is global or
can be specified differently for each mode):
MT_ST_BUFFER_WRITES write buffering (mode)
MT_ST_ASYNC_WRITES asynchronous writes (mode)
MT_ST_READ_AHEAD read ahead (mode)
MT_ST_TWO_FM writing of two filemarks (global)
MT_ST_FAST_EOM using the SCSI spacing to EOD (global)
MT_ST_AUTO_LOCK automatic locking of the drive door (global)
MT_ST_DEF_WRITES the defaults are meant only for writes (mode)
MT_ST_CAN_BSR backspacing over more than one records can
be used for repositioning the tape (global)
MT_ST_NO_BLKLIMS the driver does not ask the block limits
from the drive (block size can be changed only to
variable) (global)
MT_ST_CAN_PARTITIONS enables support for partitioned
tapes (global)
MT_ST_SCSI2LOGICAL the logical block number is used in
the MTSEEK and MTIOCPOS for SCSI-2 drives instead of
the device dependent address. It is recommended to set
this flag unless there are tapes using the device
dependent (from the old times) (global)
MT_ST_SYSV sets the SYSV semantics (mode)
MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
the command to finish) for some commands (e.g., rewind)
MT_ST_NOWAIT_EOF enables immediate filemark mode (i.e. when
writing a filemark, don't wait for it to complete). Please
see the BASICS note about MTWEOFI with respect to the
possible dangers of writing immediate filemarks.
MT_ST_SILI enables setting the SILI bit in SCSI commands when
reading in variable block mode to enhance performance when
reading blocks shorter than the byte count; set this only
if you are sure that the drive supports SILI and the HBA
correctly returns transfer residuals
MT_ST_DEBUGGING debugging (global; debugging must be
compiled into the driver)
MT_ST_SETBOOLEANS
MT_ST_CLEARBOOLEANS
Sets or clears the option bits.
MT_ST_WRITE_THRESHOLD
Sets the write threshold for this device to kilobytes
specified by the lowest bits.
MT_ST_DEF_BLKSIZE
Defines the default block size set automatically. Value
0xffffff means that the default is not used any more.
MT_ST_DEF_DENSITY
MT_ST_DEF_DRVBUFFER
Used to set or clear the density (8 bits), and drive buffer
state (3 bits). If the value is MT_ST_CLEAR_DEFAULT
(0xfffff) the default will not be used any more. Otherwise
the lowermost bits of the value contain the new value of
the parameter.
MT_ST_DEF_COMPRESSION
The compression default will not be used if the value of
the lowermost byte is 0xff. Otherwise the lowermost bit
contains the new default. If the bits 8-15 are set to a
non-zero number, and this number is not 0xff, the number is
used as the compression algorithm. The value
MT_ST_CLEAR_DEFAULT can be used to clear the compression
default.
MT_ST_SET_TIMEOUT
Set the normal timeout in seconds for this device. The
default is 900 seconds (15 minutes). The timeout should be
long enough for the retries done by the device while
reading/writing.
MT_ST_SET_LONG_TIMEOUT
Set the long timeout that is used for operations that are
known to take a long time. The default is 14000 seconds
(3.9 hours). For erase this value is further multiplied by
eight.
MT_ST_SET_CLN
Set the cleaning request interpretation parameters using
the lowest 24 bits of the argument. The driver can set the
generic status bit GMT_CLN if a cleaning request bit pattern
is found from the extended sense data. Many drives set one or
more bits in the extended sense data when the drive needs
cleaning. The bits are device-dependent. The driver is
given the number of the sense data byte (the lowest eight
bits of the argument; must be >= 18 (values 1 - 17
reserved) and <= the maximum requested sense data sixe),
a mask to select the relevant bits (the bits 9-16), and the
bit pattern (bits 17-23). If the bit pattern is zero, one
or more bits under the mask indicate cleaning request. If
the pattern is non-zero, the pattern must match the masked
sense data byte.
(The cleaning bit is set if the additional sense code and
qualifier 00h 17h are seen regardless of the setting of
MT_ST_SET_CLN.)
The following ioctl uses the structure mtpos:
MTIOCPOS Reads the current position from the drive. Uses
Tandberg-compatible QFA for SCSI-1 drives and the SCSI-2
command for the SCSI-2 drives.
The following ioctl uses the structure mtget to return the status:
MTIOCGET Returns some status information.
The file number and block number within file are returned. The
block is -1 when it can't be determined (e.g., after MTBSF).
The drive type is either MTISSCSI1 or MTISSCSI2.
The number of recovered errors since the previous status call
is stored in the lower word of the field mt_erreg.
The current block size and the density code are stored in the field
mt_dsreg (shifts for the subfields are MT_ST_BLKSIZE_SHIFT and
MT_ST_DENSITY_SHIFT).
The GMT_xxx status bits reflect the drive status. GMT_DR_OPEN
is set if there is no tape in the drive. GMT_EOD means either
end of recorded data or end of tape. GMT_EOT means end of tape.
MISCELLANEOUS COMPILE OPTIONS
The recovered write errors are considered fatal if ST_RECOVERED_WRITE_FATAL
is defined.
The maximum number of tape devices is determined by the define
ST_MAX_TAPES. If more tapes are detected at driver initialization, the
maximum is adjusted accordingly.
Immediate return from tape positioning SCSI commands can be enabled by
defining ST_NOWAIT. If this is defined, the user should take care that
the next tape operation is not started before the previous one has
finished. The drives and SCSI adapters should handle this condition
gracefully, but some drive/adapter combinations are known to hang the
SCSI bus in this case.
The MTEOM command is by default implemented as spacing over 32767
filemarks. With this method the file number in the status is
correct. The user can request using direct spacing to EOD by setting
ST_FAST_EOM 1 (or using the MT_ST_OPTIONS ioctl). In this case the file
number will be invalid.
When using read ahead or buffered writes the position within the file
may not be correct after the file is closed (correct position may
require backspacing over more than one record). The correct position
within file can be obtained if ST_IN_FILE_POS is defined at compile
time or the MT_ST_CAN_BSR bit is set for the drive with an ioctl.
(The driver always backs over a filemark crossed by read ahead if the
user does not request data that far.)
DEBUGGING HINTS
To enable debugging messages, edit st.c and #define DEBUG 1. As seen
above, debugging can be switched off with an ioctl if debugging is
compiled into the driver. The debugging output is not voluminous.
If the tape seems to hang, I would be very interested to hear where
the driver is waiting. With the command 'ps -l' you can see the state
of the process using the tape. If the state is D, the process is
waiting for something. The field WCHAN tells where the driver is
waiting. If you have the current System.map in the correct place (in
/boot for the procps I use) or have updated /etc/psdatabase (for kmem
ps), ps writes the function name in the WCHAN field. If not, you have
to look up the function from System.map.
Note also that the timeouts are very long compared to most other
drivers. This means that the Linux driver may appear hung although the
real reason is that the tape firmware has got confused.

23
Documentation/scsi/sym53c500_cs.txt Normal file
View file

@ -0,0 +1,23 @@
The sym53c500_cs driver originated as an add-on to David Hinds' pcmcia-cs
package, and was written by Tom Corner (tcorner@via.at). A rewrite was
long overdue, and the current version addresses the following concerns:
(1) extensive kernel changes between 2.4 and 2.6.
(2) deprecated PCMCIA support outside the kernel.
All the USE_BIOS code has been ripped out. It was never used, and could
not have worked anyway. The USE_DMA code is likewise gone. Many thanks
to YOKOTA Hiroshi (nsp_cs driver) and David Hinds (qlogic_cs driver) for
the code fragments I shamelessly adapted for this work. Thanks also to
Christoph Hellwig for his patient tutelage while I stumbled about.
The Symbios Logic 53c500 chip was used in the "newer" (circa 1997) version
of the New Media Bus Toaster PCMCIA SCSI controller. Presumably there are
other products using this chip, but I've never laid eyes (much less hands)
on one.
Through the years, there have been a number of downloads of the pcmcia-cs
version of this driver, and I guess it worked for those users. It worked
for Tom Corner, and it works for me. Your mileage will probably vary.
--Bob Tracy (rct@frus.com)

1048
Documentation/scsi/sym53c8xx_2.txt Normal file
View file

File diff suppressed because it is too large Load diff

447
Documentation/scsi/tmscsim.txt Normal file
View file

@ -0,0 +1,447 @@
The tmscsim driver
==================
1. Purpose and history
2. Installation
3. Features
4. Configuration via /proc/scsi/tmscsim/?
5. Configuration via boot/module params
6. Potential improvements
7. Bug reports, debugging and updates
8. Acknowledgements
9. Copyright
1. Purpose and history
----------------------
The tmscsim driver supports PCI SCSI Host Adapters based on the AM53C974
chip. AM53C974 based SCSI adapters include:
Tekram DC390, DC390T
Dawicontrol 2974
QLogic Fast! PCI Basic
some on-board adapters
(This is most probably not a complete list)
It has originally written by C.L. Huang from the Tekram corp. to support the
Tekram DC390(T) adapter. This is where the name comes from: tm = Tekram
scsi = SCSI driver, m = AMD (?) as opposed to w for the DC390W/U/F
(NCR53c8X5, X=2/7) driver. Yes, there was also a driver for the latter,
tmscsiw, which supported DC390W/U/F adapters. It's not maintained any more,
as the ncr53c8xx is perfectly supporting these adapters since some time.
The driver first appeared in April 1996, exclusively supported the DC390
and has been enhanced since then in various steps. In May 1998 support for
general AM53C974 based adapters and some possibilities to configure it were
added. The non-DC390 support works by assuming some values for the data
normally taken from the DC390 EEPROM. See below (chapter 5) for details.
When using the DC390, the configuration is still be done using the DC390
BIOS setup. The DC390 EEPROM is read and used by the driver, any boot or
module parameters (chapter 5) are ignored! However, you can change settings
dynamically, as described in chapter 4.
For a more detailed description of the driver's history, see the first lines
of tmscsim.c.
The numbering scheme isn't consistent. The first versions went from 1.00 to
1.12, then 1.20a to 1.20t. Finally I decided to use the ncr53c8xx scheme. So
the next revisions will be 2.0a to 2.0X (stable), 2.1a to 2.1X (experimental),
2.2a to 2.2X (stable, again) etc. (X = anything between a and z.) If I send
fixes to people for testing, I create intermediate versions with a digit
appended, e.g. 2.0c3.
2. Installation
---------------
If you got any recent kernel with this driver and document included in
linux/drivers/scsi, you basically have to do nothing special to use this
driver. Of course you have to choose to compile SCSI support and DC390(T)
support into your kernel or as module when configuring your kernel for
compiling.
NEW: You may as well compile this module outside your kernel, using the
supplied Makefile.
If you got an old kernel (pre 2.1.127, pre 2.0.37p1) with an old version of
this driver: Get dc390-21125-20b.diff.gz or dc390-2036p21-20b1.diff.gz from
my web page and apply the patch. Apply further patches to upgrade to the
latest version of the driver.
If you want to do it manually, you should copy the files (dc390.h,
tmscsim.h, tmscsim.c, scsiiom.c and README.tmscsim) from this directory to
linux/drivers/scsi. You have to recompile your kernel/module of course.
You should apply the three patches included in dc390-120-kernel.diff
(Applying them: cd /usr/src; patch -p0 <~/dc390-120-kernel.diff)
The patches are against 2.1.125, so you might have to manually resolve
rejections when applying to another kernel version.
The patches will update the kernel startup code to allow boot parameters to
be passed to the driver, update the Documentation and finally offer you the
possibility to omit the non-DC390 parts of the driver.
(By selecting "Omit support for non DC390" you basically disable the
emulation of a DC390 EEPROM for non DC390 adapters. This saves a few bytes
of memory.)
If you got a very old kernel without the tmscsim driver (pre 2.0.31)
I recommend upgrading your kernel. However, if you don't want to, please
contact me to get the appropriate patches.
Upgrading a SCSI driver is always a delicate thing to do. The 2.0 driver has
proven stable on many systems, but it's still a good idea to take some
precautions. In an ideal world you would have a full backup of your disks.
The world isn't ideal and most people don't have full backups (me neither).
So take at least the following measures:
* make your kernel remount the FS read-only on detecting an error:
tune2fs -e remount-ro /dev/sd??
* have copies of your SCSI disk's partition tables on some safe location:
dd if=/dev/sda of=/mnt/floppy/sda bs=512 count=1
or just print it with:
fdisk -l | lpr
* make sure you are able to boot Linux (e.g. from floppy disk using InitRD)
if your SCSI disk gets corrupted. You can use
ftp://student.physik.uni-dortmund.de/pub/linux/kernel/bootdisk.gz
One more warning: I used to overclock my PCI bus to 41.67 MHz. My Tekram
DC390F (Sym53c875) accepted this as well as my Millennium. But the Am53C974
produced errors and started to corrupt my disks. So don't do that! A 37.50
MHz PCI bus works for me, though, but I don't recommend using higher clocks
than the 33.33 MHz being in the PCI spec.
If you want to share the IRQ with another device and the driver refuses to
do so, you might succeed with changing the DC390_IRQ type in tmscsim.c to
IRQF_SHARED | IRQF_DISABLED.
3.Features
----------
- SCSI
* Tagged command queueing
* Sync speed up to 10 MHz
* Disconnection
* Multiple LUNs
- General / Linux interface
* Support for up to 4 AM53C974 adapters.
* DC390 EEPROM usage or boot/module params
* Information via cat /proc/scsi/tmscsim/?
* Dynamically configurable by writing to /proc/scsi/tmscsim/?
* Dynamic allocation of resources
* SMP support: Locking on io_request lock (Linux 2.1/2.2) or adapter
specific locks (Linux 2.5?)
* Uniform source code for Linux-2.x.y
* Support for dyn. addition/removal of devices via add/remove-single-device
(Try: echo "scsi add-single-device C B T U" >/proc/scsi/scsi
C = Controller, B = Bus, T = Target SCSI ID, U = Unit SCSI LUN.)
Use with care!
* Try to use the partition table for the determination of the mapping
4. Configuration via /proc/scsi/tmscsim/?
-----------------------------------------
First of all look at the output of /proc/scsi/tmscsim/? by typing
cat /proc/scsi/tmscsim/?
The "?" should be replaced by the SCSI host number. (The shell might do this
for you.)
You will see some info regarding the adapter and, at the end, a listing of
the attached devices and their settings.
Here's an example:
garloff@kurt:/home/garloff > cat /proc/scsi/tmscsim/0
Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0e7 2000-11-28
SCSI Host Nr 1, AM53C974 Adapter Nr 0
IOPortBase 0xb000, IRQ 10
MaxID 8, MaxLUN 8, AdapterID 6, SelTimeout 250 ms, DelayReset 1 s
TagMaxNum 16, Status 0x00, ACBFlag 0x00, GlitchEater 24 ns
Statistics: Cmnds 1470165, Cmnds not sent directly 0, Out of SRB conds 0
Lost arbitrations 587, Sel. connected 0, Connected: No
Nr of attached devices: 4, Nr of DCBs: 4
Map of attached LUNs: 01 00 00 03 01 00 00 00
Idx ID LUN Prty Sync DsCn SndS TagQ NegoPeriod SyncSpeed SyncOffs MaxCmd
00 00 00 Yes Yes Yes Yes Yes 100 ns 10.0 M 15 16
01 03 00 Yes Yes Yes Yes No 100 ns 10.0 M 15 01
02 03 01 Yes Yes Yes Yes No 100 ns 10.0 M 15 01
03 04 00 Yes Yes Yes Yes No 100 ns 10.0 M 15 01
Note that the settings MaxID and MaxLUN are not zero- but one-based, which
means that a setting MaxLUN=4, will result in the support of LUNs 0..3. This
is somehow inconvenient, but the way the mid-level SCSI code expects it to be.
ACB and DCB are acronyms for Adapter Control Block and Device Control Block.
These are data structures of the driver containing information about the
adapter and the connected SCSI devices respectively.
Idx is the device index (just a consecutive number for the driver), ID and
LUN are the SCSI ID and LUN, Prty means Parity checking, Sync synchronous
negotiation, DsCn Disconnection, SndS Send Start command on startup (not
used by the driver) and TagQ Tagged Command Queueing. NegoPeriod and
SyncSpeed are somehow redundant, because they are reciprocal values
(1 / 112 ns = 8.9 MHz). At least in theory. The driver is able to adjust the
NegoPeriod more accurate (4ns) than the SyncSpeed (1 / 25ns). I don't know
if certain devices will have problems with this discrepancy. Max. speed is
10 MHz corresp. to a min. NegoPeriod of 100 ns.
(The driver allows slightly higher speeds if the devices (Ultra SCSI) accept
it, but that's out of adapter spec, on your own risk and unlikely to improve
performance. You're likely to crash your disks.)
SyncOffs is the offset used for synchronous negotiations; max. is 15.
The last values are only shown, if Sync is enabled. (NegoPeriod is still
displayed in brackets to show the values which will be used after enabling
Sync.)
MaxCmd ist the number of commands (=tags) which can be processed at the same
time by the device.
If you want to change a setting, you can do that by writing to
/proc/scsi/tmscsim/?. Basically you have to imitate the output of driver.
(Don't use the brackets for NegoPeriod on Sync disabled devices.)
You don't have to care about capitalisation. The driver will accept space,
tab, comma, = and : as separators.
There are three kinds of changes:
(1) Change driver settings:
You type the names of the parameters and the params following it.
Example:
echo "MaxLUN=8 seltimeout 200" >/proc/scsi/tmscsim/0
Note that you can only change MaxID, MaxLUN, AdapterID, SelTimeOut,
TagMaxNum, ACBFlag, GlitchEater and DelayReset. Don't change ACBFlag
unless you want to see what happens, if the driver hangs.
(2) Change device settings: You write a config line to the driver. The Nr
must match the ID and LUN given. If you give "-" as parameter, it is
ignored and the corresponding setting won't be changed.
You can use "y" or "n" instead of "Yes" and "No" if you want to.
You don't need to specify a full line. The driver automatically performs
an INQUIRY on the device if necessary to check if it is capable to operate
with the given settings (Sync, TagQ).
Examples:
echo "0 0 0 y y y - y - 10 " >/proc/scsi/tmscsim/0
echo "3 5 0 y n y " >/proc/scsi/tmscsim/0
To give a short explanation of the first example:
The first three numbers, "0 0 0" (Device index 0, SCSI ID 0, SCSI LUN 0),
select the device to which the following parameters apply. Note that it
would be sufficient to use the index or both SCSI ID and LUN, but I chose
to require all three to have a syntax similar to the output.
The following "y y y - y" enables Parity checking, enables Synchronous
transfers, Disconnection, leaves Send Start (not used) untouched and
enables Tagged Command Queueing for the selected device. The "-" skips
the Negotiation Period setting but the "10" sets the max sync. speed to
10 MHz. It's useless to specify both NegoPeriod and SyncSpeed as
discussed above. The values used in this example will result in maximum
performance.
(3) Special commands: You can force a SCSI bus reset, an INQUIRY command, the
removal or the addition of a device's DCB and a SCSI register dump.
This is only used for debugging when you meet problems. The parameter of
the INQUIRY and REMOVE commands is the device index as shown by the
output of /proc/scsi/tmscsim/? in the device listing in the first column
(Idx). ADD takes the SCSI ID and LUN.
Examples:
echo "reset" >/proc/scsi/tmscsim/0
echo "inquiry 1" >/proc/scsi/tmscsim/0
echo "remove 2" >/proc/scsi/tmscsim/1
echo "add 2 3" >/proc/scsi/tmscsim/?
echo "dump" >/proc/scsi/tmscsim/0
Note that you will meet problems when you REMOVE a device's DCB with the
remove command if it contains partitions which are mounted. Only use it
after unmounting its partitions, telling the SCSI mid-level code to
remove it (scsi remove-single-device) and you really need a few bytes of
memory.
The ADD command allows you to configure a device before you tell the
mid-level code to try detection.
I'd suggest reviewing the output of /proc/scsi/tmscsim/? after changing
settings to see if everything changed as requested.
5. Configuration via boot/module parameters
-------------------------------------------
With the DC390, the driver reads its EEPROM settings and tries to use them.
But you may want to override the settings prior to being able to change the
driver configuration via /proc/scsi/tmscsim/?.
If you do have another AM53C974 based adapter, that's even the only
possibility to adjust settings before you are able to write to the
/proc/scsi/tmscsim/? pseudo-file, e.g. if you want to use another
adapter ID than 7.
(BTW, the log message "DC390: No EEPROM found!" is normal without a DC390.)
For this purpose, you can pass options to the driver before it is initialised
by using kernel or module parameters. See lilo(8) or modprobe(1) manual
pages on how to pass params to the kernel or a module.
[NOTE: Formerly, it was not possible to override the EEPROM supplied
settings of the DC390 with cmd line parameters. This has changed since
2.0e7]
The syntax of the params is much shorter than the syntax of the /proc/...
interface. This makes it a little bit more difficult to use. However, long
parameter lines have the risk to be misinterpreted and the length of kernel
parameters is limited.
As the support for non-DC390 adapters works by simulating the values of the
DC390 EEPROM, the settings are given in a DC390 BIOS' way.
Here's the syntax:
tmscsim=AdaptID,SpdIdx,DevMode,AdaptMode,TaggedCmnds,DelayReset
Each of the parameters is a number, containing the described information:
* AdaptID: The SCSI ID of the host adapter. Must be in the range 0..7
Default is 7.
* SpdIdx: The index of the maximum speed as in the DC390 BIOS. The values
0..7 mean 10, 8.0, 6.7, 5.7, 5.0, 4.0, 3.1 and 2 MHz resp. Default is
0 (10.0 MHz).
* DevMode is a bit mapped value describing the per-device features. It
applies to all devices. (Sync, Disc and TagQ will only apply, if the
device supports it.) The meaning of the bits (* = default):
Bit Val(hex) Val(dec) Meaning
*0 0x01 1 Parity check
*1 0x02 2 Synchronous Negotiation
*2 0x04 4 Disconnection
*3 0x08 8 Send Start command on startup. (Not used)
*4 0x10 16 Tagged Command Queueing
As usual, the desired value is obtained by adding the wanted values. If
you want to enable all values, e.g., you would use 31(0x1f). Default is 31.
* AdaptMode is a bit mapped value describing the enabled adapter features.
Bit Val(hex) Val(dec) Meaning
*0 0x01 1 Support more than two drives. (Not used)
*1 0x02 2 Use DOS compatible mapping for HDs greater than 1GB.
*2 0x04 4 Reset SCSI Bus on startup.
*3 0x08 8 Active Negation: Improves SCSI Bus noise immunity.
4 0x10 16 Immediate return on BIOS seek command. (Not used)
(*)5 0x20 32 Check for LUNs >= 1.
* TaggedCmnds is a number indicating the maximum number of Tagged Commands.
It is the binary logarithm - 1 of the actual number. Max is 4 (32).
Value Number of Tagged Commands
0 2
1 4
2 8
*3 16
4 32
* DelayReset is the time in seconds (minus 0.5s), the adapter waits, after a
bus reset. Default is 1 (corresp. to 1.5s).
Example:
modprobe tmscsim tmscsim=6,2,31
would set the adapter ID to 6, max. speed to 6.7 MHz, enable all device
features and leave the adapter features, the number of Tagged Commands
and the Delay after a reset to the defaults.
As you can see, you don't need to specify all of the six params.
If you want values to be ignored (i.e. the EEprom settings or the defaults
will be used), you may pass -2 (not 0!) at the corresponding position.
The defaults (7,0,31,15,3,1) are aggressive to allow good performance. You
can use tmscsim=7,0,31,63,4,0 for maximum performance, if your SCSI chain
allows it. If you meet problems, you can use tmscsim=-1 which is a shortcut
for tmscsim=7,4,9,15,2,10.
6. Potential improvements
-------------------------
Most of the intended work on the driver has been done. Here are a few ideas
to further improve its usability:
* Cleanly separate per-Target and per-LUN properties (DCB)
* More intelligent abort() routine
* Use new_eh code (Linux-2.1+)
* Have the mid-level (ML) code (and not the driver) handle more of the
various conditions.
* Command queueing in the driver: Eliminate Query list and use ML instead.
* More user friendly boot/module param syntax
Further investigation on these problems:
* Driver hangs with sync readcdda (xcdroast) (most probably VIA PCI error)
Known problems:
Please see http://www.garloff.de/kurt/linux/dc390/problems.html
* Changing the parameters of multi-lun by the tmscsim/? interface will
cause problems, cause these settings are mostly per Target and not per LUN
and should be updated accordingly. To be fixed for 2.0d24.
* CDRs (eg Yam CRW4416) not recognized, because some buggy devices don't
recover from a SCSI reset in time. Use a higher delay or don't issue
a SCSI bus reset on driver initialization. See problems page.
For the CRW4416S, this seems to be solved with firmware 1.0g (reported by
Jean-Yves Barbier).
* TEAC CD-532S not being recognized. (Works with 1.11).
* Scanners (eg. Astra UMAX 1220S) don't work: Disable Sync Negotiation.
If this does not help, try echo "INQUIRY t" >/proc/scsi/tmscsim/? (t
replaced by the dev index of your scanner). You may try to reset your SCSI
bus afterwards (echo "RESET" >/proc/scsi/tmscsim/?).
The problem seems to be solved as of 2.0d18, thanks to Andreas Rick.
* If there is a valid partition table, the driver will use it for determining
the mapping. If there's none, a reasonable mapping (Symbios-like) will be
assumed. Other operating systems may not like this mapping, though
it's consistent with the BIOS' behaviour. Old DC390 drivers ignored the
partition table and used a H/S = 64/32 or 255/63 translation. So if you
want to be compatible to those, use this old mapping when creating
partition tables. Even worse, on bootup the DC390 might complain if other
mappings are found, so auto rebooting may fail.
* In some situations, the driver will get stuck in an abort loop. This is a
bad interaction between the Mid-Layer of Linux' SCSI code and the driver.
Try to disable DsCn, if you meet this problem. Please contact me for
further debugging.
7. Bug reports, debugging and updates
-------------------------------------
Whenever you have problems with the driver, you are invited to ask the
author for help. However, I'd suggest reading the docs and trying to solve
the problem yourself, first.
If you find something, which you believe to be a bug, please report it to me.
Please append the output of /proc/scsi/scsi, /proc/scsi/tmscsim/? and
maybe the DC390 log messages to the report.
Bug reports should be send to me (Kurt Garloff <dc390@garloff.de>) as well
as to the linux-scsi list (<linux-scsi@vger.kernel.org>), as sometimes bugs
are caused by the SCSI mid-level code.
I will ask you for some more details and probably I will also ask you to
enable some of the DEBUG options in the driver (tmscsim.c:DC390_DEBUGXXX
defines). The driver will produce some data for the syslog facility then.
Beware: If your syslog gets written to a SCSI disk connected to your
AM53C974, the logging might produce log output again, and you might end
having your box spending most of its time doing the logging.
The latest version of the driver can be found at:
http://www.garloff.de/kurt/linux/dc390/
ftp://ftp.suse.com/pub/people/garloff/linux/dc390/
8. Acknowledgements
-------------------
Thanks to Linus Torvalds, Alan Cox, the FSF people, the XFree86 team and
all the others for the wonderful OS and software.
Thanks to C.L. Huang and Philip Giang (Tekram) for the initial driver
release and support.
Thanks to Doug Ledford, Gérard Roudier for support with SCSI coding.
Thanks to a lot of people (espec. Chiaki Ishikawa, Andreas Haumer, Hubert
Tonneau) for intensively testing the driver (and even risking data loss
doing this during early revisions).
Recently, SuSE GmbH, Nuernberg, FRG, has been paying me for the driver
development and maintenance. Special thanks!
9. Copyright
------------
This driver is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
If you want to use any later version of the GNU GPL, you will probably
be allowed to, but you have to ask me and Tekram <erich@tekram.com.tw>
before.
-------------------------------------------------------------------------
Written by Kurt Garloff <kurt@garloff.de> 1998/06/11
Last updated 2000/11/28, driver revision 2.0e7
$Id: README.tmscsim,v 2.25.2.7 2000/12/20 01:07:12 garloff Exp $

133
Documentation/scsi/ufs.txt Normal file
View file

@ -0,0 +1,133 @@
Universal Flash Storage
=======================
Contents
--------
1. Overview
2. UFS Architecture Overview
2.1 Application Layer
2.2 UFS Transport Protocol(UTP) layer
2.3 UFS Interconnect(UIC) Layer
3. UFSHCD Overview
3.1 UFS controller initialization
3.2 UTP Transfer requests
3.3 UFS error handling
3.4 SCSI Error handling
1. Overview
-----------
Universal Flash Storage(UFS) is a storage specification for flash devices.
It is aimed to provide a universal storage interface for both
embedded and removable flash memory based storage in mobile
devices such as smart phones and tablet computers. The specification
is defined by JEDEC Solid State Technology Association. UFS is based
on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the
physical layer and MIPI Unipro as the link layer.
The main goals of UFS is to provide,
* Optimized performance:
For UFS version 1.0 and 1.1 the target performance is as follows,
Support for Gear1 is mandatory (rate A: 1248Mbps, rate B: 1457.6Mbps)
Support for Gear2 is optional (rate A: 2496Mbps, rate B: 2915.2Mbps)
Future version of the standard,
Gear3 (rate A: 4992Mbps, rate B: 5830.4Mbps)
* Low power consumption
* High random IOPs and low latency
2. UFS Architecture Overview
----------------------------
UFS has a layered communication architecture which is based on SCSI
SAM-5 architectural model.
UFS communication architecture consists of following layers,
2.1 Application Layer
The Application layer is composed of UFS command set layer(UCS),
Task Manager and Device manager. The UFS interface is designed to be
protocol agnostic, however SCSI has been selected as a baseline
protocol for versions 1.0 and 1.1 of UFS protocol layer.
UFS supports subset of SCSI commands defined by SPC-4 and SBC-3.
* UCS: It handles SCSI commands supported by UFS specification.
* Task manager: It handles task management functions defined by the
UFS which are meant for command queue control.
* Device manager: It handles device level operations and device
configuration operations. Device level operations mainly involve
device power management operations and commands to Interconnect
layers. Device level configurations involve handling of query
requests which are used to modify and retrieve configuration
information of the device.
2.2 UFS Transport Protocol(UTP) layer
UTP layer provides services for
the higher layers through Service Access Points. UTP defines 3
service access points for higher layers.
* UDM_SAP: Device manager service access point is exposed to device
manager for device level operations. These device level operations
are done through query requests.
* UTP_CMD_SAP: Command service access point is exposed to UFS command
set layer(UCS) to transport commands.
* UTP_TM_SAP: Task management service access point is exposed to task
manager to transport task management functions.
UTP transports messages through UFS protocol information unit(UPIU).
2.3 UFS Interconnect(UIC) Layer
UIC is the lowest layer of UFS layered architecture. It handles
connection between UFS host and UFS device. UIC consists of
MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points
to upper layer,
* UIC_SAP: To transport UPIU between UFS host and UFS device.
* UIO_SAP: To issue commands to Unipro layers.
3. UFSHCD Overview
------------------
The UFS host controller driver is based on Linux SCSI Framework.
UFSHCD is a low level device driver which acts as an interface between
SCSI Midlayer and PCIe based UFS host controllers.
The current UFSHCD implementation supports following functionality,
3.1 UFS controller initialization
The initialization module brings UFS host controller to active state
and prepares the controller to transfer commands/response between
UFSHCD and UFS device.
3.2 UTP Transfer requests
Transfer request handling module of UFSHCD receives SCSI commands
from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host
controller. Also, the module decodes, responses received from UFS
host controller in the form of UPIUs and intimates the SCSI Midlayer
of the status of the command.
3.3 UFS error handling
Error handling module handles Host controller fatal errors,
Device fatal errors and UIC interconnect layer related errors.
3.4 SCSI Error handling
This is done through UFSHCD SCSI error handling routines registered
with SCSI Midlayer. Examples of some of the error handling commands
issues by SCSI Midlayer are Abort task, Lun reset and host reset.
UFSHCD Routines to perform these tasks are registered with
SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and
.eh_host_reset_handler.
In this version of UFSHCD Query requests and power management
functionality are not implemented.
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf