1. 23 8月, 2009 1 次提交
  2. 10 6月, 2009 4 次提交
  3. 27 7月, 2008 1 次提交
  4. 22 7月, 2008 1 次提交
  5. 05 6月, 2008 1 次提交
  6. 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
  7. 13 10月, 2007 8 次提交
  8. 28 7月, 2007 1 次提交
  9. 19 7月, 2007 2 次提交
  10. 18 6月, 2007 2 次提交
  11. 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
  12. 03 2月, 2007 2 次提交
  13. 06 1月, 2007 1 次提交
  14. 08 12月, 2006 1 次提交
  15. 22 11月, 2006 1 次提交
  16. 26 10月, 2006 1 次提交
  17. 07 8月, 2006 3 次提交
  18. 13 7月, 2006 1 次提交
  19. 29 6月, 2006 1 次提交
  20. 28 6月, 2006 1 次提交
  21. 11 6月, 2006 4 次提交
  22. 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