1. 22 7月, 2008 1 次提交
  2. 05 6月, 2008 1 次提交
  3. 27 5月, 2008 1 次提交
    • M
      [SCSI] fusion mpt: fix target missing after resetting external raid · 7ba2db5f
      Michael Reed 提交于
      Following a hard reset of a SAS raid, one of the raid targets is occasionally
      missing.  I tracked this down to a pretty obscure little bug.
      
      The LSI fusion drivers for SAS and Fibre Channel both use their respective
      transport layers.  Those transport layers increment the target number
      assigned to new targets.
      
      The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host
      structure to avoid scanning the scsi host adapter.  Both fusion drivers set
      "this_id" from a value returned in a firmware PortFacts response.  For my
      particular test case (SAS) the firmware id assigned to the initiator was
      173.  After enough raid resets to cause the raid targets to go and come a
      sufficient number of times, the id assigned by the transport to a raid
      target would match the id assigned by the host adapter to the "this_id"
      field, resulting in that target not being scanned.
      
      Fix by not assigning this_id and not checking it in slave_configure. 
      Signed-off-by: NMichael Reed <mdr@sgi.com>
      Acked-by: N"Moore, Eric" <Eric.Moore@lsi.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ba2db5f
  4. 13 10月, 2007 8 次提交
  5. 28 7月, 2007 1 次提交
  6. 19 7月, 2007 2 次提交
  7. 18 6月, 2007 2 次提交
  8. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  9. 03 2月, 2007 2 次提交
  10. 06 1月, 2007 1 次提交
  11. 08 12月, 2006 1 次提交
  12. 22 11月, 2006 1 次提交
  13. 26 10月, 2006 1 次提交
  14. 07 8月, 2006 3 次提交
  15. 13 7月, 2006 1 次提交
  16. 29 6月, 2006 1 次提交
  17. 28 6月, 2006 1 次提交
  18. 11 6月, 2006 4 次提交
  19. 10 5月, 2006 1 次提交
    • M
      [SCSI] mptfc: race between mptfc_register_dev and mptfc_target_alloc · 6dd727da
      mdr@sgi.com 提交于
      A race condition exists in mptfc between the thread registering a device
      with the fc transport and the scan work generated by the transport.
      This race existed prior to the application of the mptfc bug fix patch.
      
      mptfc_register_dev() calls fc_remote_port_add() with the FC_RPORT_ROLE_TARGET
      bit set in the rport ids passed to the function.  Having this bit set causes
      fc_remote_port_add() to schedule a scan of the device.
      
      This scan can execute before mptfc_register_dev() can fill in the dd_data
      in the rport structure.  When this happens, mptfc_target_alloc() will fail
      because dd_data is null.
      
      Attached is a patch which fixes the problem.  The patch changes the rport ids
      passed to fc_remote_port_add() to not have the TARGET bit set.  This prevents
      the scan from being scheduled.  After mptfc_register_dev() fills in the rport
      dd_data field, fc_remote_port_rolechg() is called, changing the role of the
      rport to TARGET.  Thus, the scan is scheduled after dd_data is filled
      in which prevents the failure in mptfc_target_alloc().
      Signed-off-by: NMichael Reed <mdr@sgi.com>
      Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6dd727da
  20. 26 4月, 2006 1 次提交
    • M
      [SCSI] - fusion - mptfc bug fix's to prevent deadlock situations · 65207fed
      Moore, Eric 提交于
      mptbase.h
      
      	bump version number to 3.03.09
      
      	remove unneeded flags
      	define workq and remove old fc specific locks
      
      mptbase.c
      
      	initialize new lock and don't initialize two removed locks
      
      mptscsih.c
      
      	when firmware reports target is no longer there, return
              DID_REQUEUE for fc hosts so that i/o doesn't get killed until
              the transport has an opportunity to manage the loss via its
              dev loss timer
      
      	when the "eh_abort" routine is called, check to see if the
              driver has the command or not before looking to see if a reset
              is pending.  James Smart and I talked about this and believe
              that the API for this routine is: if driver doesn't have
              command, return SUCCESS.  This change helps prevent a target
              from being taken offline.  SUCCESS is returned because it's
              likely that the command completed after error recovery timed
              it out but before it could be aborted.
      
      	provide a routine to queue work to newly created workq, and
              use it.
      
      	remove "ioc" from mptscsih_abort() it was only used one time.
      	the other references were via hd->ioc, so I just moved it....
      	net change in references to ioc via hd->ioc is zero
      
      	move hd->resetPending test and hd->timeouts increment to after
      	the test for whether the command to be aborted remains known
      	to the driver
      
      	Make certain that the workq exists before queuing work to it.
      
      mptfc.c
      
      	no longer need to lock rport data structures as I was able to
      	single thread the code!  I fixed up the debug code to
      	eliminate compilation messages due to type mismatch in the
      	printk.  Got rid of some no longer needed rport flags.
      	Initialize and destroy the workq used for the rescan work.
      
      	simplify the logic regarding the increment of
              fc_rescan_work_count.  use post increment and test for zero
              vs. pre increment and test for one; eliminate work_count
              variable: queue_work can be called with the work_lock held as
              it doesn't sleep
      Signed-off-by: NMichael Reed <mdr@sgi.com>
      Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      65207fed
  21. 15 3月, 2006 2 次提交
  22. 28 2月, 2006 1 次提交
  23. 01 2月, 2006 1 次提交
  24. 15 1月, 2006 1 次提交