1. 11 Oct, 2006 1 commit
    • Matthew Wilcox's avatar
      [SCSI] Add ability to scan scsi busses asynchronously · 3e082a91
      Matthew Wilcox authored
      
      
      Since it often takes around 20-30 seconds to scan a scsi bus, it's
      highly advantageous to do this in parallel with other things.  The bulk
      of this patch is ensuring that devices don't change numbering, and that
      all devices are discovered prior to trying to start init.  For those
      who build SCSI as modules, there's a new scsi_wait_scan module that will
      ensure all bus scans are finished.
      
      This patch only handles drivers which call scsi_scan_host.  Fibre Channel,
      SAS, SATA, USB and Firewire all need additional work.
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      3e082a91
  2. 07 Sep, 2006 1 commit
  3. 02 Sep, 2006 1 commit
    • Alan Stern's avatar
      [SCSI] SCSI: sanitize INQUIRY strings · e5b3cd42
      Alan Stern authored
      
      
      Sanitize the Vendor, Product, and Revision strings contained in an
      INQUIRY result by setting all non-graphic or non-ASCII characters to ' '.
      Since the standard disallows such characters, this will affect
      only non-compliant devices.
      
      To help maintain backward compatibility, NUL characters are treated
      specially.  They are taken as string terminators; they and all the
      following characters are set to ' '.  If some valid characters get
      erased as a result... well, we weren't seeing them before so we haven't
      lost anything.
      
      The primary purpose of this change is to allow blacklist entries to
      match devices with illegal Vendor or Product strings.
      
      In addition, the patch updates a couple of function prototypes, giving
      inq_result its correct type (unsigned char *).
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e5b3cd42
  4. 19 Aug, 2006 1 commit
    • dave wysochanski's avatar
      [SCSI] Don't add scsi_device for devices that return PQ=1, PDT=0x1f · 84961f28
      dave wysochanski authored
      
      
      Some targets may return slight variations of PQ and PDT to indicate
      no LUN mapped.  USB UFI setting PDT=0x1f but having reserved bits for
      PQ is one example, and NetApp targets returning PQ=1 and PDT=0x1f is
      another.  Both instances seem like reasonable responses according to
      SPC-3 and UFI specs.
      
      The current scsi_probe_and_add_lun() code adds a scsi_device
      for targets that return PQ=1 and PDT=0x1f.  This causes LUNs of type
      "UNKNOWN" to show up in /proc/scsi/scsi when no LUNs are mapped.
      In addition, subsequent rescans fail to recognize LUNs that may be
      added on the target, unless preceded by a write to the delete attribute
      of the "UNKNOWN" LUN.
      
      This patch addresses this problem by skipping over the scsi_add_lun()
      when PQ=1,PDT=0x1f is encountered, and just returns
      SCSI_SCAN_TARGET_PRESENT.
      Signed-off-by: default avatarDave Wysochanski <davidw@netapp.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      84961f28
  5. 06 Aug, 2006 2 commits
  6. 30 Jun, 2006 1 commit
  7. 28 Jun, 2006 1 commit
    • Brian King's avatar
      [SCSI] scsi: Device scanning oops for offlined devices (resend) · 309bd271
      Brian King authored
      
      
      If a device gets offlined as a result of the Inquiry sent
      during scanning, the following oops can occur. After the
      disk gets put into the SDEV_OFFLINE state, the error handler
      sends back the failed inquiry, which wakes the thread doing
      the scan. This starts a race between the scanning thread
      freeing the scsi device and the error handler calling
      scsi_run_host_queues to restart the host. Since the disk
      is in the SDEV_OFFLINE state, scsi_device_get will still
      work, which results in __scsi_iterate_devices getting
      a reference to the scsi disk when it shouldn't.
      
      The following execution thread causes the oops:
      
      CPU 0 (scan)				CPU 1 (eh)
      
      ---------------------------------------------------------
      scsi_probe_and_add_lun
                              ....
                                              scsi_eh_offline_sdevs
                                              scsi_eh_flush_done_q
      scsi_destroy_sdev
      scsi_device_dev_release
                                              scsi_restart_operations
                                               scsi_run_host_queues
                                                __scsi_iterate_devices
                                                 get_device
      scsi_device_dev_release_usercontext
                                                scsi_run_queue
                                                  <---OOPS--->
      
      The patch fixes this by changing the state of the sdev to SDEV_DEL
      before doing the final put_device, which should prevent the race
      from occurring.
      
      Original oops follows:
      
      Badness in kref_get at lib/kref.c:32
      Call Trace:
      [C00000002F4476D0] [C00000000000EE20] .show_stack+0x68/0x1b0 (unreliable)
      [C00000002F447770] [C00000000037515C] .program_check_exception+0x1cc/0x5a8
      [C00000002F447840] [C00000000000446C] program_check_common+0xec/0x100
       Exception: 700 at .kref_get+0x10/0x28
          LR = .kobject_get+0x20/0x3c
      [C00000002F447B30] [C00000002F447BC0] 0xc00000002f447bc0 (unreliable)
      [C00000002F447BB0] [C000000000254BDC] .get_device+0x20/0x3c
      [C00000002F447C30] [D000000000063188] .scsi_device_get+0x34/0xdc [scsi_mod]
      [C00000002F447CC0] [D0000000000633EC] .__scsi_iterate_devices+0x50/0xbc [scsi_mod]
      [C00000002F447D60] [D00000000006A910] .scsi_run_host_queues+0x34/0x5c [scsi_mod]
      [C00000002F447DF0] [D000000000069054] .scsi_error_handler+0xdb4/0xe44 [scsi_mod]
      [C00000002F447EE0] [C00000000007B4E0] .kthread+0x128/0x178
      [C00000002F447F90] [C000000000025E84] .kernel_thread+0x4c/0x68
      Unable to handle kernel paging request for <7>PCI: Enabling device: (0002:41:01.1), cmd 143
      data at address 0x000001b8
      Faulting instruction address: 0xd0000000000698e4
      sym1: <1010-66> rev 0x1 at pci 0002:41:01.1 irq 216
      sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking
      sym1: SCSI BUS has been reset.
      scsi2 : sym-2.2.2
      cpu 0x0: Vector: 300 (Data Access) at [c00000002f447a30]
          pc: d0000000000698e4: .scsi_run_queue+0x2c/0x218 [scsi_mod]
          lr: d00000000006a904: .scsi_run_host_queues+0x28/0x5c [scsi_mod]
          sp: c00000002f447cb0
         msr: 9000000000009032
         dar: 1b8
       dsisr: 40000000
        current = 0xc0000000045fecd0
        paca    = 0xc00000000048ee80
          pid   = 1123, comm = scsi_eh_1
      enter ? for help
      [c00000002f447d60] d00000000006a904 .scsi_run_host_queues+0x28/0x5c [scsi_mod]
      [c00000002f447df0] d000000000069054 .scsi_error_handler+0xdb4/0xe44 [scsi_mod]
      [c00000002f447ee0] c00000000007b4e0 .kthread+0x128/0x178
      [c00000002f447f90] c000000000025e84 .kernel_thread+0x4c/0x68
      Signed-off-by: default avatarBrian King <brking@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      309bd271
  8. 10 Jun, 2006 1 commit
  9. 28 May, 2006 1 commit
  10. 15 Apr, 2006 1 commit
  11. 14 Apr, 2006 3 commits
    • Kurt Garloff's avatar
      [SCSI] BLIST_ATTACH_PQ3 flags · 13f7e5ac
      Kurt Garloff authored
      
      
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This is patch 3/3:
      3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
         scanning code register PQ3 devices and continues scanning; only sg
         will attach thanks to scsi_bus_match().
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      13f7e5ac
    • Kurt Garloff's avatar
      [SCSI] Better log messages for PQ3 devs · 6c7154c9
      Kurt Garloff authored
      
      
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This patch 2/3:
      If a PQ3 device is found, log a message that describes the device
      (INQUIRY DATA and C:B:T:U tuple) and make a suggestion for blacklisting
      it.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      6c7154c9
    • Kurt Garloff's avatar
      [SCSI] Try LUN 1 and use bflags · 4186ab19
      Kurt Garloff authored
      
      
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This is patch 1/3:
      If we end up in sequential scan, at least try LUN 1 for devices
      that reported a PQ of 3 for LUN 0.
      Also return blacklist flags, even for PQ3 devices.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4186ab19
  12. 13 Apr, 2006 1 commit
  13. 14 Mar, 2006 1 commit
  14. 12 Mar, 2006 1 commit
  15. 28 Feb, 2006 7 commits
  16. 14 Feb, 2006 1 commit
    • James Bottomley's avatar
      [SCSI] fix wrong context bugs in SCSI · 65110b21
      James Bottomley authored
      
      
      There's a bug in releasing scsi_device where the release function
      actually frees the block queue.  However, the block queue release
      calls flush_work(), which requires process context (the scsi_device
      structure may release from irq context).  Update the release function
      to invoke via the execute_in_process_context() API.
      
      Also clean up the scsi_target structure releasing via this API.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      65110b21
  17. 14 Jan, 2006 1 commit
    • Christoph Hellwig's avatar
      [SCSI] remove target parent limitiation · e02f3f59
      Christoph Hellwig authored
      
      
      When James Smart fixed the issue of the userspace scan atributes
      crashing the system with the FC transport class he added a patch to
      let the transport class check if the parent is valid for a given
      transport class.
      
      When adding support for the integrated raid of fusion sas devices
      we ran into a problem with that, as it didn't allow adding virtual
      raid volumes without the transport class knowing about it.
      
      So this patch adds a user_scan attribute instead, that takes over from
      scsi_scan_host_selected if the transport class sets it and thus lets
      the transport class control the user-initiated scanning.  As this
      plugs the hole about user-initiated scanning the target_parent hook
      goes away and we rely on callers of the scanning routines to do
      something sensible.
      
      For SAS this meant I had to switch from a spinlock to a mutex to
      synchronize the topology linked lists, in FC they were completely
      unsynchronized which seems wrong.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e02f3f59
  18. 12 Jan, 2006 1 commit
  19. 26 Dec, 2005 1 commit
  20. 17 Dec, 2005 1 commit
  21. 14 Dec, 2005 1 commit
  22. 12 Dec, 2005 2 commits
  23. 09 Nov, 2005 1 commit
  24. 08 Nov, 2005 1 commit
  25. 29 Oct, 2005 2 commits
  26. 28 Oct, 2005 1 commit
  27. 25 Sep, 2005 1 commit
  28. 18 Sep, 2005 1 commit
    • Alan Stern's avatar
      [SCSI] SCSI scanning and removal fixes · a64358db
      Alan Stern authored
      
      
      This patch (as545) fixes the list traversals in __scsi_remove_target and
      scsi_forget_host.  In each case the existing code list_for_each_entry_safe
      in an _unsafe_ manner, because the list was not protected from outside
      modification while the iteration was running.
      
      The new scsi_forget_host routine takes the moderately controversial step
      of iterating over devices for removal rather than iterating over targets.
      This makes more sense to me because the current scheme treats targets as
      second-class citizens, created and removed on demand, rather than as
      objects corresponding to actual hardware.  (Also I couldn't figure out any
      safe way to iterate over the target list, since it's not so easy to tell
      when a target has already been removed.)
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      a64358db
  29. 10 Sep, 2005 1 commit