Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 6月, 2009 3 次提交
    • K
      [SCSI] mpt fusion: rewrite taskmgmt request and completion routines · 1ba9ab2e
      由 Kashyap, Desai 提交于 
      1.)	 rewrite taskmanagement request and completion routines, making them
single threaded and using the generic MPT_MGMT struct, deleting
mptscsih_TMHandler, replacing with single request TM handler
mptscsih_IssueTaskMgmt, and killing the watchdog timer functions.
2.) cleanup ioc_reset callback handlers, introducing wrappers for
synchronizing error recovery (mpt_set_taskmgmt_in_progress_flag,
mpt_clear_taskmgmt_in_progress_flag), as the fusion firmware only handles
one task management request at a time
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      1ba9ab2e
    • K
      [SCSI] mpt fusion: rewrite of all internal generated functions · 37c60f37
      由 Kashyap, Desai 提交于 
      Rewrite of all internal generated functions that issue commands to firmware,
porting them to be single threaded using the generic MPT_MGMT
struct. Implemented using completion Queue.
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      37c60f37
    • K
      [SCSI] mpt fusion: Fixing 1078 data corruption issue for 36GB memory region · 14d0f0b0
      由 Kashyap, Desai 提交于 
      The reason for this change is there is a data corruption when four different
physical memory regions in the 36GB to 37GB region are
accessed. This is only affecting 1078.

The solution is we need to use different addressing when filling in
the scatter gather table for the effected memory regions.  So instead
of snooping on all four different memory holes, we treat any physical
addresses in the 36GB address with the same algorithm.

The fix is explained below
1) Ensure that the message frames are NOT located in the trouble
region. There is no remapping available for message frames, they must
be allocated outside the problem region.
2) Ensure that Sense buffers are NOT in the trouble region. There is
no remapping available.
3) Walk through the SGE entries and if any are inside the trouble region
   then they need to be remapped as discussed below.
	1) Set the Local Address bit in the SGE Flags field.
  	MPI_SGE_FLAGS_LOCAL_ADDRESS
  	2) Ensure we are using 64-bit SGEs
  	3) Set MSb (Bit 63) of the 64-bit address, this will indicate buffer
	location is Host Memory.
Signed-off-by: NKashyap Desai <kadesai@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      14d0f0b0
  3. 14 1月, 2009 1 次提交
  5. 17 12月, 2008 1 次提交
  7. 24 10月, 2008 1 次提交
  9. 27 7月, 2008 1 次提交
  11. 05 6月, 2008 1 次提交
  13. 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
  15. 20 4月, 2008 1 次提交
  17. 08 4月, 2008 1 次提交
  19. 19 3月, 2008 1 次提交
  21. 04 3月, 2008 2 次提交
  23. 03 2月, 2008 1 次提交
  25. 24 1月, 2008 1 次提交
  27. 16 10月, 2007 2 次提交
  29. 13 10月, 2007 8 次提交
  31. 28 7月, 2007 1 次提交
  33. 19 7月, 2007 1 次提交
  35. 18 6月, 2007 4 次提交
  37. 30 5月, 2007 1 次提交
  39. 23 5月, 2007 1 次提交
  41. 21 3月, 2007 3 次提交
  43. 20 3月, 2007 1 次提交
  45. 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
  47. 03 2月, 2007 1 次提交