1. 10 Apr, 2015 1 commit
  2. 25 Jul, 2014 1 commit
  3. 15 Mar, 2014 1 commit
  4. 20 Jul, 2012 1 commit
  5. 19 Feb, 2012 2 commits
  6. 31 Mar, 2011 1 commit
  7. 07 Oct, 2010 1 commit
  8. 05 Sep, 2010 1 commit
  9. 11 Apr, 2010 1 commit
    • Christof Schmitt's avatar
      [SCSI] Allow FC LLD to fast-fail scsi eh by introducing new eh return · 2f2eb587
      Christof Schmitt authored
      If the scsi eh is running and then a FC LLD calls
      fc_remote_port_delete, the SCSI commands sent from the eh will fail.
      To prevent this, a FC LLD can call fc_block_scsi_eh from the eh
      callback, blocking the eh thread until the dev_loss_tmo fires or the
      remote port is available again.
      If (e.g. for a multipathing setup) the dev_loss_tmo is set to a very
      large value, thus preventing the scsi device removal , the scsi eh can
      block for a long time. For multipathing, the fast_io_fail_tmo is then
      set to a low value to detect path problems sooner.
      This patch introduces a new return code FAST_IO_FAIL. The function
      fc_block_scsi_eh now returns FAST_IO_FAIL when the fast_io_fail_tmo
      fires. This indicates that the LLD terminated all pending I/O requests
      and there are no more pending SCSI commands for the scsi eh to wait
      for. This return code can be passed back to the scsi eh to stop the
      escalation and finish the recovery process for this device.
      Signed-off-by: default avatarChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
  10. 04 Dec, 2009 1 commit
  11. 12 Jun, 2009 1 commit
    • James Smart's avatar
      [SCSI] FC Pass Thru support · 9e4f5e29
      James Smart authored
      Attached is the ELS/CT pass-thru patch for the FC Transport. The patch
      creates a generic framework that lays on top of bsg and the SGIO v4 ioctl
      in order to pass transaction requests to LLDD's.
      The interface supports the following operations:
        On an fc_host basis:
          Request login to the specified N_Port_ID, creating an fc_rport.
          Request logout of the specified N_Port_ID, deleting an fc_rport
          Send ELS request to specified N_Port_ID w/o requiring a login, and
            wait for ELS response.
          Send CT request to specified N_Port_ID and wait for CT response.
            Login is required, but LLDD is allowed to manage login and decide
            whether it stays in place after the request is satisfied.
          Vendor-Unique request. Allows a LLDD-specific request to be passed
            to the LLDD, and the passing of a response back to the application.
        On an fc_rport basis:
          Send ELS request to nport and wait for ELS response.
          Send CT request to nport and wait for CT response.
      The patch also exports several headers from include/scsi such that
      they can be available to user-space applications:
      For further information, refer to the last RFC:
      Note: Documentation is still spotty and will be added later.
      [bharrosh@panasas.com: update for new block API]
      Signed-off-by: default avatarJames Smart <james.smart@emulex.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
  12. 15 May, 2009 1 commit
    • Andrew Vasquez's avatar
      [SCSI] fc-transport: Close state transition-window during rport deletion. · 9a1a69a1
      Andrew Vasquez authored
      Andrew Vasquez wrote:
      > fc-transport: Close state transition-window during rport deletion.
      > After an rport's state has transitioned to FC_PORTSTATE_BLOCKED,
      > but, prior to making the upcall to 'block' the scsi-target
      > associated with an rport, queued commands can recycle and
      > ultimately run out of retries causing failures to propagate to
      > upper-level drivers.  Close this transition-window by returning
      > the non-'retries' modifying DID_IMM_RETRY status for submitted
      > I/Os.
      The same can happen for iscsi when transitioning from logged in
      to failed and blocking the sdevs.
      This patch converts iscsi and fc's transitions back to use DID_IMM_RETRY
      instead of DID_TRANSPORT_DISRUPTED which has a limited number of retries
      that we do not want to use for handling this race.
      Signed-off-by: default avatarAndrew Vasquez <andrew.vasquez@qlogic.com>
      [Addition of iscsi and fc port online devloss case conversion by Mike Christie]
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
  13. 06 Jan, 2009 1 commit
  14. 21 Nov, 2008 1 commit
  15. 13 Oct, 2008 2 commits
    • Mike Christie's avatar
      [SCSI] fc class: Add support for new transport errors · f46e307d
      Mike Christie authored
      If the target is blocked and fast io fail tmo has not fired
      then we requeue with DID_TRANSPORT_DISRUPTED. Once that
      tmo fires we fail with DID_TRANSPORT_FAILFAST.
      - seperate from
      "fc class: unblock target after calling terminate callback"
      to make it easier to review.
      - Add JamesS's ack from list.
      - initial patch
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Acked-by: default avatarJames Smart <James.Smart@emulex.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
    • Mike Christie's avatar
      [SCSI] fc class: unblock target after calling terminate callback (take 2) · fff9d40c
      Mike Christie authored
      When we block a rport and the driver implements the terminate
      callback we will fail IO that was running quickly. However
      IO that was in the scsi_device/block queue sits there until
      the dev_loss_tmo fires, and this can make it look like IO is
      lost because new IO will get executed but that IO stuck in
      the blocked queue sits there for some time longer.
      With this patch when the fast io fail tmo fires, we will
      fail the blocked IO and any new IO. This patch also allows
      all drivers to partially support the fast io fail tmo. If the
      terminate io callback is not implemented, we will still fail blocked
      IO and any new IO, so multipath can handle that.
      This patch also allows the fc and iscsi classes to implement the
      same behavior. The timers are just unfornately named differently.
      This patch also fixes the problem where drivers were unblocking
      the target in their terminate callback, which was needed for
      rport removal, but for fast io fail timeout it would cause
      IO to bounce arround the scsi/block layer and the LLD queuecommand.
      And it for drivers that could have IO stuck but did not have
      a terminate callback the unblock calls in the class will fix
      - fix up bit setting style to meet JamesS's pref.
      - Broke out new host byte error changes to make it easier to read.
      - added JamesS's ack from list.
      - initial patch
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Acked-by: default avatarJames Smart <James.Smart@emulex.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
  16. 03 Oct, 2008 1 commit
  17. 21 Jul, 2008 1 commit
  18. 19 Apr, 2008 1 commit
  19. 03 Feb, 2008 1 commit
  20. 12 Oct, 2007 2 commits
  21. 26 May, 2007 1 commit
  22. 16 May, 2007 1 commit
    • James Smart's avatar
      [SCSI] FC Transport support for vports based on NPIV · a53eb5e0
      James Smart authored
      This patch provides support for FC virtual ports based on NPIV.
      For information on the interfaces and design, please read the
      Documentation/scsi/scsi_fc_transport.txt file enclosed within
      the patch.
      The RFC was originally posted here:
      Changes from the initial RFC:
      - Bug fix: needed a transport_class_unregister() for the vport class
      - Create a symlink to the vport in the shost device if it is not the
          parent of the vport.
      - Made symbolic name writable so it can be set after creation
      - Made the temporary fc_vport_identifiers struct private to the
      - Deleted the vport_id field from the vport. I couldn't find any good
        use for it (and symname is a good replacement).
      - Made the vport_state and vport_last_state "private" attributes.
        Added the fc_vport_set_state() helper function to manage state
      - Updated vport_create() to allow a vport to be created in a disabled
      - Added INITIALIZING and FAILED vport states
      - Added VPCERR_xxx defines for errors to be returned from vport_create()
      - Created a Documentation/scsi/scsi_fc_transport.txt file that describes
        the interfaces and expected LLDD behaviors.
      Signed-off-by: default avatarJames Smart <James.Smart@emulex.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  23. 20 Mar, 2007 1 commit
  24. 22 Nov, 2006 1 commit
  25. 04 Sep, 2006 1 commit
  26. 02 Sep, 2006 2 commits
  27. 19 Aug, 2006 2 commits
  28. 26 Apr, 2006 1 commit
  29. 13 Apr, 2006 1 commit
    • James Smart's avatar
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      James Smart authored
      As previously reported via Michael Reed, the FC transport took a hit
      in 2.6.15 (perhaps a little earlier) when we solved a recursion error.
      There are 2 deadlocks occurring:
      - With scan and the delete items sharing the same workq, flushing the
        workq for the delete code was getting it stalled behind a very long
        running scan code path.
      - There's a deadlock where scsi_remove_target() has to sit behind
        scsi_scan_target() due to contention over the scan_lock().
      This patch resolves the 1st deadlock and significantly reduces the
      odds of the second. So far, we have only replicated the 2nd deadlock
      on a highly-parallel SMP system. More on the 2nd deadlock in a following
      This patch reworks the transport to:
      - Only use the scsi host workq for scanning
      - Use 2 other workq's internally. One for deletions, the other for
        scheduled deletions. Originally, we tried this with a single workq,
        but the occassional flushes of the scheduled queues was hitting the
        second deadlock with a slightly higher frequency. In the future, we'll
        look at the LLDD's and the transport to see if we can get rid of this
        extra overhead.
      - When moving to the other workq's we tightened up some object states
        and some lock handling.
      - Properly syncs adds/deletes
      - minor code cleanups
        - directly reference fc_host_attrs, rather than through attribute
        - flush the right workq on delayed work cancel failures.
      Large kudos to Michael Reed who has been working this issue for the last
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  30. 14 Jan, 2006 1 commit
  31. 15 Dec, 2005 1 commit
    • James.Smart@Emulex.Com's avatar
      [SCSI] fix for fc transport recursion problem. · 42e33148
      James.Smart@Emulex.Com authored
      In the scenario that a link was broken, the devloss timer for each
      rport was expire at roughly the same time, causing lots of "delete"
      workqueue items being queued. Depth is dependent upon the number of
      rports that were on the link.
      The rport target remove calls were calling flush_scheduled_work(),
      which would interrupt the stream, and start the next workqueue item,
      which did the same thing, and so on until recursion depth was large.
      This fix stops the recursion in the initial delete path, and pushes it
      off to a host-level work item that reaps the dead rports.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  32. 30 Oct, 2005 1 commit
    • Tim Schmielau's avatar
      [PATCH] fix missing includes · 4e57b681
      Tim Schmielau authored
      I recently picked up my older work to remove unnecessary #includes of
      sched.h, starting from a patch by Dave Jones to not include sched.h
      from module.h. This reduces the number of indirect includes of sched.h
      by ~300. Another ~400 pointless direct includes can be removed after
      this disentangling (patch to follow later).
      However, quite a few indirect includes need to be fixed up for this.
      In order to feed the patches through -mm with as little disturbance as
      possible, I've split out the fixes I accumulated up to now (complete for
      i386 and x86_64, more archs to follow later) and post them before the real
      patch.  This way this large part of the patch is kept simple with only
      adding #includes, and all hunks are independent of each other.  So if any
      hunk rejects or gets in the way of other patches, just drop it.  My scripts
      will pick it up again in the next round.
      Signed-off-by: default avatarTim Schmielau <tim@physik3.uni-rostock.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  33. 28 Oct, 2005 2 commits
    • James.Smart@Emulex.Com's avatar
      [SCSI] update fc_transport for removal of block/unblock functions · 19a7b4ae
      James.Smart@Emulex.Com authored
      We recently went back to implement a board reset. When we perform the
      reset, we wanted to tear down the internal data structures and rebuild
      them. Unfortunately, when it came to the rport structure, things were
      odd. If we deleted them, the scsi targets and sdevs would be
      torn down. Not a good thing for a temporary reset. We could block the
      rports, but we either maintain the internal structures to keep the
      rport reference (perhaps even replicating what's in the transport),
      or we have to fatten the fc transport with new search routines to find
      the rport (and deal with a case of a dangling rport that the driver
      It dawned on me that we had actually reached this state incorrectly.
      When the fc transport first started, we did the block/unblock first, then
      added the rport interface. The purpose of block/unblock is to hide the
      temporary disappearance of the rport (e.g. being deleted, then readded).
      Why are we making the driver do the block/unblock ? We should be making
      the transport have only an rport add/delete, and the let the transport
      handle the block/unblock.
      So... This patch removes the existing fc_remote_port_block/unblock
      functions. It moves the block/unblock functionality into the
      fc_remote_port_add/delete functions.  Updates for the lpfc driver are
      included. Qlogic driver updates are also enclosed, thanks to the
      contributions of Andrew Vasquez. [Note: the qla2xxx changes are
      relative to the scsi-misc-2.6 tree as of this morning - which does
      not include the recent patches sent by Andrew]. The zfcp driver does
      not use the block/unblock functions.
      One last comment: The resulting behavior feels very clean. The LLDD is
      concerned only with add/delete, which corresponds to the physical
      disappearance.  However, the fact that the scsi target and sdevs are
      not immediately torn down after the LLDD calls delete causes an
      interesting scenario... the midlayer can call the xxx_slave_alloc and
      xxx_queuecommand functions with a sdev that is at the location the
      rport used to be. The driver must validate the device exists when it
      first enters these functions. In thinking about it, this has always
      been the case for the LLDD and these routines. The existing drivers
      already check for existence. However, this highlights that simple
      validation via data structure dereferencing needs to be watched.
      To deal with this, a new transport function, fc_remote_port_chkready()
      was created that LLDDs should call when they first enter these two
      routines. It validates the rport state, and returns a scsi result
      which could be returned. In addition to solving the above, it also
      creates consistent behavior from the LLDD's when the block and deletes
      are occuring.
      Rejections fixed up and
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Andrew Vasquez's avatar
      [SCSI] Add an 'Issue LIP' device attribute in fc_transport class · 91ca7b01
      Andrew Vasquez authored
      Ok, here's a patch to add such a common API for fc transport users.
      Relevant LLD changes (lpfc and qla2xxx) also present.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  34. 16 Sep, 2005 1 commit
    • Andreas Herrmann's avatar
      [SCSI] change port speed definitions for scsi_transport_fc · 1832a586
      Andreas Herrmann authored
      obviously FC Port Speeds in scsi_transport_fc.h are defined according
      to FC-HBA:
      #define FC_PORTSPEED_1GBIT              1
      #define FC_PORTSPEED_2GBIT              2
      #define FC_PORTSPEED_10GBIT             4
      #define FC_PORTSPEED_4GBIT              8
      Problem is, whoever invented FC-HBA did not care about FC-FS or
      FC-GS-x. Following FC-FS/FC-GS-x defintions of port speeds would look
      1 GBit: 0x0001
      2 GBit: 0x0002
      4 GBit: 0x0004
      10GBit: 0x0008
      (and new in FC-LS:
      8 Gbit: 0x0010
      16GBit: 0x0020)
      I really appreciate if scsi_transport_fc.h would define port speeds
      according to FC-GS-x/FC-FS. Thus mapping of port speed capabilities to
      values defined in scsi_transport_fc.h can be avoided in the LLDD.
      Attached is a patch to change the definitions.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>