Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 6月, 2009 8 次提交
  3. 03 4月, 2009 1 次提交
  5. 27 7月, 2008 1 次提交
  7. 05 6月, 2008 1 次提交
  9. 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
  11. 08 4月, 2008 1 次提交
    • M
      [SCSI] mptsas: do not use ioc->handle to locate hba portinfo structure · 7748369f
      由 Michael Reed 提交于 
      While performing hardware raid reset testing via the raid's client, I
noticed that sometimes, following the reset, that there would be more
raid targets in the lsscsi output than there actually were raid
targets.  I tracked this down to the following issue.

Fusion cannot always find the mptsas_portinfo structure for the hba
because it uses the handle stored in ioc->handle to locate it.  The
problem is that the firmware can change the handle associated with the
hba when h/w raid is reset (via the raid client).  When this happens,
the driver will allocate another mptsas_portinfo structure and link it
into the chain of said structures.  This ultimately causes confusion
within the driver resulting in targets not being removed when they
should be.

Eric Moore pointed out that the hba's portinfo structure is always the
first structure on the sas_topology list.  This patch modifies
mptsas.c to access the hba's portinfo structure by taking the first
structure on said list.
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>
      7748369f
  13. 06 3月, 2008 1 次提交
  15. 12 1月, 2008 1 次提交
  17. 13 10月, 2007 12 次提交
  19. 01 8月, 2007 1 次提交
  21. 28 7月, 2007 1 次提交
  23. 19 7月, 2007 2 次提交
  25. 18 6月, 2007 1 次提交
  27. 11 3月, 2007 1 次提交
    • J
      [SCSI] mptsas: Fix oops for insmod during kexec · ba76ef24
      由 Judith Lebzelter 提交于 
      This fix's an oops during driver load time.   mptsas_probe calls
mpt_attach(over in mptbase.c).  Inside that call, we read some
manufacturing config pages to setup some defaults.  While reading the
config pages, the firmware doesn't complete the reply in time, and we
have a timeout. The timeout results in hardreset handler being called.
The hardreset handler calls all the fusion upper layer driver reset
callback handlers.  The mptsas_ioc_reset function is the callback
handler in mptsas.c.   So where I'm getting to, is mptsas_ioc_reset is
getting called before scsi_host_alloc is called, and the pointer ioc->sh
is NULL as well as the hostdata. 
Signed-off-by: NJudith Lebzelter <judith@osdl.org>
Acked-by: N"Moore, Eric" <Eric.Moore@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      ba76ef24
  29. 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
  31. 03 2月, 2007 5 次提交
  33. 06 1月, 2007 1 次提交