1. 28 May, 2006 1 commit
  2. 15 Apr, 2006 1 commit
  3. 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
  4. 13 Apr, 2006 1 commit
  5. 14 Mar, 2006 1 commit
  6. 12 Mar, 2006 1 commit
  7. 28 Feb, 2006 7 commits
  8. 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
  9. 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
  10. 12 Jan, 2006 1 commit
  11. 26 Dec, 2005 1 commit
  12. 17 Dec, 2005 1 commit
  13. 14 Dec, 2005 1 commit
  14. 12 Dec, 2005 2 commits
  15. 09 Nov, 2005 1 commit
  16. 08 Nov, 2005 1 commit
  17. 29 Oct, 2005 2 commits
  18. 28 Oct, 2005 1 commit
  19. 25 Sep, 2005 1 commit
  20. 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
  21. 10 Sep, 2005 2 commits
  22. 09 Sep, 2005 1 commit
  23. 28 Aug, 2005 2 commits
  24. 08 Aug, 2005 1 commit
    • James.Smart@Emulex.Com's avatar
      [SCSI] fix target scanning oops with fc transport class · 5c44cd2a
      James.Smart@Emulex.Com authored
      
      
      We have some nasty issues with 2.6.12-rc6. Any request to scan on
      the lpfc or qla2xxx FC adapters will oops. What is happening is the
      system is defaulting to non-transport registered targets, which
      inherit the parent of the scan. On this second scan, performed by
      the attribute, the parent becomes the shost instead of the rport.
      The slave functions in the 2 FC adapters use starget_to_rport()
      routines, which incorrectly map the shost as an rport pointer.
      
      Additionally, this pointed out other weaknesses:
      - If the target structure is torn down outside of the transport,
        we have no method for it to be regenerated at the proper parent.
      - We have race conditions on the target being allocated by both
        the midlayer scan (parent=shost) and by the fc transport
        (parent=rport).
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      5c44cd2a
  25. 30 Jul, 2005 1 commit
  26. 27 Jul, 2005 1 commit
  27. 14 Jul, 2005 1 commit
    • James.Smart@Emulex.Com's avatar
      [SCSI] add int_to_scsilun() function · 2f4701d8
      James.Smart@Emulex.Com authored
      One of the issues we had was reverting the midlayers lun value
      into the 8byte lun value that we wanted to send to the device.
      Historically, there's been some combination of byte swapping,
      setting high/low, etc. There's also been no common thread between
      how our driver did it and others.  I also got very confused as
      to why byteswap routines were being used.
      
      Anyway, this patch is a LLDD-callable function that reverts the
      midlayer's lun value, stored in an int, to the 8-byte quantity
      (note: this is not the real 8byte quantity, just the same amount
      that scsilun_to_int() was able to convert and store originally).
      
      This also solves the dilemma of the thread:
      http://marc.theaimsgroup.com/?l=linux-kernel&m=112116767118981&w=2
      
      
      
      A patch for the lpfc driver to use this function will be along
      in a few days (batched with other patches).
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      2f4701d8
  28. 03 Jun, 2005 1 commit
    • Nathan Lynch's avatar
      [SCSI] fix slab corruption during ipr probe · c92715b3
      Nathan Lynch authored
      With CONFIG_DEBUG_SLAB=y I see slab corruption messages during boot on
      pSeries machines with IPR adapters with any 2.6.12-rc kernel.
      
      The change which seems to have introduced the problem is "SCSI: revamp
      target scanning routines" and may be found at:
      http://marc.theaimsgroup.com/?l=bk-commits-head&m=111093946426333&w=2
      
      In order to revert that in a 2.6.12-rc1 tree, I had to revert "target
      code updates to support scanned targets" first:
      http://marc.theaimsgroup.com/?l=bk-commits-head&m=111094132524649&w=2
      
      
      
      With both patches reverted, the corruption messages go away.
      
      ipr: IBM Power RAID SCSI Device Driver version: 2.0.13 (February 21,
      2005)
      ipr 0001:d0:01.0: Found IOA with IRQ: 167
      ipr 0001:d0:01.0: Starting IOA initialization sequence.
      ipr 0001:d0:01.0: Adapter firmware version: 020A005C
      ipr 0001:d0:01.0: IOA initialized.
      scsi0 : IBM 570B Storage Adapter
        Vendor: IBM       Model: VSBPD4E1  U4SCSI  Rev: 4770
        Type:   Enclosure                          ANSI SCSI revision: 02
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM       Model: VSBPD4E1  U4SCSI  Rev: 4770
        Type:   Enclosure                          ANSI SCSI revision: 02
      Slab corruption: start=c0000001e8de5268, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<c00000000029c3a0>](.scsi_target_dev_release+0x28/0x50)
      080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a
      Prev obj: start=c0000001e8de5050, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<0000000000000000>](0x0)
      000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      Next obj: start=c0000001e8de5480, len=512
      Redzone: 0x170fc2a5/0x170fc2a5.
      Last user: [<c000000000228d7c>](.as_init_queue+0x5c/0x228)
      000: c0 00 00 01 e8 83 26 08 00 00 00 00 00 00 00 00
      010: 00 00 00 00 00 00 00 00 c0 00 00 01 e8 de 54 98
      Slab corruption: start=c0000001e8de5268, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<c00000000029c3a0>](.scsi_target_dev_release+0x28/0x50)
      080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a
      Prev obj: start=c0000001e8de5050, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<0000000000000000>](0x0)
      000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      Next obj: start=c0000001e8de5480, len=512
      Redzone: 0x170fc2a5/0x170fc2a5.
      Last user: [<c000000000228d7c>](.as_init_queue+0x5c/0x228)
      000: c0 00 00 01 e8 83 26 08 00 00 00 00 00 00 00 00
      010: 00 00 00 00 00 00 00 00 c0 00 00 01 e8 de 54 98
      ...
      
      I did some digging and the problem seems to be a refcounting issue in
      __scsi_add_device.  The target gets freed in scsi_target_reap, and
      then __scsi_add_device tries to do another device_put on it.
      Signed-off-by: default avatarNathan Lynch <ntl@pobox.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c92715b3