diff options
Diffstat (limited to 'Documentation/scsi')
33 files changed, 1315 insertions, 2108 deletions
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index c2e18e10985..c4b978a72f7 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -28,22 +28,30 @@ 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 -aic7xxx_old.txt - - info on driver for Adaptec controllers, old generation 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 @@ -52,20 +60,24 @@ 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 -ibmmca.txt - - info on driver for IBM adapters with MCA bus 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 @@ -76,6 +88,8 @@ 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 @@ -92,3 +106,5 @@ 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. diff --git a/Documentation/scsi/53c700.txt b/Documentation/scsi/53c700.txt index 0da681d497a..e31aceb6df1 100644 --- a/Documentation/scsi/53c700.txt +++ b/Documentation/scsi/53c700.txt @@ -16,32 +16,13 @@ fill in to get the driver working. Compile Time Flags ================== -The driver may be either io mapped or memory mapped. This is -selectable by configuration flags: - -CONFIG_53C700_MEM_MAPPED - -define if the driver is memory mapped. - -CONFIG_53C700_IO_MAPPED - -define if the driver is to be io mapped. - -One or other of the above flags *must* be defined. - -Other flags are: +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). -CONFIG_53C700_USE_CONSISTENT - -allocate consistent memory (should only be used if your architecture -has a mixture of consistent and inconsistent memory). Fully -consistent or fully inconsistent architectures should not define this. - Using the Chip Core Driver ========================== diff --git a/Documentation/scsi/BusLogic.txt b/Documentation/scsi/BusLogic.txt index d7fbc9488b9..48e982cd6fe 100644 --- a/Documentation/scsi/BusLogic.txt +++ b/Documentation/scsi/BusLogic.txt @@ -553,7 +553,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree: make config make zImage -Then install "arch/i386/boot/zImage" as your standard kernel, run lilo if +Then install "arch/x86/boot/zImage" as your standard kernel, run lilo if appropriate, and reboot. diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc index 337c924cc81..2f6d595f95e 100644 --- a/Documentation/scsi/ChangeLog.lpfc +++ b/Documentation/scsi/ChangeLog.lpfc @@ -352,7 +352,7 @@ Changes from 20041229 to 20050110 lpfc_scsiport.c * In remote port changes: no longer nulling target->pnode when removing from mapped list. Pnode get nulled when the node is - freed (after nodev tmo). This bug was causing i/o recieved in + freed (after nodev tmo). This bug was causing i/o received in the small window while the device was blocked to be errored w/ did_no_connect. With the fix, it returns host_busy (per the pre-remote port changes). @@ -530,7 +530,7 @@ Changes from 20041018 to 20041123 coherent mappings. Note: There are more consistent mappings that are using pci_dma_sync calls. Probably these should be removed as well. - * Modified lpfc_free_scsi_buf to accomodate all three scsi_buf + * Modified lpfc_free_scsi_buf to accommodate all three scsi_buf free types to alleviate miscellaneous panics with cable pull testing. * Set hotplug to default 0 and lpfc_target_remove to not remove @@ -573,7 +573,7 @@ Changes from 20041018 to 20041123 * Backround nodev_timeout processing to DPC This enables us to unblock (stop dev_loss_tmo) when appopriate. * Fix array discovery with multiple luns. The max_luns was 0 at - the time the host structure was intialized. lpfc_cfg_params + the time the host structure was initialized. lpfc_cfg_params then set the max_luns to the correct value afterwards. * Remove unused define LPFC_MAX_LUN and set the default value of lpfc_max_lun parameter to 512. @@ -583,7 +583,7 @@ Changes from 20041018 to 20041123 included more than once. * Replaced "set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(timeout)" with "msleep(timeout)". - * Fixnode was loosing starget when rediscovered. We saw messages + * Fixnode was losing starget when rediscovered. We saw messages like: lpfc 0000:04:02.0: 0:0263 Cannot block scsi target as a result. Moved starget field into struct lpfc_target which is referenced from the node. @@ -604,7 +604,7 @@ Changes from 20041018 to 20041123 * Make 3 functions static: lpfc_get_hba_sym_node_name, lpfc_intr_prep and lpfc_setup_slim_access. Move lpfc_intr_prep and lpfc_setup_slim_access so they're defined before being used. - * Remove an unecessary list_del() in lpfc_hbadisc.c. + * Remove an unnecessary list_del() in lpfc_hbadisc.c. * Set nlp_state before calling lpfc_nlp_list() since this will potentially call fc_target_unblock which may cause a race in queuecommand by releasing host_lock. @@ -753,7 +753,7 @@ Changes from 20040908 to 20040920 * Changed version number to 8.0.12 * Removed used #defines: DEFAULT_PCI_LATENCY_CLOCKS and PCI_LATENCY_VALUE from lpfc_hw.h. - * Changes to accomodate rnid. + * Changes to accommodate rnid. * Fix RSCN handling so RSCN NS queries only effect NPorts found in RSCN data. * If we rcv a plogi on a NPort queued up for discovery, clear the @@ -813,7 +813,7 @@ Changes from 20040908 to 20040920 counter instead, brd_no isn't reused anymore. Also some tiny whitespace cleanups in surrounding code. * Reorder functions in lpfc_els.c to remove need for prototypes. - * Removed unsed prototypes from lpfc_crtn.h - + * Removed unused prototypes from lpfc_crtn.h - lpfc_ip_timeout_handler, lpfc_read_pci and lpfc_revoke. * Removed some unused prototypes from lpfc_crtn.h - lpfc_scsi_hba_reset, lpfc_scsi_issue_inqsn, @@ -863,7 +863,7 @@ Changes from 20040823 to 20040908 * Minimal support for SCSI flat space addressing/volume set addressing. Use 16 bits of LUN address so that flat addressing/VSA will work. - * Changed 2 occurences of if( 1 != f(x)) to if(f(x) != 1) + * Changed 2 occurrences of if( 1 != f(x)) to if(f(x) != 1) * Drop include of lpfc_cfgparm.h. * Reduce stack usage of lpfc_fdmi_cmd in lpfc_ct.c. * Add minimum range checking property to /sys write/store @@ -1449,7 +1449,7 @@ Changes from 20040402 to 20040409 * Removed lpfc_els_chk_latt from the lpfc_config_post function. lpfc_els_chk_latt will enable the link event interrupts when flogi is pending which causes two discovery state machines - running parallely. + running parallelly. * Add pci_disable_device to unload path. * Move lpfc_sleep_event from lpfc_fcp.c to lpfc_util_ioctl.c * Call dma_map_single() & pci_map_single() directly instead of via @@ -1590,7 +1590,7 @@ Changes from 20040326 to 20040402 ELX_WRITE_HS ELX_WRITE_HA ELX_WRITE_CA ELX_READ_HC ELX_READ_HS ELX_READ_HA ELX_READ_CA ELX_READ_MB ELX_RESET ELX_READ_HBA ELX_INSTANCE ELX_LIP. Also introduced - attribute "set" to be used in conjuction with the above + attribute "set" to be used in conjunction with the above attributes. * Removed DLINK, enque and deque declarations now that clock doesn't use them anymore @@ -1718,7 +1718,7 @@ Changes from 20040319 to 20040326 * lpfc_els_timeout_handler() now uses system timer. * Further cleanup of #ifdef powerpc * lpfc_scsi_timeout_handler() now uses system timer. - * Replace common driver's own defines for endianess w/ Linux's + * Replace common driver's own defines for endianness w/ Linux's __BIG_ENDIAN etc. * Added #ifdef IPFC for all IPFC specific code. * lpfc_disc_retry_rptlun() now uses system timer. diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index 5e07d320817..d2052fdbedd 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -168,7 +168,7 @@ 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 - charactor node name change from 'megadev' to 'megadev_legacy' to avoid + character node name change from 'megadev' to 'megadev_legacy' to avoid conflict. --- Hopefully we'll be getting the build restriction zapped much sooner, diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 00301ed9c37..91ba58ef02d 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,180 @@ +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 @@ -418,7 +595,7 @@ i. Support for 1078 type (ppc IOP) controller, device id : 0x60 added. 3 Older Version : 00.00.02.02 i. Register 16 byte CDB capability with scsi midlayer - "Ths patch properly registers the 16 byte command length capability of the + "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." diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx index 8b278c10edf..9288e3d8974 100644 --- a/Documentation/scsi/ChangeLog.ncr53c8xx +++ b/Documentation/scsi/ChangeLog.ncr53c8xx @@ -200,7 +200,7 @@ Sun Feb 14:00 1999 Gerard Roudier (groudier@club-internet.fr) 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 mispelling fixed (ABORT instead of ABRT). Was fortunately + - Tiny misspelling fixed (ABORT instead of ABRT). Was fortunately harmless. - Negotiate SYNC data transfers with CCS devices. diff --git a/Documentation/scsi/ChangeLog.sym53c8xx b/Documentation/scsi/ChangeLog.sym53c8xx index 02ffbc1e8a8..c1933707d0b 100644 --- a/Documentation/scsi/ChangeLog.sym53c8xx +++ b/Documentation/scsi/ChangeLog.sym53c8xx @@ -457,7 +457,7 @@ Fri Jan 1 20:00 1999 Gerard Roudier (groudier@club-internet.fr) 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 slighly the Symbios NVRAM lay-out based on the excerpt of + - 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). diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx index 9e15b4f9cd2..52f0b435923 100644 --- a/Documentation/scsi/LICENSE.qla2xxx +++ b/Documentation/scsi/LICENSE.qla2xxx @@ -1,45 +1,290 @@ -Copyright (c) 2003-2005 QLogic Corporation -QLogic Linux Fibre Channel HBA Driver +Copyright (c) 2003-2014 QLogic Corporation +QLogic Linux FC-FCoE Driver -This program includes a device driver for Linux 2.6 that may be -distributed with QLogic hardware specific firmware binary file. +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 as published by the Free Software -Foundation (version 2 or a later version). - -You may redistribute the hardware specific firmware binary file -under the following terms: - - 1. Redistribution of source code (only if applicable), - must retain the above copyright notice, this list of - conditions and the following disclaimer. - - 2. Redistribution 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 QLogic Corporation may not be used to - endorse or promote products derived from this software - without specific prior written permission - -REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, -THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "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 -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. - -USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT -CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR -OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, -TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN -ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN -COMBINATION WITH THIS PROGRAM. +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. diff --git a/Documentation/scsi/LICENSE.qla4xxx b/Documentation/scsi/LICENSE.qla4xxx new file mode 100644 index 00000000000..fcc27ad27d7 --- /dev/null +++ b/Documentation/scsi/LICENSE.qla4xxx @@ -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. diff --git a/Documentation/scsi/aha152x.txt b/Documentation/scsi/aha152x.txt index 29ce6d87e45..94848734ac6 100644 --- a/Documentation/scsi/aha152x.txt +++ b/Documentation/scsi/aha152x.txt @@ -124,7 +124,7 @@ in the partition table and therefore every operating system has to know the right geometry to be able to interpret it. Moreover there are certain limitations to the C/H/S addressing scheme, -namely the address space is limited to upto 255 heads, upto 63 sectors +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 diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt index 16e054c9c70..e2d3273000d 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt @@ -215,7 +215,7 @@ The following information is available in this file: INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. USE THEM WITH CAUTION. - Edit the file "modprobe.conf" in the directory /etc and add/edit a + 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: ----------------------------------------------------------------- @@ -267,7 +267,7 @@ The following information is available in this file: 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 ommitted indicating that they should retain + 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 @@ -291,7 +291,7 @@ The following information is available in this file: 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 ommitted indicating that + target. Controllers may be omitted indicating that they should retain the default read streaming setting. Example: rd_strm:{0x0041} On Controller 0 @@ -313,7 +313,7 @@ The following information is available in this file: ----------------------------------------------------------------- Option: dv: {value[,value...]} Definition: Set Domain Validation Policy on a per-controller basis. - Controllers may be ommitted indicating that + 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. @@ -340,7 +340,7 @@ The following information is available in this file: Option: precomp: {value[,value...]} Definition: Set IO Cell precompensation value on a per-controller basis. - Controllers may be ommitted indicating that + Controllers may be omitted indicating that they should retain the default precompensation setting. Example: precomp:{0x1} On Controller 0 set precompensation to 1. @@ -353,7 +353,7 @@ The following information is available in this file: ----------------------------------------------------------------- Option: slewrate: {value[,value...]} Definition: Set IO Cell slew rate on a per-controller basis. - Controllers may be ommitted indicating that + 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. @@ -366,7 +366,7 @@ The following information is available in this file: ----------------------------------------------------------------- Option: amplitude: {value[,value...]} Definition: Set IO Cell signal amplitude on a per-controller basis. - Controllers may be ommitted indicating that + Controllers may be omitted indicating that they should retain the default read streaming setting. Example: amplitude:{0x1} On Controller 0 set amplitude to 1. diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt index 18f8d1905e6..7c5d0223d44 100644 --- a/Documentation/scsi/aic7xxx.txt +++ b/Documentation/scsi/aic7xxx.txt @@ -190,7 +190,7 @@ The following information is available in this file: INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. USE THEM WITH CAUTION. - Edit the file "modprobe.conf" in the directory /etc and add/edit a + 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: ----------------------------------------------------------------- diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt deleted file mode 100644 index 7bd210ab45a..00000000000 --- a/Documentation/scsi/aic7xxx_old.txt +++ /dev/null @@ -1,511 +0,0 @@ - AIC7xxx Driver for Linux - -Introduction ----------------------------- -The AIC7xxx SCSI driver adds support for Adaptec (http://www.adaptec.com) -SCSI controllers and chipsets. Major portions of the driver and driver -development are shared between both Linux and FreeBSD. Support for the -AIC-7xxx chipsets have been in the default Linux kernel since approximately -linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD -2.1.0 or later. - - Supported cards/chipsets - ---------------------------- - Adaptec Cards - ---------------------------- - AHA-274x - AHA-274xT - AHA-2842 - AHA-2910B - AHA-2920C - AHA-2930 - AHA-2930U - AHA-2930CU - AHA-2930U2 - AHA-2940 - AHA-2940W - AHA-2940U - AHA-2940UW - AHA-2940UW-PRO - AHA-2940AU - AHA-2940U2W - AHA-2940U2 - AHA-2940U2B - AHA-2940U2BOEM - AHA-2944D - AHA-2944WD - AHA-2944UD - AHA-2944UWD - AHA-2950U2 - AHA-2950U2W - AHA-2950U2B - AHA-29160M - AHA-3940 - AHA-3940U - AHA-3940W - AHA-3940UW - AHA-3940AUW - AHA-3940U2W - AHA-3950U2B - AHA-3950U2D - AHA-3960D - AHA-39160M - AHA-3985 - AHA-3985U - AHA-3985W - AHA-3985UW - - Motherboard Chipsets - ---------------------------- - AIC-777x - AIC-785x - AIC-786x - AIC-787x - AIC-788x - AIC-789x - AIC-3860 - - Bus Types - ---------------------------- - W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support - SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s. - U - Ultra SCSI, transfer rates up to 40MB/s. - U2- Ultra 2 SCSI, transfer rates up to 80MB/s. - D - Differential SCSI. - T - Twin Channel SCSI. Up to 14 SCSI devices. - - AHA-274x - EISA SCSI controller - AHA-284x - VLB SCSI controller - AHA-29xx - PCI SCSI controller - AHA-394x - PCI controllers with two separate SCSI controllers on-board. - AHA-398x - PCI RAID controllers with three separate SCSI controllers - on-board. - - Not Supported Devices - ------------------------------ - Adaptec Cards - ---------------------------- - AHA-2920 (Only the cards that use the Future Domain chipset are not - supported, any 2920 cards based on Adaptec AIC chipsets, - such as the 2920C, are supported) - AAA-13x Raid Adapters - AAA-113x Raid Port Card - - Motherboard Chipsets - ---------------------------- - AIC-7810 - - Bus Types - ---------------------------- - R - Raid Port busses are not supported. - - The hardware RAID devices sold by Adaptec are *NOT* supported by this - driver (and will people please stop emailing me about them, they are - a totally separate beast from the bare SCSI controllers and this driver - cannot be retrofitted in any sane manner to support the hardware RAID - features on those cards - Doug Ledford). - - - People - ------------------------------ - Justin T Gibbs gibbs@plutotech.com - (BSD Driver Author) - Dan Eischen deischen@iworks.InterWorks.org - (Original Linux Driver Co-maintainer) - Dean Gehnert deang@teleport.com - (Original Linux FTP/patch maintainer) - Jess Johnson jester@frenzy.com - (AIC7xxx FAQ author) - Doug Ledford dledford@redhat.com - (Current Linux aic7xxx-5.x.x Driver/Patch/FTP maintainer) - - Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original - author of the driver. John has since retired from the project. Thanks - again for all his work! - - Mailing list - ------------------------------ - There is a mailing list available for users who want to track development - and converse with other users and developers. This list is for both - FreeBSD and Linux support of the AIC7xxx chipsets. - - To subscribe to the AIC7xxx mailing list send mail to the list server, - with "subscribe AIC7xxx" in the body (no Subject: required): - To: majordomo@FreeBSD.ORG - --- - subscribe AIC7xxx - - To unsubscribe from the list, send mail to the list server with: - To: majordomo@FreeBSD.ORG - --- - unsubscribe AIC7xxx - - Send regular messages and replies to: AIC7xxx@FreeBSD.ORG - - Boot Command line options - ------------------------------ - "aic7xxx=no_reset" - Eliminate the SCSI bus reset during startup. - Some SCSI devices need the initial reset that this option disables - in order to work. If you have problems at bootup, please make sure - you aren't using this option. - - "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at - bootup by scanning from the highest numbered PCI device to the - lowest numbered PCI device, others do just the opposite and scan - from lowest to highest numbered PCI device. There is no reliable - way to autodetect this ordering. So, we default to the most common - order, which is lowest to highest. Then, in case your motherboard - scans from highest to lowest, we have this option. If your BIOS - finds the drives on controller A before controller B but the linux - kernel finds your drives on controller B before A, then you should - use this option. - - "aic7xxx=extended" - Force the driver to detect extended drive translation - on your controller. This helps those people who have cards without - a SEEPROM make sure that linux and all other operating systems think - the same way about your hard drives. - - "aic7xxx=scbram" - Some cards have external SCB RAM that can be used to - give the card more hardware SCB slots. This allows the driver to use - that SCB RAM. Without this option, the driver won't touch the SCB - RAM because it is known to cause problems on a few cards out there - (such as 3985 class cards). - - "aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel - to use the correct IRQ type for your card. This only applies to EISA - based controllers. On these controllers, 0 is for Edge triggered - interrupts, and 1 is for Level triggered interrupts. If you aren't - sure or don't know which IRQ trigger type your EISA card uses, then - let the kernel autodetect the trigger type. - - "aic7xxx=verbose" - This option can be used in one of two ways. If you - simply specify aic7xxx=verbose, then the kernel will automatically - pick the default set of verbose messages for you to see. - Alternatively, you can specify the command as - "aic7xxx=verbose:0xXXXX" where the X entries are replaced with - hexadecimal digits. This option is a bit field type option. For - a full listing of the available options, search for the - #define VERBOSE_xxxxxx lines in the aic7xxx.c file. If you want - verbose messages, then it is recommended that you simply use the - aic7xxx=verbose variant of this command. - - "aic7xxx=pci_parity:x" - This option controls whether or not the driver - enables PCI parity error checking on the PCI bus. By default, this - checking is disabled. To enable the checks, simply specify pci_parity - with no value afterwords. To reverse the parity from even to odd, - supply any number other than 0 or 255. In short: - pci_parity - Even parity checking (even is the normal PCI parity) - pci_parity:x - Where x > 0, Odd parity checking - pci_parity:0 - No check (default) - NOTE: In order to get Even PCI parity checking, you must use the - version of the option that does not include the : and a number at - the end (unless you want to enter exactly 2^32 - 1 as the number). - - "aic7xxx=no_probe" - This option will disable the probing for any VLB - based 2842 controllers and any EISA based controllers. This is - needed on certain newer motherboards where the normal EISA I/O ranges - have been claimed by other PCI devices. Probing on those machines - will often result in the machine crashing or spontaneously rebooting - during startup. Examples of machines that need this are the - Dell PowerEdge 6300 machines. - - "aic7xxx=seltime:2" - This option controls how long the card waits - during a device selection sequence for the device to respond. - The original SCSI spec says that this "should be" 256ms. This - is generally not required with modern devices. However, some - very old SCSI I devices need the full 256ms. Most modern devices - can run fine with only 64ms. The default for this option is - 64ms. If you need to change this option, then use the following - table to set the proper value in the example above: - 0 - 256ms - 1 - 128ms - 2 - 64ms - 3 - 32ms - - "aic7xxx=panic_on_abort" - This option is for debugging and will cause - the driver to panic the linux kernel and freeze the system the first - time the drivers abort or reset routines are called. This is most - helpful when some problem causes infinite reset loops that scroll too - fast to see. By using this option, you can write down what the errors - actually are and send that information to me so it can be fixed. - - "aic7xxx=dump_card" - This option will print out the *entire* set of - configuration registers on the card during the init sequence. This - is a debugging aid used to see exactly what state the card is in - when we finally finish our initialization routines. If you don't - have documentation on the chipsets, this will do you absolutely - no good unless you are simply trying to write all the information - down in order to send it to me. - - "aic7xxx=dump_sequencer" - This is the same as the above options except - that instead of dumping the register contents on the card, this - option dumps the contents of the sequencer program RAM. This gives - the ability to verify that the instructions downloaded to the - card's sequencer are indeed what they are supposed to be. Again, - unless you have documentation to tell you how to interpret these - numbers, then it is totally useless. - - "aic7xxx=override_term:0xffffffff" - This option is used to force the - termination on your SCSI controllers to a particular setting. This - is a bit mask variable that applies for up to 8 aic7xxx SCSI channels. - Each channel gets 4 bits, divided as follows: - bit 3 2 1 0 - | | | Enable/Disable Single Ended Low Byte Termination - | | En/Disable Single Ended High Byte Termination - | En/Disable Low Byte LVD Termination - En/Disable High Byte LVD Termination - - The upper 2 bits that deal with LVD termination only apply to Ultra2 - controllers. Furthermore, due to the current Ultra2 controller - designs, these bits are tied together such that setting either bit - enables both low and high byte LVD termination. It is not possible - to only set high or low byte LVD termination in this manner. This is - an artifact of the BIOS definition on Ultra2 controllers. For other - controllers, the only important bits are the two lowest bits. Setting - the higher bits on non-Ultra2 controllers has no effect. A few - examples of how to use this option: - - Enable low and high byte termination on a non-ultra2 controller that - is the first aic7xxx controller (the correct bits are 0011), - aic7xxx=override_term:0x3 - - Enable all termination on the third aic7xxx controller, high byte - termination on the second aic7xxx controller, and low and high byte - SE termination on the first aic7xxx controller - (bits are 1111 0010 0011), - aic7xxx=override_term:0xf23 - - No attempt has been made to make this option non-cryptic. It really - shouldn't be used except in dire circumstances, and if that happens, - I'm probably going to be telling you what to set this to anyway :) - - "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV - bit in the DEVCONFIG PCI register. Currently, this is one of the - very few registers that we have absolutely *no* way of detecting - what the variable should be. It depends entirely on how the chipset - and external terminators were coupled by the card/motherboard maker. - Further, a chip reset (at power up) always sets this bit to 0. If - there is no BIOS to run on the chipset/card (such as with a 2910C - or a motherboard controller with the BIOS totally disabled) then - the variable may not get set properly. Of course, if the proper - setting was 0, then that's what it would be after the reset, but if - the proper setting is actually 1.....you get the picture. Now, since - we can't detect this at all, I've added this option to force the - setting. If you have a BIOS on your controller then you should never - need to use this option. However, if you are having lots of SCSI - reset problems and can't seem to get them knocked out, this may help. - - Here's a test to know for certain if you need this option. Make - a boot floppy that you can use to boot your computer up and that - will detect the aic7xxx controller. Next, power down your computer. - While it's down, unplug all SCSI cables from your Adaptec SCSI - controller. Boot the system back up to the Adaptec EZ-SCSI BIOS - and then make sure that termination is enabled on your adapter (if - you have an Adaptec BIOS of course). Next, boot up the floppy you - made and wait for it to detect the aic7xxx controller. If the kernel - finds the controller fine, says scsi : x hosts and then tries to - detect your devices like normal, up to the point where it fails to - mount your root file system and panics, then you're fine. If, on - the other hand, the system goes into an infinite reset loop, then - you need to use this option and/or the previous option to force the - proper termination settings on your controller. If this happens, - then you next need to figure out what your settings should be. - - To find the correct settings, power your machine back down, connect - back up the SCSI cables, and boot back into your machine like normal. - However, boot with the aic7xxx=verbose:0x39 option. Record the - initial DEVCONFIG values for each of your aic7xxx controllers as - they are listed, and also record what the machine is detecting as - the proper termination on your controllers. NOTE: the order in - which the initial DEVCONFIG values are printed out is not guaranteed - to be the same order as the SCSI controllers are registered. The - above option and this option both work on the order of the SCSI - controllers as they are registered, so make sure you match the right - DEVCONFIG values with the right controllers if you have more than - one aic7xxx controller. - - Once you have the detected termination settings and the initial - DEVCONFIG values for each controller, then figure out what the - termination on each of the controllers *should* be. Hopefully, that - part is correct, but it could possibly be wrong if there is - bogus cable detection logic on your controller or something similar. - If all the controllers have the correct termination settings, then - don't set the aic7xxx=override_term variable at all, leave it alone. - Next, on any controllers that go into an infinite reset loop when - you unplug all the SCSI cables, get the starting DEVCONFIG value. - If the initial DEVCONFIG value is divisible by 2, then the correct - setting for that controller is 0. If it's an odd number, then - the correct setting for that controller is 1. For any other - controllers that didn't have an infinite reset problem, then reverse - the above options. If DEVCONFIG was even, then the correct setting - is 1, if not then the correct setting is 0. - - Now that you know what the correct setting was for each controller, - we need to encode that into the aic7xxx=stpwlev:0x... variable. - This variable is a bit field encoded variable. Bit 0 is for the first - aic7xxx controller, bit 1 for the next, etc. Put all these bits - together and you get a number. For example, if the third aic7xxx - needed a 1, but the second and first both needed a 0, then the bits - would be 100 in binary. This then translates to 0x04. You would - therefore set aic7xxx=stpwlev:0x04. This is fairly standard binary - to hexadecimal conversions here. If you aren't up to speed on the - binary->hex conversion then send an email to the aic7xxx mailing - list and someone can help you out. - - "aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to disable - or enable Tagged Command Queueing (TCQ) on specific devices. As of - driver version 5.1.11, TCQ is now either on or off by default - according to the setting you choose during the make config process. - In order to en/disable TCQ for certain devices at boot time, a user - may use this boot param. The driver will then parse this message out - and en/disable the specific device entries that are present based upon - the value given. The param line is parsed in the following manner: - - { - first instance indicates the start of this parameter values - second instance is the start of entries for a particular - device entry - } - end the entries for a particular host adapter, or end the entire - set of parameter entries - , - move to next entry. Inside of a set of device entries, this - moves us to the next device on the list. Outside of device - entries, this moves us to the next host adapter - . - Same effect as , but is safe to use with insmod. - x - the number to enter into the array at this position. - 0 = Enable tagged queueing on this device and use the default - queue depth - 1-254 = Enable tagged queueing on this device and use this - number as the queue depth - 255 = Disable tagged queueing on this device. - Note: anything above 32 for an actual queue depth is wasteful - and not recommended. - - A few examples of how this can be used: - - tag_info:{{8,12,,0,,255,4}} - This line will only effect the first aic7xxx card registered. It - will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2 - at the default, set id 3 to tagged queueing enabled and use the - default queue depth, id 4 default, id 5 disabled, and id 6 to 4. - Any not specified entries stay at the default value, repeated - commas with no value specified will simply increment to the next id - without changing anything for the missing values. - - tag_info:{,,,{,,,255}} - First, second, and third adapters at default values. Fourth - adapter, id 3 is disabled. Notice that leading commas simply - increment what the first number effects, and there are no need - for trailing commas. When you close out an adapter, or the - entire entry, anything not explicitly set stays at the default - value. - - A final note on this option. The scanner I used for this isn't - perfect or highly robust. If you mess the line up, the worst that - should happen is that the line will get ignored. If you don't - close out the entire entry with the final bracket, then any other - aic7xxx options after this will get ignored. So, in general, be - sure of what you are entering, and after you have it right, just - add it to the lilo.conf file so there won't be any mistakes. As - a means of checking this parser, the entire tag_info array for - each card is now printed out in the /proc/scsi/aic7xxx/x file. You - can use that to verify that your options were parsed correctly. - - Boot command line options may be combined to form the proper set of options - a user might need. For example, the following is valid: - - aic7xxx=verbose,extended,irq_trigger:1 - - The only requirement is that individual options be separated by a comma or - a period on the command line. - - Module Loading command options - ------------------------------ - When loading the aic7xxx driver as a module, the exact same options are - available to the user. However, the syntax to specify the options changes - slightly. For insmod, you need to wrap the aic7xxx= argument in quotes - and replace all ',' with '.'. So, for example, a valid insmod line - would be: - - insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended' - - This line should result in the *exact* same behaviour as if you typed - it in at the lilo prompt and the driver was compiled into the kernel - instead of being a module. The reason for the single quote is so that - the shell won't try to interpret anything in the line, such as {. - Insmod assumes any options starting with a letter instead of a number - is a character string (which is what we want) and by switching all of - the commas to periods, insmod won't interpret this as more than one - string and write junk into our binary image. I consider it a bug in - the insmod program that even if you wrap your string in quotes (quotes - that pass the shell mind you and that insmod sees) it still treats - a comma inside of those quotes as starting a new variable, resulting - in memory scribbles if you don't switch the commas to periods. - - - Kernel Compile options - ------------------------------ - The various kernel compile time options for this driver are now fairly - well documented in the file Documentation/Configure.help. In order to - see this documentation, you need to use one of the advanced configuration - programs (menuconfig and xconfig). If you are using the "make menuconfig" - method of configuring your kernel, then you would simply highlight the - option in question and hit the ? key. If you are using the "make xconfig" - method of configuring your kernel, then simply click on the help button - next to the option you have questions about. The help information from - the Configure.help file will then get automatically displayed. - - /proc support - ------------------------------ - The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/ - directory. That directory contains a file for each SCSI controller in - the system. Each file presents the current configuration and transfer - statistics (enabled with #define in aic7xxx.c) for each controller. - - Thanks to Michael Neuffer for his upper-level SCSI help, and - Matthew Jacob for statistics support. - - Debugging the driver - ------------------------------ - Should you have problems with this driver, and would like some help in - getting them solved, there are a couple debugging items built into - the driver to facilitate getting the needed information from the system. - In general, I need a complete description of the problem, with as many - logs as possible concerning what happens. To help with this, there is - a command option aic7xxx=panic_on_abort. This option, when set, forces - the driver to panic the kernel on the first SCSI abort issued by the - mid level SCSI code. If your system is going to reset loops and you - can't read the screen, then this is what you need. Not only will it - stop the system, but it also prints out a large amount of state - information in the process. Second, if you specify the option - "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much - information as it runs that you won't be able to see anything. - However, this can actually be very useful if your machine simply - locks up when trying to boot, since it will pin-point what was last - happening (in regards to the aic7xxx driver) immediately prior to - the lockup. This is really only useful if your machine simply can - not boot up successfully. If you can get your machine to run, then - this will produce far too much information. - - FTP sites - ------------------------------ - ftp://ftp.redhat.com/pub/aic/ - - Out of date. I used to keep stuff here, but too many people - complained about having a hard time getting into Red Hat's ftp - server. So use the web site below instead. - ftp://ftp.pcnet.com/users/eischen/Linux/ - - Dan Eischen's driver distribution area - ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/ - - European Linux mirror of Teleport site - - Web sites - ------------------------------ - http://people.redhat.com/dledford/ - - My web site, also the primary aic7xxx site with several related - pages. - -Dean W. Gehnert -deang@teleport.com - -$Revision: 3.0 $ - -Modified by Doug Ledford 1998-2000 - diff --git a/Documentation/scsi/bfa.txt b/Documentation/scsi/bfa.txt new file mode 100644 index 00000000000..f2d6e9d1791 --- /dev/null +++ b/Documentation/scsi/bfa.txt @@ -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 diff --git a/Documentation/scsi/bnx2fc.txt b/Documentation/scsi/bnx2fc.txt new file mode 100644 index 00000000000..80823556d62 --- /dev/null +++ b/Documentation/scsi/bnx2fc.txt @@ -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 diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt index dca658362cb..891435a72fc 100644 --- a/Documentation/scsi/hpsa.txt +++ b/Documentation/scsi/hpsa.txt @@ -28,6 +28,12 @@ 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 ----------------------------- @@ -39,6 +45,8 @@ HPSA specific entries in /sys /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 @@ -55,6 +63,21 @@ HPSA specific entries in /sys 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: ------------------------------ diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt index 9605179711f..12ecfd308e5 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt @@ -37,7 +37,7 @@ For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: 0x40 Inbound Queue Port 0x44 Outbound Queue Port -For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: +For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: BAR0 offset Register 0x20400 Inbound Doorbell Register @@ -55,9 +55,31 @@ For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: 0x40-0x1040 Inbound Queue 0x1040-0x2040 Outbound Queue +For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: -I/O Request Workflow ----------------------- + 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. @@ -101,6 +123,45 @@ 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 --------------------- @@ -112,7 +173,7 @@ The driver exposes following sysfs attributes: ----------------------------------------------------------------------------- -Copyright (C) 2006-2009 HighPoint Technologies, Inc. All Rights Reserved. +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 diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt deleted file mode 100644 index 45d61ad8c6f..00000000000 --- a/Documentation/scsi/ibmmca.txt +++ /dev/null @@ -1,1402 +0,0 @@ - - -=< The IBM Microchannel SCSI-Subsystem >=- - - for the IBM PS/2 series - - Low Level Software-Driver for Linux - - Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU - General Public License. Originally written by Martin Kolinek, December 1995. - Officially modified and maintained by Michael Lang since January 1999. - - Version 4.0a - - Last update: January 3, 2001 - - Before you Start - ---------------- - This is the common README.ibmmca file for all driver releases of the - IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0 - or newer do not work with kernel versions older than 2.4.0, while driver - versions older than 4.0 do not work with kernels 2.4.0 or later! If you - try to compile your kernel with the wrong driver source, the - compilation is aborted and you get a corresponding error message. This is - no bug in the driver; it prevents you from using the wrong source code - with the wrong kernel version. - - Authors of this Driver - ---------------------- - - Chris Beauregard (improvement of the SCSI-device mapping by the driver) - - Martin Kolinek (origin, first release of this driver) - - Klaus Kudielka (multiple SCSI-host management/detection, adaption to - Linux Kernel 2.1.x, module support) - - Michael Lang (assigning original pun/lun mapping, dynamical ldn - assignment, rewritten adapter detection, this file, - patches, official driver maintenance and subsequent - debugging, related with the driver) - - Table of Contents - ----------------- - 1 Abstract - 2 Driver Description - 2.1 IBM SCSI-Subsystem Detection - 2.2 Physical Units, Logical Units, and Logical Devices - 2.3 SCSI-Device Recognition and dynamical ldn Assignment - 2.4 SCSI-Device Order - 2.5 Regular SCSI-Command-Processing - 2.6 Abort & Reset Commands - 2.7 Disk Geometry - 2.8 Kernel Boot Option - 2.9 Driver Module Support - 2.10 Multiple Hostadapter Support - 2.11 /proc/scsi-Filesystem Information - 2.12 /proc/mca-Filesystem Information - 2.13 Supported IBM SCSI-Subsystems - 2.14 Linux Kernel Versions - 3 Code History - 4 To do - 5 Users' Manual - 5.1 Commandline Parameters - 5.2 Troubleshooting - 5.3 Bug reports - 5.4 Support WWW-page - 6 References - 7 Credits to - 7.1 People - 7.2 Sponsors & Supporters - 8 Trademarks - 9 Disclaimer - - * * * - - 1 Abstract - ---------- - This README-file describes the IBM SCSI-subsystem low level driver for - Linux. The descriptions which were formerly kept in the source code have - been taken out of this file to simplify the codes readability. The driver - description has been updated, as most of the former description was already - quite outdated. The history of the driver development is also kept inside - here. Multiple historical developments have been summarized to shorten the - text size a bit. At the end of this file you can find a small manual for - this driver and hints to get it running on your machine. - - 2 Driver Description - -------------------- - 2.1 IBM SCSI-Subsystem Detection - -------------------------------- - This is done in the ibmmca_detect() function. It first checks, if the - Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the - Microchannel. In a next step, a free interrupt is chosen and the main - interrupt handler is connected to it to handle answers of the SCSI- - subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11 - instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a - further step it is checked, if the adapter gets detected by force from - the kernel commandline, where the I/O port and the SCSI-subsystem id can - be specified. The next step checks if there is an integrated SCSI-subsystem - installed. This register area is fixed through all IBM PS/2 MCA-machines - and appears as something like a virtual slot 10 of the MCA-bus. On most - PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not - integrated SCSI-controller is available. But on certain PS/2s, like model - 9595, this slot 10 is used to store other information which at earlier - stage confused the driver and resulted in the detection of some ghost-SCSI. - If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS - registers are either 0xff or 0x00, there must be an integrated SCSI- - subsystem present and it will be registered as IBM Integrated SCSI- - Subsystem. The next step checks, if there is a slot-adapter installed on - the MCA-bus. To get this, the first two POS-registers, that represent the - adapter ID are checked. If they fit to one of the ids, stored in the - adapter list, a SCSI-subsystem is assumed to be found in a slot and will be - registered. This check is done through all possible MCA-bus slots to allow - more than one SCSI-adapter to be present in the PS/2-system and this is - already the first point of problems. Looking into the technical reference - manual for the IBM PS/2 common interfaces, the POS2 register must have - different interpretation of its single bits to avoid overlapping I/O - regions. While one can assume, that the integrated subsystem has a fix - I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must - use a different I/O-address. This is expressed by bit 1 to 3 of POS2 - (multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated - subsystem, but not for the adapters! The following list shows, how the - bits of POS2 and POS3 should be interpreted. - - The POS2-register of all PS/2 models' integrated SCSI-subsystems has the - following interpretation of bits: - Bit 7 - 4 : Chip Revision ID (Release) - Bit 3 - 2 : Reserved - Bit 1 : 8k NVRAM Disabled - Bit 0 : Chip Enable (EN-Signal) - The POS3-register is interpreted as follows (for most IBM SCSI-subsys.): - Bit 7 - 5 : SCSI ID - Bit 4 - 0 : Reserved = 0 - The slot-adapters have different interpretation of these bits. The IBM SCSI - adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following - interpretation of the POS2 register: - Bit 7 - 4 : ROM Segment Address Select - Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540) - Bit 0 : Adapter Enable (EN-Signal) - and for the POS3 register: - Bit 7 - 5 : SCSI ID - Bit 4 : Fairness Enable (SCSI ID3 f. F/W) - Bit 3 - 0 : Arbitration Level - The most modern product of the series is the IBM SCSI-2 F/W adapter, it - allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be - between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide - adapter PUN expression. In short words, this means, that IBM PS/2 machines - can only support 1 single integrated subsystem by default. Additional - slot-adapters get ports assigned by the automatic configuration tool. - - One day I found a patch in ibmmca_detect(), forcing the I/O-address to be - 0x3540 for integrated SCSI-subsystems, there was a remark placed, that on - integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5. - This means, that really for these models, POS2 has to be interpreted - sticking to the technical reference guide. In this case, the bit 2 (4) is - a reserved bit and may not be interpreted. These differences between the - adapters and the integrated controllers are taken into account by the - detection routine of the driver on from version >3.0g. - - Every time, a SCSI-subsystem is discovered, the ibmmca_register() function - is called. This function checks first, if the requested area for the I/O- - address of this SCSI-subsystem is still available and assigns this I/O- - area to the SCSI-subsystem. There are always 8 sequential I/O-addresses - taken for each individual SCSI-subsystem found, which are: - - Offset Type Permissions - 0 Command Interface Register 1 Read/Write - 1 Command Interface Register 2 Read/Write - 2 Command Interface Register 3 Read/Write - 3 Command Interface Register 4 Read/Write - 4 Attention Register Read/Write - 5 Basic Control Register Read/Write - 6 Interrupt Status Register Read - 7 Basic Status Register Read - - After the I/O-address range is assigned, the host-adapter is assigned - to a local structure which keeps all adapter information needed for the - driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun - and the adapters' ldn tables are initialized and get probed afterwards by - the check_devices() function. If no further adapters are found, - ibmmca_detect() quits. - - 2.2 Physical Units, Logical Units, and Logical Devices - ------------------------------------------------------ - There can be up to 56 devices on the SCSI bus (besides the adapter): - there are up to 7 "physical units" (each identified by physical unit - number or pun, also called the scsi id, this is the number you select - with hardware jumpers), and each physical unit can have up to 8 - "logical units" (each identified by logical unit number, or lun, - between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two - busses and provides support for 30 logical devices at the same time, where - in wide-addressing mode you can have 16 puns with 32 luns on each device. - This section describes the handling of devices on non-F/W adapters. - Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter - which means a lot of possible devices for such a small machine. - - Typically the adapter has pun=7, so puns of other physical units - are between 0 and 6(15). On a wide-adapter a pun higher than 7 is - possible, but is normally not used. Almost all physical units have only - one logical unit, with lun=0. A CD-ROM jukebox would be an example of a - physical unit with more than one logical unit. - - The embedded microprocessor of the IBM SCSI-subsystem hides the complex - two-dimensional (pun,lun) organization from the operating system. - When the machine is powered-up (or rebooted), the embedded microprocessor - checks, on its own, all 56 possible (pun,lun) combinations, and the first - 15 devices found are assigned into a one-dimensional array of so-called - "logical devices", identified by "logical device numbers" or ldn. The last - ldn=15 is reserved for the subsystem itself. Wide adapters may have - to check up to 15 * 8 = 120 pun/lun combinations. - - 2.3 SCSI-Device Recognition and Dynamical ldn Assignment - -------------------------------------------------------- - One consequence of information hiding is that the real (pun,lun) - numbers are also hidden. The two possibilities to get around this problem - are to offer fake pun/lun combinations to the operating system or to - delete the whole mapping of the adapter and to reassign the ldns, using - the immediate assign command of the SCSI-subsystem for probing through - all possible pun/lun combinations. An ldn is a "logical device number" - which is used by IBM SCSI-subsystems to access some valid SCSI-device. - At the beginning of the development of this driver, the following approach - was used: - - First, the driver checked the ldn's (0 to 6) to find out which ldn's - have devices assigned. This was done by the functions check_devices() and - device_exists(). The interrupt handler has a special paragraph of code - (see local_checking_phase_flag) to assist in the checking. Assume, for - example, that three logical devices were found assigned at ldn 0, 1, 2. - These are presented to the upper layer of Linux SCSI driver - as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0). - On the other hand, if the upper layer issues a command to device - say (4,0), this driver returns DID_NO_CONNECT error. - - In a second step of the driver development, the following improvement has - been applied: The first approach limited the number of devices to 7, far - fewer than the 15 that it could use, then it just mapped ldn -> - (ldn/8,ldn%8) for pun,lun. We ended up with a real mishmash of puns - and luns, but it all seemed to work. - - The latest development, which is implemented from the driver version 3.0 - and later, realizes the device recognition in the following way: - The physical SCSI-devices on the SCSI-bus are probed via immediate_assign- - and device_inquiry-commands, that is all implemented in a completely new - made check_devices() subroutine. This delivers an exact map of the physical - SCSI-world that is now stored in the get_scsi[][]-array. This means, - that the once hidden pun,lun assignment is now known to this driver. - It no longer believes in default-settings of the subsystem and maps all - ldns to existing pun,lun "by foot". This assures full control of the ldn - mapping and allows dynamical remapping of ldns to different pun,lun, if - there are more SCSI-devices installed than ldns available (n>15). The - ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0, - excluding the pun of the subsystem. This assures, that at least simple - SCSI-installations have optimum access-speed and are not touched by - dynamical remapping. The ldns 7 to 14 are put to existing devices with - lun>0 or to non-existing devices, in order to satisfy the subsystem, if - there are less than 15 SCSI-devices connected. In the case of more than 15 - devices, the dynamical mapping goes active. If the get_scsi[][] reports a - device to be existent, but it has no ldn assigned, it gets an ldn out of 7 - to 14. The numbers are assigned in cyclic order, therefore it takes 8 - dynamical reassignments on the SCSI-devices until a certain device - loses its ldn again. This assures that dynamical remapping is avoided - during intense I/O between up to 15 SCSI-devices (means pun,lun - combinations). A further advantage of this method is that people who - build their kernel without probing on all luns will get what they expect, - because the driver just won't assign everything with lun>0 when - multiple lun probing is inactive. - - 2.4 SCSI-Device Order - --------------------- - Because of the now correct recognition of physical pun,lun, and - their report to mid-level- and higher-level-drivers, the new reported puns - can be different from the old, faked puns. Therefore, Linux will eventually - change /dev/sdXXX assignments and prompt you for corrupted superblock - repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!! - You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file - entries right. After that, the system should come up as errorfree as before. - If your boot-partition is not coming up, also edit the /etc/lilo.conf-file - in a Linux session booted on old kernel and run lilo before reboot. Check - lilo.conf anyway to get boot on other partitions with foreign OSes right - again. But there exists a feature of this driver that allows you to change - the assignment order of the SCSI-devices by flipping the PUN-assignment. - See the next paragraph for a description. - - The problem for this is, that Linux does not assign the SCSI-devices in the - way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to - the device with at minimum id 0. But the first drive should be at id 6, - because for historical reasons, drive at id 6 has, by hardware, the highest - priority and a drive at id 0 the lowest. IBM was one of the rare producers, - where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most - other producers' BIOS does not (I think even Adaptec-BIOS). The - IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the - kernel enables to choose the preferred way of SCSI-device-assignment. - Defining this flag would result in Linux determining the devices in the - same order as DOS and OS/2 does on your MCA-machine. This is also standard - on most industrial computers and OSes, like e.g. OS-9. Leaving this flag - undefined will get your devices ordered in the default way of Linux. See - also the remarks of Chris Beauregard from Dec 15, 1997 and the followups - in section 3. - - 2.5 Regular SCSI-Command-Processing - ----------------------------------- - Only three functions get involved: ibmmca_queuecommand(), issue_cmd(), - and interrupt_handler(). - - The upper layer issues a scsi command by calling function - ibmmca_queuecommand(). This function fills a "subsystem control block" - (scb) and calls a local function issue_cmd(), which writes a scb - command into subsystem I/O ports. Once the scb command is carried out, - the interrupt_handler() is invoked. If a device is determined to be - existant and it has not assigned any ldn, it gets one dynamically. - For this, the whole stuff is done in ibmmca_queuecommand(). - - 2.6 Abort & Reset Commands - -------------------------- - These are implemented with busy waiting for interrupt to arrive. - ibmmca_reset() and ibmmca_abort() do not work sufficiently well - up to now and need still a lot of development work. This seems - to be a problem with other low-level SCSI drivers too, however - this should be no excuse. - - 2.7 Disk Geometry - ----------------- - The ibmmca_biosparams() function should return the same disk geometry - as the bios. This is needed for fdisk, etc. The returned geometry is - certainly correct for disks smaller than 1 gigabyte. In the meantime, - it has been proved, that this works fine even with disks larger than - 1 gigabyte. - - 2.8 Kernel Boot Option - ---------------------- - The function ibmmca_scsi_setup() is called if option ibmmcascsi=n - is passed to the kernel. See file linux/init/main.c for details. - - 2.9 Driver Module Support - ------------------------- - Is implemented and tested by K. Kudielka. This could probably not work - on kernels <2.1.0. - - 2.10 Multiple Hostadapter Support - --------------------------------- - This driver supports up to eight interfaces of type IBM-SCSI-Subsystem. - Integrated-, and MCA-adapters are automatically recognized. Unrecognizable - IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters. - - 2.11 /proc/scsi-Filesystem Information - -------------------------------------- - Information about the driver condition is given in - /proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information. - - This table is quite informative for interested users. It shows the load - of commands on the subsystem and whether you are running the bypassed - (software) or integrated (hardware) SCSI-command set (see below). The - amount of accesses is shown. Read, write, modeselect is shown separately - in order to help debugging problems with CD-ROMs or tapedrives. - - The following table shows the list of 15 logical device numbers, that are - used by the SCSI-subsystem. The load on each ldn is shown in the table, - again, read and write commands are split. The last column shows the amount - of reassignments, that have been applied to the ldns, if you have more than - 15 pun/lun combinations available on the SCSI-bus. - - The last two tables show the pun/lun map and the positions of the ldns - on this pun/lun map. This may change during operation, when a ldn is - reassigned to another pun/lun combination. If the necessity for dynamical - assignments is set to 'no', the ldn structure keeps static. - - 2.12 /proc/mca-Filesystem Information - ------------------------------------- - The slot-file contains all default entries and in addition chip and I/O- - address information of the SCSI-subsystem. This information is provided - by ibmmca_getinfo(). - - 2.13 Supported IBM SCSI-Subsystems - ---------------------------------- - The following IBM SCSI-subsystems are supported by this driver: - - - IBM Fast/Wide SCSI-2 Adapter - - IBM 7568 Industrial Computer SCSI Adapter w/Cache - - IBM Expansion Unit SCSI Controller - - IBM SCSI Adapter w/Cache - - IBM SCSI Adapter - - IBM Integrated SCSI Controller - - All clones, 100% compatible with the chipset and subsystem command - system of IBM SCSI-adapters (forced detection) - - 2.14 Linux Kernel Versions - -------------------------- - The IBM SCSI-subsystem low level driver is prepared to be used with - all versions of Linux between 2.0.x and 2.4.x. The compatibility checks - are fully implemented up from version 3.1e of the driver. This means, that - you just need the latest ibmmca.h and ibmmca.c file and copy it in the - linux/drivers/scsi directory. The code is automatically adapted during - kernel compilation. This is different from kernel 2.4.0! Here version - 4.0 or later of the driver must be used for kernel 2.4.0 or later. Version - 4.0 or later does not work together with older kernels! Driver versions - older than 4.0 do not work together with kernel 2.4.0 or later. They work - on all older kernels. - - 3 Code History - -------------- - Jan 15 1996: First public release. - - Martin Kolinek - - Jan 23 1996: Scrapped code which reassigned scsi devices to logical - device numbers. Instead, the existing assignment (created - when the machine is powered-up or rebooted) is used. - A side effect is that the upper layer of Linux SCSI - device driver gets bogus scsi ids (this is benign), - and also the hard disks are ordered under Linux the - same way as they are under dos (i.e., C: disk is sda, - D: disk is sdb, etc.). - - Martin Kolinek - - I think that the CD-ROM is now detected only if a CD is - inside CD_ROM while Linux boots. This can be fixed later, - once the driver works on all types of PS/2's. - - Martin Kolinek - - Feb 7 1996: Modified biosparam function. Fixed the CD-ROM detection. - For now, devices other than harddisk and CD_ROM are - ignored. Temporarily modified abort() function - to behave like reset(). - - Martin Kolinek - - Mar 31 1996: The integrated scsi subsystem is correctly found - in PS/2 models 56,57, but not in model 76. Therefore - the ibmmca_scsi_setup() function has been added today. - This function allows the user to force detection of - scsi subsystem. The kernel option has format - ibmmcascsi=n - where n is the scsi_id (pun) of the subsystem. Most likely, n is 7. - - Martin Kolinek - - Aug 21 1996: Modified the code which maps ldns to (pun,0). It was - insufficient for those of us with CD-ROM changers. - - Chris Beauregard - - Dec 14 1996: More improvements to the ldn mapping. See check_devices - for details. Did more fiddling with the integrated SCSI detection, - but I think it's ultimately hopeless without actually testing the - model of the machine. The 56, 57, 76 and 95 (ultimedia) all have - different integrated SCSI register configurations. However, the 56 - and 57 are the only ones that have problems with forced detection. - - Chris Beauregard - - Mar 8-16 1997: Modified driver to run as a module and to support - multiple adapters. A structure, called ibmmca_hostdata, is now - present, containing all the variables, that were once only - available for one single adapter. The find_subsystem-routine has vanished. - The hardware recognition is now done in ibmmca_detect directly. - This routine checks for presence of MCA-bus, checks the interrupt - level and continues with checking the installed hardware. - Certain PS/2-models do not recognize a SCSI-subsystem automatically. - Hence, the setup defined by command-line-parameters is checked first. - Thereafter, the routine probes for an integrated SCSI-subsystem. - Finally, adapters are checked. This method has the advantage to cover all - possible combinations of multiple SCSI-subsystems on one MCA-board. Up to - eight SCSI-subsystems can be recognized and announced to the upper-level - drivers with this improvement. A set of defines made changes to other - routines as small as possible. - - Klaus Kudielka - - May 30 1997: (v1.5b) - 1) SCSI-command capability enlarged by the recognition of MODE_SELECT. - This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which - allows data to be written from the system to the device. It is a - necessary step to be allowed to set blocksize of SCSI-tape-drives and - the tape-speed, without confusing the SCSI-Subsystem. - 2) The recognition of a tape is included in the check_devices routine. - This is done by checking for TYPE_TAPE, that is already defined in - the kernel-scsi-environment. The markup of a tape is done in the - global ldn_is_tape[] array. If the entry on index ldn - is 1, there is a tapedrive connected. - 3) The ldn_is_tape[] array is necessary to distinguish between tape- and - other devices. Fixed blocklength devices should not cause a problem - with the SCB-command for read and write in the ibmmca_queuecommand - subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for - the tape-devices, as recommended by IBM in this Technical Reference, - mentioned below. (IBM recommends to avoid using the read/write of the - subsystem, but the fact was, that read/write causes a command error from - the subsystem and this causes kernel-panic.) - 4) In addition, I propose to use the ldn instead of a fix char for the - display of PS2_DISK_LED_ON(). On 95, one can distinguish between the - devices that are accessed. It shows activity and easyfies debugging. - The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2 - (I do not know yet the type). Optimization and CD-ROM audio-support, - I am working on ... - - Michael Lang - - June 19 1997: (v1.6b) - 1) Submitting the extra-array ldn_is_tape[] -> to the local ld[] - device-array. - 2) CD-ROM Audio-Play seems to work now. - 3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code - 0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears - also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that - the problem is independent of the low-level-driver/bus-architecture. - 4) Hexadecimal ldn on PS/2-95 LED-display. - 5) Fixing of the PS/2-LED on/off that it works right with tapedrives and - does not confuse the disk_rw_in_progress counter. - - Michael Lang - - June 21 1997: (v1.7b) - 1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the - outer-world about operational load statistics on the different ldns, - seen by the driver. Everybody that has more than one IBM-SCSI should - test this, because I only have one and cannot see what happens with more - than one IBM-SCSI hosts. - 2) Definition of a driver version-number to have a better recognition of - the source when there are existing too much releases that may confuse - the user, when reading about release-specific problems. Up to know, - I calculated the version-number to be 1.7. Because we are in BETA-test - yet, it is today 1.7b. - 3) Sorry for the heavy bug I programmed on June 19 1997! After that, the - CD-ROM did not work any more! The C7-command was a fake impression - I got while programming. Now, the READ and WRITE commands for CD-ROM are - no longer running over the subsystem, but just over - IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts - much faster(!) and hopefully all fancy multimedia-functions, like direct - digital recording from audio-CDs also work. (I tried it with cdda2wav - from the cdwtools-package and it filled up the harddisk immediately :-).) - To easify boolean logics, a further local device-type in ld[], called - is_cdrom has been included. - 4) If one uses a SCSI-device of unsupported type/commands, one - immediately runs into a kernel-panic caused by Command Error. To better - understand which SCSI-command caused the problem, I extended this - specific panic-message slightly. - - Michael Lang - - June 25 1997: (v1.8b) - 1) Some cosmetic changes for the handling of SCSI-device-types. - Now, also CD-Burners / WORMs and SCSI-scanners should work. For - MO-drives I have no experience, therefore not yet supported. - In logical_devices I changed from different type-variables to one - called 'device_type' where the values, corresponding to scsi.h, - of a SCSI-device are stored. - 2) There existed a small bug, that maps a device, coming after a SCSI-tape - wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong - -> problem removed. - 3) Extension of the logical_device structure. Now it contains also device, - vendor and revision-level of a SCSI-device for internal usage. - - Michael Lang - - June 26-29 1997: (v2.0b) - 1) The release number 2.0b is necessary because of the completely new done - recognition and handling of SCSI-devices with the adapter. As I got - from Chris the hint, that the subsystem can reassign ldns dynamically, - I remembered this immediate_assign-command, I found once in the handbook. - Now, the driver first kills all ldn assignments that are set by default - on the SCSI-subsystem. After that, it probes on all puns and luns for - devices by going through all combinations with immediate_assign and - probing for devices, using device_inquiry. The found physical(!) pun,lun - structure is stored in get_scsi[][] as device types. This is followed - by the assignment of all ldns to existing SCSI-devices. If more ldns - than devices are available, they are assigned to non existing pun,lun - combinations to satisfy the adapter. With this, the dynamical mapping - was possible to implement. (For further info see the text in the - source code and in the description below. Read the description - below BEFORE installing this driver on your system!) - 2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION. - 3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID - (pun) of the accessed SCSI-device. This is now senseful, because the - pun known within the driver is exactly the pun of the physical device - and no longer a fake one. - 4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where - hit-statistics of ldns is shown and a second part, where the maps of - physical and logical SCSI-devices are displayed. This could be very - interesting, when one is using more than 15 SCSI-devices in order to - follow the dynamical remapping of ldns. - - Michael Lang - - June 26-29 1997: (v2.0b-1) - 1) I forgot to switch the local_checking_phase_flag to 1 and back to 0 - in the dynamical remapping part in ibmmca_queuecommand for the - device_exist routine. Sorry. - - Michael Lang - - July 1-13 1997: (v3.0b,c) - 1) Merging of the driver-developments of Klaus Kudielka and Michael Lang - in order to get a optimum and unified driver-release for the - IBM-SCSI-Subsystem-Adapter(s). - For people, using the Kernel-release >=2.1.0, module-support should - be no problem. For users, running under <2.1.0, module-support may not - work, because the methods have changed between 2.0.x and 2.1.x. - 2) Added some more effective statistics for /proc-output. - 3) Change typecasting at necessary points from (unsigned long) to - virt_to_bus(). - 4) Included #if... at special points to have specific adaption of the - driver to kernel 2.0.x and 2.1.x. It should therefore also run with - later releases. - 5) Magneto-Optical drives and medium-changers are also recognized, now. - Therefore, we have a completely gapfree recognition of all SCSI- - device-types, that are known by Linux up to kernel 2.1.31. - 6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within - the configuration, each connected SCSI-device will get a reset command - during boottime. This can be necessary for some special SCSI-devices. - This flag should be included in Config.in. - (See also the new Config.in file.) - Probable next improvement: bad disk handler. - - Michael Lang - - Sept 14 1997: (v3.0c) - 1) Some debugging and speed optimization applied. - - Michael Lang - - Dec 15, 1997 - - chrisb@truespectra.com - - made the front panel display thingy optional, specified from the - command-line via ibmmcascsi=display. Along the lines of the /LED - option for the OS/2 driver. - - fixed small bug in the LED display that would hang some machines. - - reversed ordering of the drives (using the - IBMMCA_SCSI_ORDER_STANDARD define). This is necessary for two main - reasons: - - users who've already installed Linux won't be screwed. Keep - in mind that not everyone is a kernel hacker. - - be consistent with the BIOS ordering of the drives. In the - BIOS, id 6 is C:, id 0 might be D:. With this scheme, they'd be - backwards. This confuses the crap out of those heathens who've - got a impure Linux installation (which, <wince>, I'm one of). - This whole problem arises because IBM is actually non-standard with - the id to BIOS mappings. You'll find, in fdomain.c, a similar - comment about a few FD BIOS revisions. The Linux (and apparently - industry) standard is that C: maps to scsi id (0,0). Let's stick - with that standard. - - Since this is technically a branch of my own, I changed the - version number to 3.0e-cpb. - - Jan 17, 1998: (v3.0f) - 1) Addition of some statistical info for /proc in proc_info. - 2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15 - 1997. In fact, IBM is right, concerning the assignment of SCSI-devices - to driveletters. It is conform to the ANSI-definition of the SCSI- - standard to assign drive C: to SCSI-id 6, because it is the highest - hardware priority after the hostadapter (that has still today by - default everywhere id 7). Also realtime-operating systems that I use, - like LynxOS and OS9, which are quite industrial systems use top-down - numbering of the harddisks, that is also starting at id 6. Now, one - sits a bit between two chairs. On one hand side, using the define - IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to - the IBM- and ANSI-SCSI-standard and keeps this driver downward - compatible to older releases, on the other hand side, people is quite - habituated in believing that C: is assigned to (0,0) and much other - SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD - define out of the driver and put it into Config.in as subitem of - 'IBM SCSI support'. A help, added to Documentation/Configure.help - explains the differences between saying 'y' or 'n' to the user, when - IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to - choose the way of assignment, depending on his own situation and gusto. - 3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is - now called IBMMCA_SCSI_DEV_RESET. - 4) Optimization of proc_info and its subroutines. - 5) Added more in-source-comments and extended the driver description by - some explanation about the SCSI-device-assignment problem. - - Michael Lang - - Jan 18, 1998: (v3.0g) - 1) Correcting names to be absolutely conform to the later 2.1.x releases. - This is necessary for - IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET - IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD - - Michael Lang - - Jan 18, 1999: (v3.1 MCA-team internal) - 1) The multiple hosts structure is accessed from every subroutine, so there - is no longer the address of the device structure passed from function - to function, but only the hostindex. A call by value, nothing more. This - should really be understood by the compiler and the subsystem should get - the right values and addresses. - 2) The SCSI-subsystem detection was not complete and quite hugely buggy up - to now, compared to the technical manual. The interpretation of the pos2 - register is not as assumed by people before, therefore, I dropped a note - in the ibmmca_detect function to show the registers' interpretation. - The pos-registers of integrated SCSI-subsystems do not contain any - information concerning the IO-port offset, really. Instead, they contain - some info about the adapter, the chip, the NVRAM .... The I/O-port is - fixed to 0x3540 - 0x3547. There can be more than one adapters in the - slots and they get an offset for the I/O area in order to get their own - I/O-address area. See chapter 2 for detailed description. At least, the - detection should now work right, even on models other than 95. The 95ers - came happily around the bug, as their pos2 register contains always 0 - in the critical area. Reserved bits are not allowed to be interpreted, - therefore, IBM is allowed to set those bits as they like and they may - really vary between different PS/2 models. So, now, no interpretation - of reserved bits - hopefully no trouble here anymore. - 3) The command error, which you may get on models 55, 56, 57, 70, 77 and - P70 may have been caused by the fact, that adapters of older design do - not like sending commands to non-existing SCSI-devices and will react - with a command error as a sign of protest. While this error is not - present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI - Adapters. Therefore, I implemented a workaround to forgive those - adapters their protests, but it is marked up in the statistics, so - after a successful boot, you can see in /proc/scsi/ibmmca/<host_number> - how often the command errors have been forgiven to the SCSI-subsystem. - If the number is bigger than 0, you have a SCSI subsystem of older - design, what should no longer matter. - 4) ibmmca_getinfo() has been adapted very carefully, so it shows in the - slotn file really, what is senseful to be presented. - 5) ibmmca_register() has been extended in its parameter list in order to - pass the right name of the SCSI-adapter to Linux. - - Michael Lang - - Feb 6, 1999: (v3.1) - 1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for - the delayed release, but it was not finished with the release of - Kernel 2.2.0. - - Michael Lang - - Feb 10, 1999 (v3.1) - 1) Added a new commandline parameter called 'bypass' in order to bypass - every integrated subsystem SCSI-command consequently in case of - troubles. - 2) Concatenated read_capacity requests to the harddisks. It gave a lot - of troubles with some controllers and after I wanted to apply some - extensions, it jumped out in the same situation, on my w/cache, as like - on D. Weinehalls' Model 56, having integrated SCSI. This gave me the - decisive hint to move the code-part out and declare it global. Now - it seems to work far better and more stable. Let us see what - the world thinks of it... - 3) By the way, only Sony DAT-drives seem to show density code 0x13. A - test with a HP drive gave right results, so the problem is vendor- - specific and not a problem of the OS or the driver. - - Michael Lang - - Feb 18, 1999 (v3.1d) - 1) The abort command and the reset function have been checked for - inconsistencies. From the logical point of thinking, they work - at their optimum, now, but as the subsystem does not answer with an - interrupt, abort never finishes, sigh... - 2) Everything, that is accessed by a busmaster request from the adapter - is now declared as global variable, even the return-buffer in the - local checking phase. This assures, that no accesses to undefined memory - areas are performed. - 3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to - avoid memory-pointers for the areas higher than 16MByte in order to - be sure, it also works on 16-Bit Microchannel bus systems. - 4) A lot of small things have been found, but nothing that endangered the - driver operations. Just it should be more stable, now. - - Michael Lang - - Feb 20, 1999 (v3.1e) - 1) I took the warning from the Linux Kernel Hackers Guide serious and - checked the cmd->result return value to the done-function very carefully. - It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if - some error appeared, else it is undefined. Now, this is fixed. Before - any SCB command gets queued, the tsb.dev_status is set to 0, so the - cmd->result won't screw up Linux higher level drivers. - 2) The reset-function has slightly improved. This is still planed for - abort. During the abort and the reset function, no interrupts are - allowed. This is however quite hard to cope with, so the INT-status - register is read. When the interrupt gets queued, one can find its - status immediately on that register and is enabled to continue in the - reset function. I had no chance to test this really, only in a bogus - situation, I got this function running, but the situation was too much - worse for Linux :-(, so tests will continue. - 3) Buffers got now consistent. No open address mapping, as before and - therefore no further troubles with the unassigned memory segmentation - faults that scrambled probes on 95XX series and even on 85XX series, - when the kernel is done in a not so perfectly fitting way. - 4) Spontaneous interrupts from the subsystem, appearing without any - command previously queued are answered with a DID_BAD_INTR result. - 5) Taken into account ZP Gus' proposals to reverse the SCSI-device - scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed - by him, I implemented it in a slightly derived way, which offers in - addition more flexibility. - - Michael Lang - - Apr 23, 2000 (v3.2pre1) - 1) During a very long time, I collected a huge amount of bug reports from - various people, trying really quite different things on their SCSI- - PS/2s. Today, all these bug reports are taken into account and should be - mostly solved. The major topics were: - - Driver crashes during boottime by no obvious reason. - - Driver panics while the midlevel-SCSI-driver is trying to inquire - the SCSI-device properties, even though hardware is in perfect state. - - Displayed info for the various slot-cards is interpreted wrong. - The main reasons for the crashes were two: - 1) The commands to check for device information like INQUIRY, - TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices - to deliver information of up to 255 bytes. Midlevel drivers offer - 1024 bytes of space for the answer, but the IBM-SCSI-adapters do - not accept this, as they stick quite near to ANSI-SCSI and report - a COMMAND_ERROR message which causes the driver to panic. The main - problem was located around the INQUIRY command. Now, for all the - mentioned commands, the buffersize sent to the adapter is at - maximum 255 which seems to be a quite reasonable solution. - TEST_UNIT_READY gets a buffersize of 0 to make sure that no - data is transferred in order to avoid any possible command failure. - 2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send - a REQUEST_SENSE in order to see where the problem is located. This - REQUEST_SENSE may have various length in its answer-buffer. IBM - SCSI-subsystems report a command failure if the returned buffersize - is different from the sent buffersize, but this can be suppressed by - a special bit, which is now done and problems seem to be solved. - 2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on - 2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes. - 3) Commandline-parameters are recognized again, even under Kernel 2.3.x or - higher. - - Michael Lang - - April 27, 2000 (v3.2pre2) - 1) Bypassed commands get read by the adapter by one cycle instead of two. - This increases SCSI-performance. - 2) Synchronous datatransfer is provided for sure to be 5 MHz on older - SCSI and 10 MHz on internal F/W SCSI-adapter. - 3) New commandline parameters allow to force the adapter to slow down while - in synchronous transfer. Could be helpful for very old devices. - - Michael Lang - - June 2, 2000 (v3.2pre5) - 1) Added Jim Shorney's contribution to make the activity indicator - flashing in addition to the LED-alphanumeric display-panel on - models 95A. To be enabled to choose this feature freely, a new - commandline parameter is added, called 'activity'. - 2) Added the READ_CONTROL bit for test_unit_ready SCSI-command. - 3) Added some suppress_exception bits to read_device_capacity and - all device_inquiry occurrences in the driver code. - 4) Complaints about the various KERNEL_VERSION implementations are - taken into account. Every local_LinuxKernelVersion occurrence is - now replaced by KERNEL_VERSION, defined in linux/version.h. - Corresponding changes were applied to ibmmca.h, too. This was a - contribution to all kernel-parts by Philipp Hahn. - - Michael Lang - - July 17, 2000 (v3.2pre8) - A long period of collecting bug reports from all corners of the world - now lead to the following corrections to the code: - 1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this - was that it is possible to disable Fast-SCSI for the external bus. - The feature-control command, where this crash appeared regularly, tried - to set the maximum speed of 10MHz synchronous transfer speed and that - reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now, - the feature-command probes down from maximum speed until the adapter - stops to complain, which is at the same time the maximum possible - speed selected in the reference program. So, F/W external can run at - 5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the - COMMAND ERROR message is used to detect if the adapter does not complain. - 2) Up to now, only combined busmode is supported, if you use external - SCSI-devices, attached to the F/W-controller. If dual bus is selected, - only the internal SCSI-devices get accessed by Linux. For most - applications, this should do fine. - 3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W - bus on the F/W adapter. If F/W adapter is detected, the driver - automatically uses the extended PUN/LUN <-> LDN mapping tables, which - are now new from 3.2pre8. This allows PUNs between 0 and 15 and should - provide more fun with the F/W adapter. - 4) Several machines use the SCSI: POS registers for internal/undocumented - storage of system relevant info. This confused the driver, mainly on - models 9595, as it expected no onboard SCSI only, if all POS in - the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism - to check for integrated SCSI is much more restrictive and these problems - should be history. - - Michael Lang - - July 18, 2000 (v3.2pre9) - This develop rather quickly at the moment. Two major things were still - missing in 3.2pre8: - 1) The adapter PUN for F/W adapters has 4-bits, while all other adapters - have 3-bits. This is now taken into account for F/W. - 2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should - normally get the inverse probing order of your devices on the SCSI-bus. - The ANSI device order gets scrambled in version 3.2pre8!! Now, a new - and tested algorithm inverts the device-order on the SCSI-bus and - automatically avoids accidental access to whatever SCSI PUN the adapter - is set and works with SCSI- and Wide-SCSI-addressing. - - Michael Lang - - July 23, 2000 (v3.2pre10 unpublished) - 1) LED panel display supports wide-addressing in ibmmca=display mode. - 2) Adapter-information and autoadaption to address-space is done. - 3) Auto-probing for maximum synchronous SCSI transfer rate is working. - 4) Optimization to some embedded function calls is applied. - 5) Added some comment for the user to wait for SCSI-devices being probed. - 6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but... - - Michael Lang - - July 26, 2000 (v3.2pre11) - 1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and - a model 9595. Asking around in the community, nobody except of me has - seen such errors. Weird, but I am trying to recompile everything on - the model 9595. Maybe, as I use a specially modified gcc, that could - cause problems. But, it was not the reason. The true background was, - that the kernel was compiled for i386 and the 9595 has a 486DX-2. - Normally, no troubles should appear, but for this special machine, - only the right processor support is working fine! - 2) Previous problems with synchronous speed, slowing down from one adapter - to the next during probing are corrected. Now, local variables store - the synchronous bitmask for every single adapter found on the MCA bus. - 3) LED alphanumeric panel support for XX95 systems is now showing some - alive rotator during boottime. This makes sense, when no monitor is - connected to the system. You can get rid of all display activity, if - you do not use any parameter or just ibmmcascsi=activity, for the - harddrive activity LED, existent on all PS/2, except models 8595-XXX. - If no monitor is available, please use ibmmcascsi=display, which works - fine together with the linuxinfo utility for the LED-panel. - - Michael Lang - - July 29, 2000 (v3.2) - 1) Submission of this driver for kernel 2.4test-XX and 2.2.17. - - Michael Lang - - December 28, 2000 (v3.2d / v4.0) - 1) The interrupt handler had some wrong statement to wait for. This - was done due to experimental reasons during 3.2 development but it - has shown that this is not stable enough. Going back to wait for the - adapter to be not busy is best. - 2) Inquiry requests can be shorter than 255 bytes of return buffer. Due - to a bug in the ibmmca_queuecommand routine, this buffer was forced - to 255 at minimum. If the memory address, this return buffer is pointing - to does not offer more space, invalid memory accesses destabilized the - kernel. - 3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary - to remove old kernel version dependent waste from the driver. 3.2d is - only distributed with older kernels but keeps compatibility with older - kernel versions. 4.0 and higher versions cannot be used with older - kernels anymore!! You must have at least kernel 2.4.0!! - 4) The commandline argument 'bypass' and all its functionality got removed - in version 4.0. This was never really necessary, as all troubles were - based on non-command related reasons up to now, so bypassing commands - did not help to avoid any bugs. It is kept in 3.2X for debugging reasons. - 5) Dynamic reassignment of ldns was again verified and analyzed to be - completely inoperational. This is corrected and should work now. - 6) All commands that get sent to the SCSI adapter were verified and - completed in such a way, that they are now completely conform to the - demands in the technical description of IBM. Main candidates were the - DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must - be transferred by bypassing the internal command buffer of the adapter - or else the response can be a random result. GET_POS_INFO would be more - safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this - is not allowed by the technical references of IBM. (Sorry, folks, the - model 80 problem is still a task to be solved in a different way.) - 7) v3.2d is still hold back for some days for testing, while 4.0 is - released. - - Michael Lang - - January 3, 2001 (v4.0a) - 1) A lot of complains after the 2.4.0-prerelease kernel came in about - the impossibility to compile the driver as a module. This problem is - solved. In combination with that problem, some unprecise declaration - of the function option_setup() gave some warnings during compilation. - This is solved, too by a forward declaration in ibmmca.c. - 2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and - was entirely removed. - 3) Some switch statements got optimized in code, as some minor variables - in internal SCSI-command handlers. - - Michael Lang - - 4 To do - ------- - - IBM SCSI-2 F/W external SCSI bus support in separate mode! - - It seems that the handling of bad disks is really bad - - non-existent, in fact. However, a low-level driver cannot help - much, if such things happen. - - 5 Users' Manual - --------------- - 5.1 Commandline Parameters - -------------------------- - There exist several features for the IBM SCSI-subsystem driver. - The commandline parameter format is: - - ibmmcascsi=<command1>,<command2>,<command3>,... - - where commandN can be one of the following: - - display Owners of a model 95 or other PS/2 systems with an - alphanumeric LED display may set this to have their - display showing the following output of the 8 digits: - - ------DA - - where '-' stays dark, 'D' shows the SCSI-device id - and 'A' shows the SCSI hostindex, being currently - accessed. During boottime, this will give the message - - SCSIini* - - on the LED-panel, where the * represents a rotator, - showing the activity during the probing phase of the - driver which can take up to two minutes per SCSI-adapter. - adisplay This works like display, but gives more optical overview - of the activities on the SCSI-bus. The display will have - the following output: - - 6543210A - - where the numbers 0 to 6 light up at the shown position, - when the SCSI-device is accessed. 'A' shows again the SCSI - hostindex. If display nor adisplay is set, the internal - PS/2 harddisk LED is used for media-activities. So, if - you really do not have a system with a LED-display, you - should not set display or adisplay. Keep in mind, that - display and adisplay can only be used alternatively. It - is not recommended to use this option, if you have some - wide-addressed devices e.g. at the SCSI-2 F/W adapter in - your system. In addition, the usage of the display for - other tasks in parallel, like the linuxinfo-utility makes - no sense with this option. - activity This enables the PS/2 harddisk LED activity indicator. - Most PS/2 have no alphanumeric LED display, but some - indicator. So you should use this parameter to activate it. - If you own model 9595 (Server95), you can have both, the - LED panel and the activity indicator in parallel. However, - some PS/2s, like the 8595 do not have any harddisk LED - activity indicator, which means, that you must use the - alphanumeric LED display if you want to monitor SCSI- - activity. - bypass This is obsolete from driver version 4.0, as the adapters - got that far understood, that the selection between - integrated and bypassed commands should now work completely - correct! For historical reasons, the old description is - kept here: - This commandline parameter forces the driver never to use - SCSI-subsystems' integrated SCSI-command set. Except of - the immediate assign, which is of vital importance for - every IBM SCSI-subsystem to set its ldns right. Instead, - the ordinary ANSI-SCSI-commands are used and passed by the - controller to the SCSI-devices, therefore 'bypass'. The - effort, done by the subsystem is quite bogus and at a - minimum and therefore it should work everywhere. This - could maybe solve troubles with old or integrated SCSI- - controllers and nasty harddisks. Keep in mind, that using - this flag will slow-down SCSI-accesses slightly, as the - software generated commands are always slower than the - hardware. Non-harddisk devices always get read/write- - commands in bypass mode. On the most recent releases of - the Linux IBM-SCSI-driver, the bypass command should be - no longer a necessary thing, if you are sure about your - SCSI-hardware! - normal This is the parameter, introduced on the 2.0.x development - rail by ZP Gu. This parameter defines the SCSI-device - scan order in the new industry standard. This means, that - the first SCSI-device is the one with the lowest pun. - E.g. harddisk at pun=0 is scanned before harddisk at - pun=6, which means, that harddisk at pun=0 gets sda - and the one at pun=6 gets sdb. - ansi The ANSI-standard for the right scan order, as done by - IBM, Microware and Microsoft, scans SCSI-devices starting - at the highest pun, which means, that e.g. harddisk at - pun=6 gets sda and a harddisk at pun=0 gets sdb. If you - like to have the same SCSI-device order, as in DOS, OS-9 - or OS/2, just use this parameter. - fast SCSI-I/O in synchronous mode is done at 5 MHz for IBM- - SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus - should then run at 10 MHz if Fast-SCSI is enabled, - and at 5 MHz if Fast-SCSI is disabled on the external - bus. This is the default setting when nothing is - specified here. - medium Synchronous rate is at 50% approximately, which means - 2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext. - SCSI-bus (when Fast-SCSI speed enabled on external bus). - slow The slowest possible synchronous transfer rate is set. - This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz - for F/W external bus at Fast-SCSI speed on the external - bus. - - A further option is that you can force the SCSI-driver to accept a SCSI- - subsystem at a certain I/O-address with a predefined adapter PUN. This - is done by entering - - commandN = I/O-base - commandN+1 = adapter PUN - - e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem - at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if - the driver does really not recognize your SCSI-adapter! With driver version - 3.2, this recognition of various adapters was hugely improved and you - should try first to remove your commandline arguments of such type with a - newer driver. I bet, it will be recognized correctly. Even multiple and - different types of IBM SCSI-adapters should be recognized correctly, too. - Use the forced detection method only as last solution! - - Examples: - - ibmmcascsi=adisplay - - This will use the advanced display mode for the model 95 LED alphanumeric - display. - - ibmmcascsi=display,0x3558,7 - - This will activate the default display mode for the model 95 LED display - and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558 - with adapter PUN 7. - - 5.2 Troubleshooting - ------------------- - The following FAQs should help you to solve some major problems with this - driver. - - Q: "Reset SCSI-devices at boottime" halts the system at boottime, why? - A: This is only tested with the IBM SCSI Adapter w/cache. It is not - yet proven to run on other adapters, however you may be lucky. - In version 3.1d this has been hugely improved and should work better, - now. Normally you really won't need to activate this flag in the - kernel configuration, as all post 1989 SCSI-devices should accept - the reset-signal, when the computer is switched on. The SCSI- - subsystem generates this reset while being initialized. This flag - is really reserved for users with very old, very strange or self-made - SCSI-devices. - Q: Why is the SCSI-order of my drives mirrored to the device-order - seen from OS/2 or DOS ? - A: It depends on the operating system, if it looks at the devices in - ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or - if it just starts at pun 0 and counts up. If you want to be conform - with OS/2 and DOS, you have to activate this flag in the kernel - configuration or you should set 'ansi' as parameter for the kernel. - The parameter 'normal' sets the new industry standard, starting - from pun 0, scanning up to pun 6. This allows you to change your - opinion still after having already compiled the kernel. - Q: Why can't I find IBM MCA SCSI support in the config menu? - A: You have to activate MCA bus support, first. - Q: Where can I find the latest info about this driver? - A: See the file MAINTAINERS for the current WWW-address, which offers - updates, info and Q/A lists. At this file's origin, the webaddress - was: http://www.staff.uni-mainz.de/mlang/linux.html - Q: My SCSI-adapter is not recognized by the driver, what can I do? - A: Just force it to be recognized by kernel parameters. See section 5.1. - If this really happens, do also send e-mail to the maintainer, as - forced detection should be never necessary. Forced detection is in - principal some flaw of the driver adapter detection and goes into - bug reports. - Q: The driver screws up, if it starts to probe SCSI-devices, is there - some way out of it? - A: Yes, that was some recognition problem of the correct SCSI-adapter - and its I/O base addresses. Upgrade your driver to the latest release - and it should be fine again. - Q: I get a message: panic IBM MCA SCSI: command error .... , what can - I do against this? - A: Previously, I followed the way by ignoring command errors by using - ibmmcascsi=forgiveall, but this command no longer exists and is - obsolete. If such a problem appears, it is caused by some segmentation - fault of the driver, which maps to some unallowed area. The latest - version of the driver should be ok, as most bugs have been solved. - Q: There are still kernel panics, even after having set - ibmmcascsi=forgiveall. Are there other possibilities to prevent - such panics? - A: No, get just the latest release of the driver and it should work - better and better with increasing version number. Forget about this - ibmmcascsi=forgiveall, as also ignorecmd are obsolete.! - Q: Linux panics or stops without any comment, but it is probable, that my - harddisk(s) have bad blocks. - A: Sorry, the bad-block handling is still a feeble point of this driver, - but is on the schedule for development in the near future. - Q: Linux panics while dynamically assigning SCSI-ids or ldns. - A: If you disconnect a SCSI-device from the machine, while Linux is up - and the driver uses dynamical reassignment of logical device numbers - (ldn), it really gets "angry" if it won't find devices, that were still - present at boottime and stops Linux. - Q: The system does not recover after an abort-command has been generated. - A: This is regrettably true, as it is not yet understood, why the - SCSI-adapter does really NOT generate any interrupt at the end of - the abort-command. As no interrupt is generated, the abort command - cannot get finished and the system hangs, sorry, but checks are - running to hunt down this problem. If there is a real pending command, - the interrupt MUST get generated after abort. In this case, it - should finish well. - Q: The system gets in bad shape after a SCSI-reset, is this known? - A: Yes, as there are a lot of prescriptions (see the Linux Hackers' - Guide) what has to be done for reset, we still share the bad shape of - the reset functions with all other low level SCSI-drivers. - Astonishingly, reset works in most cases quite ok, but the harddisks - won't run in synchronous mode anymore after a reset, until you reboot. - Q: Why does my XXX w/Cache adapter not use read-prefetch? - A: Ok, that is not completely possible. If a cache is present, the - adapter tries to use it internally. Explicitly, one can use the cache - with a read prefetch command, maybe in future, but this requires - some major overhead of SCSI-commands that risks the performance to - go down more than it gets improved. Tests with that are running. - Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs. - A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter - was in such a case recognized as integrated SCSI-adapter or something - else, but not as the correct adapter. As the I/O-ports get assigned - wrongly by that reason, the system should crash in most cases. You - should upgrade to the latest release of the SCSI-driver. The - recommended version is 3.2 or later. Here, the F/W support is in - a stable and reliable condition. Wide-addressing is in addition - supported. - Q: I get an Oops message and something like "killing interrupt". - A: The reason for this is that the IBM SCSI-subsystem only sends a - termination status back, if some error appeared. In former releases - of the driver, it was not checked, if the termination status block - is NULL. From version 3.2, it is taken care of this. - Q: I have a F/W adapter and the driver sees my internal SCSI-devices, - but ignores the external ones. - A: Select combined busmode in the IBM config-program and check for that - no SCSI-id on the external devices appears on internal devices. - Reboot afterwards. Dual busmode is supported, but works only for the - internal bus, yet. External bus is still ignored. Take care for your - SCSI-ids. If combined bus-mode is activated, on some adapters, - the wide-addressing is not possible, so devices with ids between 8 - and 15 get ignored by the driver & adapter! - Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck. - A COMMAND ERROR is reported and characters on the screen are missing. - Warm reboot is not possible. Things look like quite weird. - A: Check the processor type of your 9595. If you have an 80486 or 486DX-2 - processor complex on your mainboard and you compiled a kernel that - supports 80386 processors, it is possible, that the kernel cannot - keep track of the PS/2 interrupt handling and stops on an NMI. Just - compile a kernel for the correct processor type of your PS/2 and - everything should be fine. This is necessary even if one assumes, - that some 80486 system should be downward compatible to 80386 - software. - Q: Some commands hang and interrupts block the machine. After some - timeout, the syslog reports that it tries to call abort, but the - machine is frozen. - A: This can be a busy wait bug in the interrupt handler of driver - version 3.2. You should at least upgrade to 3.2c if you use - kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or - later (including all test releases). - Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver - completely refuses to work, reports NMIs, COMMAND ERRORs or other - ambiguous stuff. When reducing the RAM size down below 16 MB, - everything is running smoothly. - A: No real answer, yet. In any case, one should force the kernel to - present SCBs only below the 16 MBytes barrier. Maybe this solves the - problem. Not yet tried, but guessing that it could work. To get this, - set unchecked_isa_dma argument of ibmmca.h from 0 to 1. - - 5.3 Bug reports - -------------- - If you really find bugs in the source code or the driver will successfully - refuse to work on your machine, you should send a bug report to me. The - best for this is to follow the instructions on the WWW-page for this - driver. Fill out the bug-report form, placed on the WWW-page and ship it, - so the bugs can be taken into account with maximum efforts. But, please - do not send bug reports about this driver to Linus Torvalds or Leonard - Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all - SCSI-drivers and won't have the time left to look inside every single - driver to fix a bug and especially DO NOT send modified code to Linus - Torvalds or Alan J. Cox which has not been checked here!!! They are both - quite buried in E-mail (as me, sometimes, too) and one should first check - for problems on my local teststand. Recently, I got a lot of - bug reports for errors in the ibmmca.c code, which I could not imagine, but - a look inside some Linux-distribution showed me quite often some modified - code, which did no longer work on most other machines than the one of the - modifier. Ok, so now that there is maintenance service available for this - driver, please use this address first in order to keep the level of - confusion low. Thank you! - - When you get a SCSI-error message that panics your system, a list of - register-entries of the SCSI-subsystem is shown (from Version 3.1d). With - this list, it is very easy for the maintainer to localize the problem in - the driver or in the configuration of the user. Please write down all the - values from this report and send them to the maintainer. This would really - help a lot and makes life easier concerning misunderstandings. - - Use the bug-report form (see 5.4 for its address) to send all the bug- - stuff to the maintainer or write e-mail with the values from the table. - - 5.4 Support WWW-page - -------------------- - The address of the IBM SCSI-subsystem supporting WWW-page is: - - http://www.staff.uni-mainz.de/mlang/linux.html - - Here you can find info about the background of this driver, patches, - troubleshooting support, news and a bugreport form. Please check that - WWW-page regularly for latest hints. If ever this URL changes, please - refer to the MAINTAINERS file in order to get the latest address. - - For the bugreport, please fill out the formular on the corresponding - WWW-page. Read the dedicated instructions and write as much as you - know about your problem. If you do not like such formulars, please send - some e-mail directly, but at least with the same information as required by - the formular. - - If you have extensive bug reports, including Oops messages and - screen-shots, please feel free to send it directly to the address - of the maintainer, too. The current address of the maintainer is: - - Michael Lang <langa2@kph.uni-mainz.de> - - 6 References - ------------ - IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference, - Common Interfaces", Armonk, September 1991, PN 04G3281, - (available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for - around 40,-DM at "Hallo IBM"). - - IBM Corp., "Personal System/2 Micro Channel SCSI - Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365. - - IBM Corp., "Personal System/2 Micro Channel SCSI - Adapter Technical Reference", Armonk, March 1990, PN 68X2397. - - IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus", - Armonk, March 1994, PN 83G7545. - - Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie- - Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl. - Addison Wesley, 1996. - - Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel - Hill - North Carolina, 1995 - - Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart - 1993 - - Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme * - Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988 - - 7 Credits to - ------------ - 7.1 People - ---------- - Klaus Grimm - who already a long time ago gave me the old code from the - SCSI-driver in order to get it running for some old machine - in our institute. - Martin Kolinek - who wrote the first release of the IBM SCSI-subsystem driver. - Chris Beauregard - who for a long time maintained MCA-Linux and the SCSI-driver - in the beginning. Chris, wherever you are: Cheers to you! - Klaus Kudielka - with whom in the 2.1.x times, I had a quite fruitful - cooperation to get the driver running as a module and to get - it running with multiple SCSI-adapters. - David Weinehall - for his excellent maintenance of the MCA-stuff and the quite - detailed bug reports and ideas for this driver (and his - patience ;-)). - Alan J. Cox - for his bug reports and his bold activities in cross-checking - the driver-code with his teststand. - - 7.2 Sponsors & Supporters - ------------------------- - "Hallo IBM", - IBM-Deutschland GmbH - the service of IBM-Deutschland for customers. Their E-Mail - service is unbeatable. Whatever old stuff I asked for, I - always got some helpful answers. - Karl-Otto Reimers, - IBM Klub - Sparte IBM Geschichte, Sindelfingen - for sending me a copy of the w/Cache manual from the - IBM-Deutschland archives. - Harald Staiger - for his extensive hardware donations which allows me today - still to test the driver in various constellations. - Erich Fritscher - for his very kind sponsoring. - Louis Ohland, - Charles Lasitter - for support by shipping me an IBM SCSI-2 Fast/Wide manual. - In addition, the contribution of various hardware is quite - decessive and will make it possible to add FWSR (RAID) - adapter support to the driver in the near future! So, - complaints about no RAID support won't remain forever. - Yes, folks, that is no joke, RAID support is going to rise! - Erik Weber - for the great deal we made about a model 9595 and the nice - surrounding equipment and the cool trip to Mannheim - second-hand computer market. In addition, I would like - to thank him for his exhaustive SCSI-driver testing on his - 95er PS/2 park. - Anthony Hogbin - for his direct shipment of a SCSI F/W adapter, which allowed - me immediately on the first stage to try it on model 8557 - together with onboard SCSI adapter and some SCSI w/Cache. - Andreas Hotz - for his support by memory and an IBM SCSI-adapter. Collecting - all this together now allows me to try really things with - the driver at maximum load and variety on various models in - a very quick and efficient way. - Peter Jennewein - for his model 30, which serves me as part of my teststand - and his cool remark about how you make an ordinary diskette - drive working and how to connect it to an IBM-diskette port. - Johannes Gutenberg-Universitaet, Mainz & - Institut fuer Kernphysik, Mainz Microtron (MAMI) - for the offered space, the link, placed on the central - homepage and the space to store and offer the driver and - related material and the free working times, which allow - me to answer all your e-mail. - - 8 Trademarks - ------------ - IBM, PS/2, OS/2, Microchannel are registered trademarks of International - Business Machines Corporation - - MS-DOS is a registered trademark of Microsoft Corporation - - Microware, OS-9 are registered trademarks of Microware Systems - - 9 Disclaimer - ------------ - Beside the GNU General Public License and the dependent disclaimers and disclaimers - concerning the Linux-kernel in special, this SCSI-driver comes without any - warranty. Its functionality is tested as good as possible on certain - machines and combinations of computer hardware, which does not exclude, - that data loss or severe damage of hardware is possible while using this - part of software on some arbitrary computer hardware or in combination - with other software packages. It is highly recommended to make backup - copies of your data before using this software. Furthermore, personal - injuries by hardware defects, that could be caused by this SCSI-driver are - not excluded and it is highly recommended to handle this driver with a - maximum of carefulness. - - This driver supports hardware, produced by International Business Machines - Corporation (IBM). - ------- -Michael Lang -(langa2@kph.uni-mainz.de) diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt index aa54f54c4a5..3cc9c7843e1 100644 --- a/Documentation/scsi/libsas.txt +++ b/Documentation/scsi/libsas.txt @@ -398,21 +398,6 @@ struct sas_task { task_done -- callback when the task has finished execution }; -When an external entity, entity other than the LLDD or the -SAS Layer, wants to work with a struct domain_device, it -_must_ call kobject_get() when getting a handle on the -device and kobject_put() when it is done with the device. - -This does two things: - A) implements proper kfree() for the device; - B) increments/decrements the kref for all players: - domain_device - all domain_device's ... (if past an expander) - port - host adapter - pci device - and up the ladder, etc. - DISCOVERY --------- diff --git a/Documentation/scsi/osst.txt b/Documentation/scsi/osst.txt index ad86c6d1e89..00c8ebb2fd1 100644 --- a/Documentation/scsi/osst.txt +++ b/Documentation/scsi/osst.txt @@ -66,7 +66,7 @@ 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 your /etc/modprobe.conf (before 2.6: modules.conf). +to a file under /etc/modprobe.d/ directory. You may find it convenient to create a symbolic link ln -s nosst0 /dev/tape diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt index 032399b16a5..ade046ea7c1 100644 --- a/Documentation/scsi/scsi-changer.txt +++ b/Documentation/scsi/scsi-changer.txt @@ -102,7 +102,7 @@ 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 alot +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. diff --git a/Documentation/scsi/scsi-generic.txt b/Documentation/scsi/scsi-generic.txt index 0a22ab8ea0c..51be20a6a14 100644 --- a/Documentation/scsi/scsi-generic.txt +++ b/Documentation/scsi/scsi-generic.txt @@ -62,7 +62,7 @@ There are two packages of sg utilities: 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 -freshmeat.net +freecode.com Another approach is to look at the applications that use the sg driver. These include cdrecord, cdparanoia, SANE and cdrdao. diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 21e5798526e..2bfd6f6d2d3 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -37,9 +37,6 @@ parameters may be changed at runtime by the command eata= [HW,SCSI] - fd_mcs= [HW,SCSI] - See header of drivers/scsi/fd_mcs.c. - fdomain= [HW,SCSI] See header of drivers/scsi/fdomain.c. @@ -48,9 +45,6 @@ parameters may be changed at runtime by the command gvp11= [HW,SCSI] - ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter - See Documentation/mca.txt. - in2000= [HW,SCSI] See header of drivers/scsi/in2000.c. diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt index 7acbebb17fa..a0c85110a07 100644 --- a/Documentation/scsi/scsi_eh.txt +++ b/Documentation/scsi/scsi_eh.txt @@ -42,20 +42,14 @@ discussion. 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 SCSI midlayer will time it out. +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 -does the following. - - 1. Delete timeout timer. If it fails, it means that timeout timer - has expired and is going to finish the command. Just return. - - 2. Link scmd to per-cpu scsi_done_q using scmd->en_entry - - 3. Raise SCSI_SOFTIRQ +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() @@ -64,10 +58,12 @@ with the command. - SUCCESS scsi_finish_command() is invoked for the command. The - function does some maintenance choirs and notify completion by - calling scmd->done() callback, which, for fs requests, would - be HLD completion callback - sd:sd_rw_intr, sr:rw_intr, - st:st_intr. + 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 @@ -86,33 +82,45 @@ function 1. invokes optional hostt->eh_timed_out() callback. Return value can be one of - - EH_HANDLED - This indicates that eh_timed_out() dealt with the timeout. The - scmd is passed to __scsi_done() and thus linked into per-cpu - scsi_done_q. Normal command completion described in [1-2-1] - follows. + - 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. - - EH_RESET_TIMER + - 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 EH_NOT_HANDLED is taken instead. + limit is reached, action for BLK_EH_NOT_HANDLED is taken instead. - *NOTE* This action is racy as the LLDD could finish the scmd - after the timeout has expired but before it's added back. In - such cases, scsi_done() would think that timeout has occurred - and return without doing anything. We lose completion and the - command will time out again. - - - EH_NOT_HANDLED - This is the same as when eh_timed_out() callback doesn't exist. + - 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-3] How EH takes over +[1-4] How EH takes over scmds enter EH via scsi_eh_scmd_add(), which does the following. @@ -290,7 +298,7 @@ scmd->allowed. 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 inbetween occurrence of CHECK CONDITION and this action. + 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 @@ -320,7 +328,8 @@ scmd->allowed. <<scsi_eh_abort_cmds>> - This action is taken for each timed out command. + 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. diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt index e00192de4d1..f79282fc48d 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt @@ -291,7 +291,7 @@ Transport <-> LLDD Interfaces : Vport support by LLDD: The LLDD indicates support for vports by supplying a vport_create() - function in the transport template. The presense of this function will + 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 diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 570ef2b3d79..d6a9bdeee7f 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -30,7 +30,7 @@ the motherboard (or both). Some aic7xxx based HBAs are dual controllers and thus represent two hosts. Like most modern HBAs, each aic7xxx host has its own PCI device address. [The one-to-one correspondence between a SCSI host and a PCI device is common but not required (e.g. with -ISA or MCA adapters).] +ISA adapters).] The SCSI mid level isolates an LLD from other layers such as the SCSI upper layer drivers and the block layer. @@ -55,11 +55,6 @@ or in the same directory as the C source code. For example to find a url about the USB mass storage driver see the /usr/src/linux/drivers/usb/storage directory. -The Linux kernel source Documentation/DocBook/scsidrivers.tmpl file -refers to this file. With the appropriate DocBook tool-set, this permits -users to generate html, ps and pdf renderings of information within this -file (e.g. the interface functions). - Driver structure ================ Traditionally an LLD for the SCSI subsystem has been at least two files in @@ -887,8 +882,11 @@ Details: * * Calling context: kernel thread * - * Notes: Invoked from scsi_eh thread. No other commands will be - * queued on current host during eh. + * Notes: If 'no_async_abort' is defined this callback + * will be invoked from scsi_eh thread. No other commands + * will then be queued on current host during eh. + * Otherwise it will be called whenever scsi_times_out() + * is called due to a command timeout. * * Optionally defined in: LLD **/ @@ -1044,9 +1042,9 @@ Details: /** - * queuecommand - queue scsi command, invoke 'done' on completion + * queuecommand - queue scsi command, invoke scp->scsi_done on completion + * @shost: pointer to the scsi host object * @scp: pointer to scsi command object - * @done: function pointer to be invoked on completion * * Returns 0 on success. * @@ -1074,42 +1072,45 @@ Details: * * Other types of errors that are detected immediately may be * flagged by setting scp->result to an appropriate value, - * invoking the 'done' callback, and then returning 0 from this - * function. If the command is not performed immediately (and the - * LLD is starting (or will start) the given command) then this - * function should place 0 in scp->result and return 0. + * invoking the scp->scsi_done callback, and then returning 0 + * from this function. If the command is not performed + * immediately (and the LLD is starting (or will start) the given + * command) then this function should place 0 in scp->result and + * return 0. * * Command ownership. If the driver returns zero, it owns the - * command and must take responsibility for ensuring the 'done' - * callback is executed. Note: the driver may call done before - * returning zero, but after it has called done, it may not - * return any value other than zero. If the driver makes a - * non-zero return, it must not execute the command's done - * callback at any time. - * - * Locks: struct Scsi_Host::host_lock held on entry (with "irqsave") - * and is expected to be held on return. + * command and must take responsibility for ensuring the + * scp->scsi_done callback is executed. Note: the driver may + * call scp->scsi_done before returning zero, but after it has + * called scp->scsi_done, it may not return any value other than + * zero. If the driver makes a non-zero return, it must not + * execute the command's scsi_done callback at any time. + * + * Locks: up to and including 2.6.36, struct Scsi_Host::host_lock + * held on entry (with "irqsave") and is expected to be + * held on return. From 2.6.37 onwards, queuecommand is + * called without any locks held. * * Calling context: in interrupt (soft irq) or process context * - * Notes: This function should be relatively fast. Normally it will - * not wait for IO to complete. Hence the 'done' callback is invoked - * (often directly from an interrupt service routine) some time after - * this function has returned. In some cases (e.g. pseudo adapter - * drivers that manufacture the response to a SCSI INQUIRY) - * the 'done' callback may be invoked before this function returns. - * If the 'done' callback is not invoked within a certain period - * the SCSI mid level will commence error processing. - * If a status of CHECK CONDITION is placed in "result" when the - * 'done' callback is invoked, then the LLD driver should - * perform autosense and fill in the struct scsi_cmnd::sense_buffer + * Notes: This function should be relatively fast. Normally it + * will not wait for IO to complete. Hence the scp->scsi_done + * callback is invoked (often directly from an interrupt service + * routine) some time after this function has returned. In some + * cases (e.g. pseudo adapter drivers that manufacture the + * response to a SCSI INQUIRY) the scp->scsi_done callback may be + * invoked before this function returns. If the scp->scsi_done + * callback is not invoked within a certain period the SCSI mid + * level will commence error processing. If a status of CHECK + * CONDITION is placed in "result" when the scp->scsi_done + * callback is invoked, then the LLD driver should perform + * autosense and fill in the struct scsi_cmnd::sense_buffer * array. The scsi_cmnd::sense_buffer array is zeroed prior to * the mid level queuing a command to an LLD. * * Defined in: LLD **/ - int queuecommand(struct scsi_cmnd * scp, - void (*done)(struct scsi_cmnd *)) + int queuecommand(struct Scsi_Host *shost, struct scsi_cmnd * scp) /** @@ -1259,6 +1260,8 @@ of interest: address space use_clustering - 1=>SCSI commands in mid level's queue can be merged, 0=>disallow SCSI command merging + no_async_abort - 1=>Asynchronous aborts are not supported + 0=>Timed-out commands will be aborted asynchronously hostt - pointer to driver's struct scsi_host_template from which this struct Scsi_Host instance was spawned hostt->proc_name - name of LLD. This is the driver name that sysfs uses @@ -1340,7 +1343,7 @@ Members of interest: underruns (overruns should be rare). If possible an LLD should set 'resid' prior to invoking 'done'. The most interesting case is data transfers from a SCSI target - device device (i.e. READs) that underrun. + device (e.g. READs) that underrun. underflow - LLD should place (DID_ERROR << 16) in 'result' if actual number of bytes transferred is less than this figure. Not many LLDs implement this check and some that @@ -1348,6 +1351,18 @@ Members of interest: report a DID_ERROR. Better for an LLD to implement 'resid'. +It is recommended that a LLD set 'resid' on data transfers from a SCSI +target device (e.g. READs). It is especially important that 'resid' is set +when such data transfers have sense keys of MEDIUM ERROR and HARDWARE ERROR +(and possibly RECOVERED ERROR). In these cases if a LLD is in doubt how much +data has been received then the safest approach is to indicate no bytes have +been received. For example: to indicate that no valid data has been received +a LLD might use these helpers: + scsi_set_resid(SCpnt, scsi_bufflen(SCpnt)); +where 'SCpnt' is a pointer to a scsi_cmnd object. To indicate only three 512 +bytes blocks has been received 'resid' could be set like this: + scsi_set_resid(SCpnt, scsi_bufflen(SCpnt) - (3 * 512)); + The scsi_cmnd structure is defined in include/scsi/scsi_cmnd.h diff --git a/Documentation/scsi/scsi_transport_srp/Makefile b/Documentation/scsi/scsi_transport_srp/Makefile new file mode 100644 index 00000000000..5f6b567e955 --- /dev/null +++ b/Documentation/scsi/scsi_transport_srp/Makefile @@ -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 $@ $< diff --git a/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot b/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot new file mode 100644 index 00000000000..75d610d6411 --- /dev/null +++ b/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot @@ -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()" ]; +} diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index 691ca292c24..f346abbdd6f 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -112,10 +112,8 @@ attempted). MINOR NUMBERS -The tape driver currently supports 128 drives by default. This number -can be increased by editing st.h and recompiling the driver if -necessary. The upper limit is 2^17 drives if 4 modes for each drive -are used. +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: @@ -390,6 +388,10 @@ MTSETDRVBUFFER 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 diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index 6f63b798967..6af8f7a7770 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -285,7 +285,7 @@ from the driver. 7. Profiling information -This driver does not provide profiling informations as did its predecessors. +This driver does not provide profiling information as did its predecessors. This feature was not this useful and added complexity to the code. As the driver code got more complex, I have decided to remove everything that didn't seem actually useful. diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt index 61c0531e044..3303d218b32 100644 --- a/Documentation/scsi/tmscsim.txt +++ b/Documentation/scsi/tmscsim.txt @@ -102,7 +102,7 @@ So take at least the following measures: 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 Millenium. But the Am53C974 +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. diff --git a/Documentation/scsi/ufs.txt b/Documentation/scsi/ufs.txt new file mode 100644 index 00000000000..41a6164592a --- /dev/null +++ b/Documentation/scsi/ufs.txt @@ -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 |