1. 14 Jan, 2006 1 commit
  2. 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>
      42e33148
  3. 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>
      4e57b681
  4. 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
      forgets).
      
      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>
      19a7b4ae
    • 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>
      91ca7b01
  5. 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
      like:
      
      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>
      1832a586
  6. 10 Sep, 2005 1 commit
  7. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4