diff options
Diffstat (limited to 'Documentation/scsi')
40 files changed, 1770 insertions, 2147 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 98023baa0f0..48e982cd6fe 100644 --- a/Documentation/scsi/BusLogic.txt +++ b/Documentation/scsi/BusLogic.txt @@ -47,7 +47,7 @@ tune driver performance and error recovery to their particular needs. The latest information on Linux support for BusLogic SCSI Host Adapters, as well as the most recent release of this driver and the latest firmware for the BT-948/958/958D, will always be available from my Linux Home Page at URL -"http://www.dandelion.com/Linux/". +"http://sourceforge.net/projects/dandelion/". Bug reports should be sent via electronic mail to "lnz@dandelion.com". Please include with the bug report the complete configuration messages reported by the @@ -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 ff19a52fe00..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. @@ -707,7 +707,7 @@ Changes from 20040920 to 20041018 * Integrate patches from Christoph Hellwig: two new helpers common to lpfc_sli_resume_iocb and lpfc_sli_issue_iocb - singificant cleanup of those two functions - the unused SLI_IOCB_USE_TXQ is - gone - lpfc_sli_issue_iocb_wait loses it's flags argument + gone - lpfc_sli_issue_iocb_wait loses its flags argument totally. * Fix in lpfc_sli.c: we can not store a 5 bit value in a 4-bit field. @@ -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 @@ -807,13 +807,13 @@ Changes from 20040908 to 20040920 lpfc_disc_done/lpfc_do_dpc cleanup - lpfc_disc_done can return void - move lpfc_do_dpc and lpfc_disc_done to lpfc_hbadisc.c - remove checking of list emptiness before calling lpfc_disc_done, - it handles the emtpy list case just fine and the additional + it handles the empty list case just fine and the additional instructions cost less then the bustlocked spinlock operations. * Integrated patch from Christoph Hellwig: This adds a new 64bit 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 @@ -989,8 +989,8 @@ Changes from 20040709 to 20040716 * Remove redundant port_cmp != 2 check in if (!port_cmp) { .... if (port_cmp != 2).... } * Clock changes: removed struct clk_data and timerList. - * Clock changes: seperate nodev_tmo and els_retry_delay into 2 - seperate timers and convert to 1 argument changed + * Clock changes: separate nodev_tmo and els_retry_delay into 2 + separate timers and convert to 1 argument changed LPFC_NODE_FARP_PEND_t to struct lpfc_node_farp_pend convert ipfarp_tmo to 1 argument convert target struct tmofunc and rtplunfunc to 1 argument * cr_count, cr_delay and @@ -1028,7 +1028,7 @@ Changes from 20040614 to 20040709 * Remove the need for buf_tmo. * Changed ULP_BDE64 to struct ulp_bde64. * Changed ULP_BDE to struct ulp_bde. - * Cleanup lpfc_os_return_scsi_cmd() and it's call path. + * Cleanup lpfc_os_return_scsi_cmd() and its call path. * Removed lpfc_no_device_delay. * Consolidating lpfc_hba_put_event() into lpfc_put_event(). * Removed following attributes and their functionality: @@ -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 @@ -1514,7 +1514,7 @@ Changes from 20040402 to 20040409 * Remove unused elxclock declaration in elx_sli.h. * Since everywhere IOCB_ENTRY is used, the return value is cast, move the cast into the macro. - * Split ioctls out into seperate files + * Split ioctls out into separate files Changes from 20040326 to 20040402 @@ -1534,7 +1534,7 @@ Changes from 20040326 to 20040402 * Unused variable cleanup * Use Linux list macros for DMABUF_t * Break up ioctls into 3 sections, dfc, util, hbaapi - rearranged code so this could be easily seperated into a + rearranged code so this could be easily separated into a differnet module later All 3 are currently turned on by defines in lpfc_ioctl.c LPFC_DFC_IOCTL, LPFC_UTIL_IOCTL, LPFC_HBAAPI_IOCTL @@ -1551,7 +1551,7 @@ Changes from 20040326 to 20040402 started by lpfc_online(). lpfc_offline() only stopped els_timeout routine. It now stops all timeout routines associated with that hba. - * Replace seperate next and prev pointers in struct + * Replace separate next and prev pointers in struct lpfc_bindlist with list_head type. In elxHBA_t, replace fc_nlpbind_start and _end with fc_nlpbind_list and use list_head macros to access it. @@ -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 eaa4801f2ce..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, @@ -215,7 +215,7 @@ Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) 3. Convert pci_module_init to pci_register_driver Convert from pci_module_init to pci_register_driver - (from:http://kerneljanitors.org/TODO) + (from:http://kernelnewbies.org/KernelJanitors/TODO) - Signed-off-by: Domen Puncer <domen@coderock.org> 4. Use the pre defined DMA mask constants from dma-mapping.h @@ -514,7 +514,7 @@ iv. Remove yield() while mailbox handshake in synchronous commands v. Remove redundant __megaraid_busywait_mbox routine -vi. Fix bug in the managment module, which causes a system lockup when the +vi. Fix bug in the management module, which causes a system lockup when the IO module is loaded and then unloaded, followed by executing any management utility. The current version of management module does not handle the adapter unregister properly. diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index c851ef49779..91ba58ef02d 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,305 @@ +Release Date : Mon. Mar 10, 2014 17:00:00 PST 2014 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena +Current Version : 06.803.01.00-rc1 +Old Version : 06.700.06.00-rc1 + 1. Load correct raid context timeout value for multipathing & clustering. + 2. Fix megasas_ioc_init_fusion to use local stack variable. + 3. Return leaked MPT frames to MPT command pool. + 4. Add Dell PowerEdge VRTX SR-IOV VF device support. + 5. Version and Changelog update. +------------------------------------------------------------------------------- +Release Date : Sat. Aug 31, 2013 17:00:00 PST 2013 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena +Current Version : 06.700.06.00-rc1 +Old Version : 06.600.18.00-rc1 + 1. Add High Availability clustering support using shared Logical Disks. + 2. Version and Changelog update. +------------------------------------------------------------------------------- +Release Date : Wed. May 15, 2013 17:00:00 PST 2013 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena +Current Version : 06.600.18.00-rc1 +Old Version : 06.506.00.00-rc1 + 1. Return DID_ERROR for scsi io, when controller is in critical h/w error. + 2. Fix the interrupt mask for Gen2 controller. + 3. Update balance count in driver to be in sync of firmware. + 4. Free event detail memory without device ID check. + 5. Set IO request timeout value provided by OS timeout for Tape devices. + 6. Add support for MegaRAID Fury (device ID-0x005f) 12Gb/s controllers. + 7. Add support to display Customer branding details in syslog. + 8. Set IoFlags to enable Fast Path for JBODs for Invader/Fury(12 Gb/s) + controllers. + 9. Add support for Extended MSI-x vectors for Invader and Fury(12Gb/s + HBA). + 10.Add support for Uneven Span PRL11. + 11.Add support to differentiate between iMR and MR Firmware. + 12.Version and Changelog update. +------------------------------------------------------------------------------- +Release Date : Sat. Feb 9, 2013 17:00:00 PST 2013 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 06.506.00.00-rc1 +Old Version : 06.504.01.00-rc1 + 1. Add 4k FastPath DIF support. + 2. Dont load DevHandle unless FastPath enabled. + 3. Version and Changelog update. +------------------------------------------------------------------------------- +Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 06.504.01.00-rc1 +Old Version : 00.00.06.18-rc1 + 1. Removed un-needed completion_lock spinlock calls. + 2. Add module param for configurable MSI-X vector count. + 3. Load io_request DataLength in bytes. + 4. Add array boundary check for SystemPD. + 5. Add SystemPD FastPath support. + 6. Remove duplicate code. + 7. Version, Changelog, Copyright update. +------------------------------------------------------------------------------- +Release Date : Tue. Jun 17, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford/Kashyap Desai +Current Version : 00.00.06.18-rc1 +Old Version : 00.00.06.15-rc1 + 1. Fix Copyright dates. + 2. Add throttlequeuedepth module parameter. + 3. Add resetwaittime module parameter. + 4. Move poll_aen_lock initializer. +------------------------------------------------------------------------------- +Release Date : Mon. Mar 19, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.06.15-rc1 +Old Version : 00.00.06.14-rc1 + 1. Optimize HostMSIxVectors setting. + 2. Add fpRead/WriteCapable, fpRead/WriteAcrossStripe checks. +------------------------------------------------------------------------------- +Release Date : Fri. Jan 6, 2012 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.06.14-rc1 +Old Version : 00.00.06.12-rc1 + 1. Fix reglockFlags for degraded raid5/6 for MR 9360/9380. + 2. Mask off flags in ioctl path to prevent memory scribble with older + MegaCLI versions. + 3. Remove poll_mode_io module paramater, sysfs node, and associated code. +------------------------------------------------------------------------------- +Release Date : Wed. Oct 5, 2011 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.06.12-rc1 +Old Version : 00.00.05.40-rc1 + 1. Continue booting immediately if FW in FAULT at driver load time. + 2. Increase default cmds per lun to 256. + 3. Fix mismatch in megasas_reset_fusion() mutex lock-unlock. + 4. Remove some un-necessary code. + 5. Clear state change interrupts for Fusion/Invader. + 6. Clear FUSION_IN_RESET before enabling interrupts. + 7. Add support for MegaRAID 9360/9380 12GB/s controllers. + 8. Add multiple MSI-X vector/multiple reply queue support. + 9. Add driver workaround for PERC5/1068 kdump kernel panic. +------------------------------------------------------------------------------- +Release Date : Tue. Jul 26, 2011 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.05.40-rc1 +Old Version : 00.00.05.38-rc1 + 1. Fix FastPath I/O to work with degraded RAID 1. + 2. Add .change_queue_depth support. +------------------------------------------------------------------------------- +Release Date : Wed. May 11, 2011 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.05.38-rc1 +Old Version : 00.00.05.34-rc1 + 1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable. + 2. Remove un-used function megasas_return_cmd_for_smid(). + 3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion(). + 4. Disable interrupts/free_irq() in megasas_shutdown(). + 5. Fix bug where AENs could be lost in probe() and resume(). + 6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath + IO. + 7. Add 1078 OCR support. +------------------------------------------------------------------------------- +Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.05.34-rc1 +Old Version : 00.00.05.29-rc1 + 1. Fix some failure gotos from megasas_probe_one(), etc. + 2. Add missing check_and_restore_queue_depth() call in + complete_cmd_fusion(). + 3. Enable MSI-X before calling megasas_init_fw(). + 4. Call tasklet_schedule() even if outbound_intr_status == 0 for MFI based + boards in MSI-X mode. + 5. Fix megasas_probe_one() to clear PCI_MSIX_FLAGS_ENABLE in msi control + register in kdump kernel. + 6. Fix megasas_get_cmd() to only print "Command pool empty" if + megasas_dbg_lvl is set. + 7. Fix megasas_build_dcdb_fusion() to not filter by TYPE_DISK. + 8. Fix megasas_build_dcdb_fusion() to use io_request->LUN[1] field. + 9. Add MR_EVT_CFG_CLEARED to megasas_aen_polling(). + 10. Fix tasklet_init() in megasas_init_fw() to use instancet->tasklet. + 11. Fix fault state handling in megasas_transition_to_ready(). + 12. Fix max_sectors setting for IEEE SGL's. + 13. Fix iMR OCR support to work correctly. +------------------------------------------------------------------------------- +Release Date : Tues. Dec 14, 2010 17:00:00 PST 2010 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.05.29-rc1 +Old Version : 00.00.04.31-rc1 + 1. Rename megaraid_sas.c to megaraid_sas_base.c. + 2. Update GPL headers. + 3. Add MSI-X support and 'msix_disable' module parameter. + 4. Use lowest memory bar (for SR-IOV VF support). + 5. Add struct megasas_instance_temlate changes, and change all code to use + new instance entries: + + irqreturn_t (*service_isr )(int irq, void *devp); + void (*tasklet)(unsigned long); + u32 (*init_adapter)(struct megasas_instance *); + u32 (*build_and_issue_cmd) (struct megasas_instance *, + struct scsi_cmnd *); + void (*issue_dcmd) (struct megasas_instance *instance, + struct megasas_cmd *cmd); + + 6. Add code to support MegaRAID 9265/9285 controllers device id (0x5b). +------------------------------------------------------------------------------- +1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.31-rc1 +3 Older Version : 00.00.04.17.1-rc1 + +1. Add the Online Controller Reset (OCR) to the Driver. + OCR is the new feature for megaraid_sas driver which + will allow the fw to do the chip reset which will not + affact the OS behavious. + + To add the OCR support, driver need to do: + a). reset the controller chips -- Xscale and Gen2 which + will change the function calls and add the reset function + related to this two chips. + + b). during the reset, driver will store the pending cmds + which not returned by FW to driver's pending queue. Driver + will re-issue those pending cmds again to FW after the OCR + finished. + + c). In driver's timeout routine, driver will report to + OS as reset. Also driver's queue routine will block the + cmds until the OCR finished. + + d). in Driver's ISR routine, if driver get the FW state as + state change, FW in Failure status and FW support online controller + reset (OCR), driver will start to do the controller reset. + + e). In driver's IOCTL routine, the application cmds will wait for the + OCR to finish, then issue the cmds to FW. + + f). Before driver kill adapter, driver will do last chance of + OCR to see if driver can bring back the FW. + +2. Add the support update flag to the driver to tell LSI megaraid_sas + application which driver will support the device update. So application + will not need to do the device update after application add/del the device + from the system. +3. In driver's timeout routine, driver will do three time reset if fw is in + failed state. Driver will kill adapter if can't bring back FW after the + this three times reset. +4. Add the input parameter max_sectors to 1MB support to our GEN2 controller. + customer can use the input paramenter max_sectors to add 1MB support to GEN2 + controller. + +1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.17.1-rc1 +3 Older Version : 00.00.04.12 + +1. Add the pad_0 in mfi frame structure to 0 to fix the + context value larger than 32bit value issue. + +2. Add the logic drive list to the driver. Driver will + keep the logic drive list internal after driver load. + +3. driver fixed the device update issue after get the AEN + PD delete/ADD, LD add/delete from FW. + +1 Release Date : Tues. July 28, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.12 +3 Older Version : 00.00.04.10 + +1. Change the AEN sys PD update from scsi_scan to + scsi_add_device and scsi_remove_device. +2. Takeoff the debug print-out in aen_polling routine. + +1 Release Date : Thur. July 02, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.10 +3 Older Version : 00.00.04.08 + +1. Add the 3 mins timeout during the controller initialize. +2. Add the fix for 64bit sense date errors. + +1 Release Date : Tues. May 05, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.08 +3 Older Version : 00.00.04.06 + +1. Add the fix of pending in FW after deleted the logic drives. +2. Add the fix of deallocating memory after get pdlist. + +1 Release Date : Tues. March 26, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.06 +3 Older Version : 00.00.04.04 + +1. Add the fix of the driver cmd empty fix of the driver cmd empty. +2. Add the fix of the driver MSM AEN CMD cause the system slow. + +1 Release Date : Tues. March 03, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.04 +3 Older Version : 00.00.04.01 + +1. Add the Tape drive fix to the driver: If the command is for + the tape device, set the pthru timeout to the os layer timeout value. + +2. Add Poll_wait mechanism to Gen-2 Linux driv. + In the aen handler, driver needs to wakeup poll handler similar to + the way it raises SIGIO. + +3. Add new controller new SAS2 support to the driver. + +4. Report the unconfigured PD (system PD) to OS. + +5. Add the IEEE SGL support to the driver + +6. Reasign the Application cmds to SAS2 controller 1 Release Date : Thur.July. 24 11:41:51 PST 2008 - (emaild-id:megaraidlinux@lsi.com) @@ -185,7 +487,7 @@ ii. FW enables WCE bit in Mode Sense cmd for drives that are configured Disks are exposed with WCE=1. User is advised to enable Write Back mode only when the controller has battery backup. At this time Synhronize cache is not supported by the FW. Driver will short-cycle - the cmd and return sucess without sending down to FW. + the cmd and return success without sending down to FW. 1 Release Date : Sun Jan. 14 11:21:32 PDT 2007 - Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang @@ -293,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/FlashPoint.txt b/Documentation/scsi/FlashPoint.txt index d5acaa300a4..5b5f29cb9f8 100644 --- a/Documentation/scsi/FlashPoint.txt +++ b/Documentation/scsi/FlashPoint.txt @@ -13,7 +13,7 @@ operating system support to its BusLogic brand of FlashPoint Ultra SCSI host adapters. All of BusLogic's other SCSI host adapters, including the MultiMaster line, currently support the Linux operating system. Linux drivers and information will be available on October 15th at -http://www.dandelion.com/Linux/. +http://sourceforge.net/projects/dandelion/. "Mylex is committed to supporting the Linux community," says Peter Shambora, vice president of marketing for Mylex. "We have supported Linux driver @@ -27,7 +27,7 @@ Linux is a freely-distributed implementation of UNIX for Intel x86, Sun SPARC, SGI MIPS, Motorola 68k, Digital Alpha AXP and Motorola PowerPC machines. It supports a wide range of software, including the X Window System, Emacs, and TCP/IP networking. Further information is available at -http://www.linux.org and http://www.ssc.com/linux. +http://www.linux.org and http://www.ssc.com/. FlashPoint Host Adapters @@ -71,7 +71,7 @@ peters@mylex.com Ever since its introduction last October, the BusLogic FlashPoint LT has been problematic for members of the Linux community, in that no Linux -drivers have been available for this new Ultra SCSI product. Despite it's +drivers have been available for this new Ultra SCSI product. Despite its officially being positioned as a desktop workstation product, and not being particularly well suited for a high performance multitasking operating system like Linux, the FlashPoint LT has been touted by computer system 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/Mylex.txt b/Documentation/scsi/Mylex.txt index cdf69293f7d..3797f3e6c2b 100644 --- a/Documentation/scsi/Mylex.txt +++ b/Documentation/scsi/Mylex.txt @@ -2,4 +2,4 @@ Please see the file README.BusLogic for information about Linux support for Mylex (formerly BusLogic) MultiMaster and FlashPoint SCSI Host Adapters. The Mylex DAC960 PCI RAID Controllers are now supported. Please consult -http://www.dandelion.com/Linux/ for further information on the DAC960 driver. +http://sourceforge.net/projects/dandelion for further information on the DAC960 driver. diff --git a/Documentation/scsi/NinjaSCSI.txt b/Documentation/scsi/NinjaSCSI.txt index 3229b64cf24..ac8db8ceec7 100644 --- a/Documentation/scsi/NinjaSCSI.txt +++ b/Documentation/scsi/NinjaSCSI.txt @@ -3,8 +3,6 @@ 1. Comment This is Workbit corp.'s(http://www.workbit.co.jp/) NinjaSCSI-3 -(http://www.workbit.co.jp/ts/z_nj3r.html) and NinjaSCSI-32Bi -(http://www.workbit.co.jp/ts/z_njsc32bi.html) PCMCIA card driver module for Linux. 2. My Linux environment 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 683ccae00ad..e2d3273000d 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt @@ -194,7 +194,7 @@ The following information is available in this file: - Packetized SCSI Protocol at 160MB/s and 320MB/s - Quick Arbitration Selection (QAS) - Retained Training Information (Rev B. ASIC only) - - Interrupt Coalessing + - Interrupt Coalescing - Initiator Mode (target mode not currently supported) - Support for the PCI-X standard up to 133MHz @@ -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. @@ -447,7 +447,7 @@ The following information is available in this file: http://www.adaptec.com/buy-cables/. Europe - - Visit our Web site at http://www.adaptec-europe.com/. + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - To speak with a Technical Support Specialist, call, or email, * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, http://ask-de.adaptec.com/. diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt index b7e238cbb5a..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: ----------------------------------------------------------------- @@ -344,7 +344,7 @@ The following information is available in this file: http://www.adaptec.com/buy-cables/. Europe - - Visit our Web site at http://www.adaptec-europe.com/. + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - To speak with a Technical Support Specialist, call, or email, * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, http://ask-de.adaptec.com/. 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/dtc3x80.txt b/Documentation/scsi/dtc3x80.txt index e8ae6230ab3..1d7af9f9a8e 100644 --- a/Documentation/scsi/dtc3x80.txt +++ b/Documentation/scsi/dtc3x80.txt @@ -12,7 +12,7 @@ The 3180 does not. Otherwise, they are identical. The DTC3x80 does not support DMA but it does have Pseudo-DMA which is supported by the driver. -It's DTC406 scsi chip is supposedly compatible with the NCR 53C400. +Its DTC406 scsi chip is supposedly compatible with the NCR 53C400. It is memory mapped, uses an IRQ, but no dma or io-port. There is internal DMA, between SCSI bus and an on-chip 128-byte buffer. Double buffering is done automagically by the chip. Data is transferred diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt new file mode 100644 index 00000000000..891435a72fc --- /dev/null +++ b/Documentation/scsi/hpsa.txt @@ -0,0 +1,130 @@ + +HPSA - Hewlett Packard Smart Array driver +----------------------------------------- + +This file describes the hpsa SCSI driver for HP Smart Array controllers. +The hpsa driver is intended to supplant the cciss driver for newer +Smart Array controllers. The hpsa driver is a SCSI driver, while the +cciss driver is a "block" driver. Actually cciss is both a block +driver (for logical drives) AND a SCSI driver (for tape drives). This +"split-brained" design of the cciss driver is a source of excess +complexity and eliminating that complexity is one of the reasons +for hpsa to exist. + +Supported devices: +------------------ + +Smart Array P212 +Smart Array P410 +Smart Array P410i +Smart Array P411 +Smart Array P812 +Smart Array P712m +Smart Array P711m +StorageWorks P1210m + +Additionally, older Smart Arrays may work with the hpsa driver if the kernel +boot parameter "hpsa_allow_any=1" is specified, however these are not tested +nor supported by HP with this driver. For older Smart Arrays, the cciss +driver should still be used. + +The "hpsa_simple_mode=1" boot parameter may be used to prevent the driver from +putting the controller into "performant" mode. The difference is that with simple +mode, each command completion requires an interrupt, while with "performant mode" +(the default, and ordinarily better performing) it is possible to have multiple +command completions indicated by a single interrupt. + +HPSA specific entries in /sys +----------------------------- + + In addition to the generic SCSI attributes available in /sys, hpsa supports + the following attributes: + + HPSA specific host attributes: + ------------------------------ + + /sys/class/scsi_host/host*/rescan + /sys/class/scsi_host/host*/firmware_revision + /sys/class/scsi_host/host*/resettable + /sys/class/scsi_host/host*/transport_mode + + the host "rescan" attribute is a write only attribute. Writing to this + attribute will cause the driver to scan for new, changed, or removed devices + (e.g. hot-plugged tape drives, or newly configured or deleted logical drives, + etc.) and notify the SCSI midlayer of any changes detected. Normally this is + triggered automatically by HP's Array Configuration Utility (either the GUI or + command line variety) so for logical drive changes, the user should not + normally have to use this. It may be useful when hot plugging devices like + tape drives, or entire storage boxes containing pre-configured logical drives. + + The "firmware_revision" attribute contains the firmware version of the Smart Array. + For example: + + root@host:/sys/class/scsi_host/host4# cat firmware_revision + 7.14 + + The transport_mode indicates whether the controller is in "performant" + or "simple" mode. This is controlled by the "hpsa_simple_mode" module + parameter. + + The "resettable" read-only attribute indicates whether a particular + controller is able to honor the "reset_devices" kernel parameter. If the + device is resettable, this file will contain a "1", otherwise, a "0". This + parameter is used by kdump, for example, to reset the controller at driver + load time to eliminate any outstanding commands on the controller and get the + controller into a known state so that the kdump initiated i/o will work right + and not be disrupted in any way by stale commands or other stale state + remaining on the controller from the previous kernel. This attribute enables + kexec tools to warn the user if they attempt to designate a device which is + unable to honor the reset_devices kernel parameter as a dump device. + + HPSA specific disk attributes: + ------------------------------ + + /sys/class/scsi_disk/c:b:t:l/device/unique_id + /sys/class/scsi_disk/c:b:t:l/device/raid_level + /sys/class/scsi_disk/c:b:t:l/device/lunid + + (where c:b:t:l are the controller, bus, target and lun of the device) + + For example: + + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat unique_id + 600508B1001044395355323037570F77 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat lunid + 0x0000004000000000 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat raid_level + RAID 0 + +HPSA specific ioctls: +--------------------- + + For compatibility with applications written for the cciss driver, many, but + not all of the ioctls supported by the cciss driver are also supported by the + hpsa driver. The data structures used by these are described in + include/linux/cciss_ioctl.h + + CCISS_DEREGDISK + CCISS_REGNEWDISK + CCISS_REGNEWD + + The above three ioctls all do exactly the same thing, which is to cause the driver + to rescan for new devices. This does exactly the same thing as writing to the + hpsa specific host "rescan" attribute. + + CCISS_GETPCIINFO + + Returns PCI domain, bus, device and function and "board ID" (PCI subsystem ID). + + CCISS_GETDRIVVER + + Returns driver version in three bytes encoded as: + (major_version << 16) | (minor_version << 8) | (subminor_version) + + CCISS_PASSTHRU + CCISS_BIG_PASSTHRU + + Allows "BMIC" and "CISS" commands to be passed through to the Smart Array. + These are used extensively by the HP Array Configuration Utility, SNMP storage + agents, etc. See cciss_vol_status at http://cciss.sf.net for some examples. + diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt index a6eb4add1be..12ecfd308e5 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt @@ -3,6 +3,25 @@ HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop) Controller Register Map ------------------------- +For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2: + + BAR0 offset Register + 0x11C5C Link Interface IRQ Set + 0x11C60 Link Interface IRQ Clear + + BAR2 offset Register + 0x10 Inbound Message Register 0 + 0x14 Inbound Message Register 1 + 0x18 Outbound Message Register 0 + 0x1C Outbound Message Register 1 + 0x20 Inbound Doorbell Register + 0x24 Inbound Interrupt Status Register + 0x28 Inbound Interrupt Mask Register + 0x30 Outbound Interrupt Status Register + 0x34 Outbound Interrupt Mask Register + 0x40 Inbound Queue Port + 0x44 Outbound Queue Port + For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: BAR0 offset Register @@ -18,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 @@ -36,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: + + BAR0 offset Register + 0x0 IOP configuration information. -I/O Request Workflow ----------------------- + 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. @@ -82,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 --------------------- @@ -93,7 +173,7 @@ The driver exposes following sysfs attributes: ----------------------------------------------------------------------------- -Copyright (C) 2006-2007 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 3920f28710c..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.uni-mainz.de/~langm000/linux.html - Q: My SCSI-adapter is not recognized by the driver, what can I do? - A: Just force it to be recognized by kernel parameters. See section 5.1. - If this really happens, do also send e-mail to the maintainer, as - forced detection should be never necessary. Forced detection is in - principal some flaw of the driver adapter detection and goes into - 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/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 230e30846ef..cda5f8fa2c6 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -206,7 +206,7 @@ of MOVE MEMORY instructions. The 896 and the 895A allows handling of the phase mismatch context from SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor until the C code has saved the context of the transfer). -Implementing this without using LOAD/STORE instructions would be painfull +Implementing this without using LOAD/STORE instructions would be painful and I didn't even want to try it. The 896 chip supports 64 bit PCI transactions and addressing, while the @@ -240,7 +240,7 @@ characteristics. This feature may also reduce average command latency. In order to really gain advantage of this feature, devices must have a reasonable cache size (No miracle is to be expected for a low-end hard disk with 128 KB or less). -Some kown SCSI devices do not properly support tagged command queuing. +Some known SCSI devices do not properly support tagged command queuing. Generally, firmware revisions that fix this kind of problems are available at respective vendor web/ftp sites. All I can say is that the hard disks I use on my machines behave well with @@ -1479,7 +1479,7 @@ Wide16 SCSI. Enabling serial NVRAM support enables detection of the serial NVRAM included on Symbios and some Symbios compatible host adaptors, and Tekram boards. The serial NVRAM is used by Symbios and Tekram to hold set up parameters for the -host adaptor and it's attached drives. +host adaptor and its attached drives. The Symbios NVRAM also holds data on the boot order of host adaptors in a system with more than one host adaptor. This enables the order of scanning diff --git a/Documentation/scsi/osst.txt b/Documentation/scsi/osst.txt index f536907e241..00c8ebb2fd1 100644 --- a/Documentation/scsi/osst.txt +++ b/Documentation/scsi/osst.txt @@ -40,7 +40,7 @@ behavior looks very much the same as st to the userspace applications. History ------- -In the first place, osst shared it's identity very much with st. That meant +In the first place, osst shared its identity very much with st. That meant that it used the same kernel structures and the same device node as st. So you could only have either of them being present in the kernel. This has been fixed by registering an own device, now. @@ -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 @@ -135,7 +135,7 @@ The driver development is coordinated through a mailing list a CVS repository and some web pages. The tester's pages which contain recent news and updated drivers to download can be found on -http://linux1.onstream.nl/test/ +http://sourceforge.net/projects/osst/ If you find any problems, please have a look at the tester's page in order to see whether the problem is already known and solved. Otherwise, please diff --git a/Documentation/scsi/ppa.txt b/Documentation/scsi/ppa.txt index 067ac394e0b..05ff47dbe8d 100644 --- a/Documentation/scsi/ppa.txt +++ b/Documentation/scsi/ppa.txt @@ -1,13 +1,13 @@ -------- Terse where to get ZIP Drive help info -------- General Iomega ZIP drive page for Linux: -http://www.torque.net/~campbell/ +http://web.archive.org/web/*/http://www.torque.net/~campbell/ Driver archive for old drivers: -http://www.torque.net/~campbell/ppa/ +http://web.archive.org/web/*/http://www.torque.net/~campbell/ppa Linux Parport page (parallel port) -http://www.torque.net/parport/ +http://web.archive.org/web/*/http://www.torque.net/parport/ Email list for Linux Parport linux-parport@torque.net 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 c38e2b3648e..51be20a6a14 100644 --- a/Documentation/scsi/scsi-generic.txt +++ b/Documentation/scsi/scsi-generic.txt @@ -34,11 +34,11 @@ http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO This describes the sg version 3 driver found in the lk 2.4 series. The LDP renders documents in single and multiple page HTML, postscript and pdf. This document can also be found at: -http://www.torque.net/sg/p/sg_v3_ho.html +http://sg.danny.cz/sg/p/sg_v3_ho.html Documentation for the version 2 sg driver found in the lk 2.2 series can -be found at http://www.torque.net/sg/p/scsi-generic.txt . A larger version -is at: http://www.torque.net/sg/p/scsi-generic_long.txt . +be found at http://sg.danny.cz/sg/. A larger version +is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt. The original documentation for the sg driver (prior to lk 2.2.6) can be found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt @@ -61,8 +61,8 @@ There are two packages of sg utilities: - sg_utils for the sg version 2 (and original) driver found in lk 2.2 and earlier Both packages will work in the lk 2.4 series however sg3_utils offers more -capabilities. They can be found at: http://www.torque.net/sg and -freshmeat.net +capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and +freecode.com Another approach is to look at the applications that use the sg driver. These include cdrecord, cdparanoia, SANE and cdrdao. diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt new file mode 100644 index 00000000000..2bfd6f6d2d3 --- /dev/null +++ b/Documentation/scsi/scsi-parameters.txt @@ -0,0 +1,133 @@ + SCSI Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + advansys= [HW,SCSI] + See header of drivers/scsi/advansys.c. + + aha152x= [HW,SCSI] + See Documentation/scsi/aha152x.txt. + + aha1542= [HW,SCSI] + Format: <portbase>[,<buson>,<busoff>[,<dmaspeed>]] + + aic7xxx= [HW,SCSI] + See Documentation/scsi/aic7xxx.txt. + + aic79xx= [HW,SCSI] + See Documentation/scsi/aic79xx.txt. + + atascsi= [HW,SCSI] Atari SCSI + + BusLogic= [HW,SCSI] + See drivers/scsi/BusLogic.c, comment before function + BusLogic_ParseDriverOptions(). + + dtc3181e= [HW,SCSI] + + eata= [HW,SCSI] + + fdomain= [HW,SCSI] + See header of drivers/scsi/fdomain.c. + + gdth= [HW,SCSI] + See header of drivers/scsi/gdth.c. + + gvp11= [HW,SCSI] + + in2000= [HW,SCSI] + See header of drivers/scsi/in2000.c. + + ips= [HW,SCSI] Adaptec / IBM ServeRAID controller + See header of drivers/scsi/ips.c. + + mac5380= [HW,SCSI] Format: + <can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags> + + max_luns= [SCSI] Maximum number of LUNs to probe. + Should be between 1 and 2^32-1. + + max_report_luns= + [SCSI] Maximum number of LUNs received. + Should be between 1 and 16384. + + NCR_D700= [HW,SCSI] + See header of drivers/scsi/NCR_D700.c. + + ncr5380= [HW,SCSI] + + ncr53c400= [HW,SCSI] + + ncr53c400a= [HW,SCSI] + + ncr53c406a= [HW,SCSI] + + ncr53c8xx= [HW,SCSI] + + nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. + + osst= [HW,SCSI] SCSI Tape Driver + Format: <buffer_size>,<write_threshold> + See also Documentation/scsi/st.txt. + + pas16= [HW,SCSI] + See header of drivers/scsi/pas16.c. + + scsi_debug_*= [SCSI] + See drivers/scsi/scsi_debug.c. + + scsi_default_dev_flags= + [SCSI] SCSI default device flags + Format: <integer> + + scsi_dev_flags= [SCSI] Black/white list entry for vendor and model + Format: <vendor>:<model>:<flags> + (flags are integer value) + + scsi_logging_level= [SCSI] a bit mask of logging levels + See drivers/scsi/scsi_logging.h for bits. Also + settable via sysctl at dev.scsi.logging_level + (/proc/sys/dev/scsi/logging_level). + There is also a nice 'scsi_logging_level' script in the + S390-tools package, available for download at + http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html + + scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are + discovered. async scans them in kernel threads, + allowing boot to proceed. none ignores them, expecting + user space to do the scan. + + sim710= [SCSI,HW] + See header of drivers/scsi/sim710.c. + + st= [HW,SCSI] SCSI tape parameters (buffers, etc.) + See Documentation/scsi/st.txt. + + sym53c416= [HW,SCSI] + See header of drivers/scsi/sym53c416.c. + + t128= [HW,SCSI] + See header of drivers/scsi/t128.c. + + tmscsim= [HW,SCSI] + See comment before function dc390_setup() in + drivers/scsi/tmscsim.c. + + u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter + See header of drivers/scsi/u14-34f.c. + + wd33c93= [HW,SCSI] + See header of drivers/scsi/wd33c93.c. + + wd7000= [HW,SCSI] + See header of drivers/scsi/wd7000.c. diff --git a/Documentation/scsi/scsi.txt b/Documentation/scsi/scsi.txt index dd1bbf4e98e..3d99d38cb62 100644 --- a/Documentation/scsi/scsi.txt +++ b/Documentation/scsi/scsi.txt @@ -4,8 +4,8 @@ The Linux Documentation Project (LDP) maintains a document describing the SCSI subsystem in the Linux kernel (lk) 2.4 series. See: http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single and multiple page HTML renderings as well as postscript and pdf. -It can also be found at http://www.torque.net/scsi/SCSI-2.4-HOWTO . - +It can also be found at: +http://web.archive.org/web/*/http://www.torque.net/scsi/SCSI-2.4-HOWTO Notes on using modules in the SCSI subsystem ============================================ 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 e5b071d4661..f79282fc48d 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt @@ -1,10 +1,11 @@ SCSI FC Tansport ============================================= -Date: 4/12/2007 +Date: 11/18/2008 Kernel Revisions for features: rports : <<TBS>> - vports : 2.6.22 (? TBD) + vports : 2.6.22 + bsg support : 2.6.30 (?TBD?) Introduction @@ -15,6 +16,7 @@ The FC transport can be found at: drivers/scsi/scsi_transport_fc.c include/scsi/scsi_transport_fc.h include/scsi/scsi_netlink_fc.h + include/scsi/scsi_bsg_fc.h This file is found at Documentation/scsi/scsi_fc_transport.txt @@ -68,7 +70,7 @@ Overview: up to an administrative entity controlling the vport. For example, if vports are to be associated with virtual machines, a XEN mgmt utility would be responsible for creating wwpn/wwnn's for the vport, - using it's own naming authority and OUI. (Note: it already does this + using its own naming authority and OUI. (Note: it already does this for virtual MAC addresses). @@ -79,7 +81,7 @@ Device Trees and Vport Objects: with rports and scsi target objects underneath it. Currently the FC transport creates the vport object and places it under the scsi_host object corresponding to the physical adapter. The LLDD will allocate - a new scsi_host for the vport and link it's object under the vport. + a new scsi_host for the vport and link its object under the vport. The remainder of the tree under the vports scsi_host is the same as the non-NPIV case. The transport is written currently to easily allow the parent of the vport to be something other than the scsi_host. @@ -289,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 @@ -376,7 +378,7 @@ Vport Disable/Enable: int vport_disable(struct fc_vport *vport, bool disable) where: - vport: Is vport to to be enabled or disabled + vport: Is vport to be enabled or disabled disable: If "true", the vport is to be disabled. If "false", the vport is to be enabled. @@ -472,6 +474,14 @@ int fc_vport_terminate(struct fc_vport *vport) +FC BSG support (CT & ELS passthru, and more) +======================================================================== +<< To Be Supplied >> + + + + + Credits ======= The following people have contributed to this document: diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index a6d5354639b..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. @@ -43,7 +43,7 @@ There is a SCSI documentation directory within the kernel source tree, typically Documentation/scsi . Most documents are in plain (i.e. ASCII) text. This file is named scsi_mid_low_api.txt and can be found in that directory. A more recent copy of this document may be found -at http://www.torque.net/scsi/scsi_mid_low_api.txt.gz . +at http://web.archive.org/web/20070107183357rn_1/sg.torque.net/scsi/. Many LLDs are documented there (e.g. aic7xxx.txt). The SCSI mid-level is briefly described in scsi.txt which contains a url to a document describing the SCSI subsystem in the lk 2.4 series. Two upper level @@ -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 @@ -1271,6 +1274,11 @@ of interest: hostdata[0] - area reserved for LLD at end of struct Scsi_Host. Size is set by the second argument (named 'xtr_bytes') to scsi_host_alloc() or scsi_register(). + vendor_id - a unique value that identifies the vendor supplying + the LLD for the Scsi_Host. Used most often in validating + vendor-specific message requests. Value consists of an + identifier type and a vendor-specific value. + See scsi_netlink.h for a description of valid formats. The scsi_host structure is defined in include/scsi/scsi_host.h @@ -1335,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 @@ -1343,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 40752602c05..f346abbdd6f 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver. The driver is currently maintained by Kai Mäkisara (email Kai.Makisara@kolumbus.fi) -Last modified: Sun Feb 24 21:59:07 2008 by kai.makisara +Last modified: Sun Aug 29 18:25:47 2010 by kai.makisara BASICS @@ -85,6 +85,17 @@ writing and the last operation has been a write. Two filemarks can be optionally written. In both cases end of data is signified by returning zero bytes for two consecutive reads. +Writing filemarks without the immediate bit set in the SCSI command block acts +as a synchronization point, i.e., all remaining data form the drive buffers is +written to tape before the command returns. This makes sure that write errors +are caught at that point, but this takes time. In some applications, several +consecutive files must be written fast. The MTWEOFI operation can be used to +write the filemarks without flushing the drive buffer. Writing filemark at +close() is always flushing the drive buffers. However, if the previous +operation is MTWEOFI, close() does not write a filemark. This can be used if +the program wants to close/open the tape device between files and wants to +skip waiting. + If rewind, offline, bsf, or seek is done and previous tape operation was write, a filemark is written before moving tape. @@ -101,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: @@ -301,6 +310,8 @@ MTBSR Space backward over count records. MTFSS Space forward over count setmarks. MTBSS Space backward over count setmarks. MTWEOF Write count filemarks. +MTWEOFI Write count filemarks with immediate bit set (i.e., does not + wait until data is on tape) MTWSM Write count setmarks. MTREW Rewind tape. MTOFFL Set device off line (often rewind plus eject). @@ -377,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 49ea5c58c6b..6af8f7a7770 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -206,7 +206,7 @@ characteristics. This feature may also reduce average command latency. In order to really gain advantage of this feature, devices must have a reasonable cache size (No miracle is to be expected for a low-end hard disk with 128 KB or less). -Some kown old SCSI devices do not properly support tagged command queuing. +Some known old SCSI devices do not properly support tagged command queuing. Generally, firmware revisions that fix this kind of problems are available at respective vendor web/ftp sites. All I can say is that I never have had problem with tagged queuing using @@ -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. @@ -687,7 +687,7 @@ maintain the driver code. Enabling serial NVRAM support enables detection of the serial NVRAM included on Symbios and some Symbios compatible host adaptors, and Tekram boards. The serial NVRAM is used by Symbios and Tekram to hold set up parameters for the -host adaptor and it's attached drives. +host adaptor and its attached drives. The Symbios NVRAM also holds data on the boot order of host adaptors in a system with more than one host adaptor. This information is no longer used 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 |