Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 7月, 2007 8 次提交
    • P
      [SCSI] mpt fusion: Changes in mptscsih.c for logging support · 6757d6b4
      由 Prakash, Sathya 提交于 
      This patch contains changes in mptscsih.c to support logging in MPT fusion
drivers.

The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h

A new sysfs attribute is added to retrieve and modify the debug level.
signed-off-by: NSathya Prakash <sathya.prakash@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6757d6b4
    • P
      [SCSI] mpt fusion: Changes in mptbase.c for logging support · 436ace72
      由 Prakash, Sathya 提交于 
      This patch contains changes in mptbase.c to support logging in MPT fusion
drivers.

The changes are majorly in debug printks, the existing debugprintk are
modified accroding to new debug macros defined in the file mptbdebug.h

A new module parameter mpt_debug_level is added to pass the debug level as
module parameter.
signed-off-by: NSathya Prakash <sathya.prakash@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      436ace72
    • P
      [SCSI] mpt fusion: logging support in Kconfig, Makefile, mptbase.h and addition of mptdebug.h · 5c1b91b9
      由 Prakash, Sathya 提交于 
      This patch adds a new file mptdebug.h in the fusion source directory,
which contains different debug macros.  The existing debug macros and
flags are removed from the mptbase.h and Makefile In Kconfig a new
configuration parameter FUSION_LOGGING is added to enable/disable the
logging support during compile time.
signed-off-by: NSathya Prakash <sathya.prakash@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      5c1b91b9
    • J
      [SCSI] libsas: Fix potential NULL dereference in sas_smp_get_phy_events() · 92631fa4
      由 Jesper Juhl 提交于 
      In sas_smp_get_phy_events() we never test if the call to
alloc_smp_req(RPEL_REQ_SIZE) succeeds or fails. That means we run
the risk of dereferencing a NULL pointer if it does fail. Far
better to test if we got NULL back and in that case return -ENOMEM
just as we already do for the other memory allocation in that
function.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      92631fa4
    • P
      [SCSI] bsg: Fix build for CONFIG_BLOCK=n · 99d4d0a9
      由 Paul Mundt 提交于 
      BLK_DEV_BSG was added outside of the if BLOCK check, which allows it to
be enabled when CONFIG_BLOCK=n. This leads to many screenlengths of
errors, starting with a parse error on the request_queue_t definition.
Obviously this wasn't intended for CONFIG_BLOCK=n usage, so just move the
option back in to the block.

Caught with a randconfig on sh.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NJens Axboe <jens.axboe@oracle.com>
Acked-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      99d4d0a9
    • S
      [SCSI] aacraid: fix Sunrise Lake reset handling · 9859c1aa
      由 Salyzyn, Mark 提交于 
      The patch is *much* smaller than the description. I am attempting to
answer to those that want to understand an issue that was reported in
May this year.

If a Sunrise Lake based card that requires an alternate reset mechanism
is set up to ignore the commanded IOP_RESET it reports 0x00000010
(IOP_RESET ignored) instead of 0x3803000F (use alternate reset mechanism
to reset all cores), and thus the reset platform function decides to
switch to IOP_RESET_ALWAYS because the reset platform function
parameters indicate that we *need* to reset the card. IOP_RESET_ALWAYS
then responds with the 0x3803000F return code, but alas we treat this as
an error instead of using the alternate reset mechanism (put a 0x03 into
the register offset 0x38). The reset fails, but the fact that the
IOP_RESET_ALWAYS command was issued has put the card in a purposeful
shutdown state in preparation for the alternate hardware reset to be
applied. Yuck.

IOP_RESET is ignored in internal production cards, typically to ensure
that we catch all adapter lockup issues without the driver progressing
further, so this would not appear to be a field issue and thus this
patch was destined to be only in the internal Adaptec source tree.
IOP_RESET_ALWAYS is reserved for
kexec/kdump/FirmwareUpdate/AutomatedTestFrames so we did not function as
expected in any case. Also in the past we have had OEMs specifically
request that cards not be resetable after a BlinkLED/FirmwareAssert for
one reason or another and To head off the possibility that the Sunrise
Lake based cards would suffer a similar fate, we propose the enclosed
fix.

Yinghai Lu of SUN had a pre-production card with IOP_RESET disabled when
he reported an issue to the linux kernel list back in May regarding a
kexec problem resulting from this reset being ignore. His fix was to
update the Firmware to one that did not ignore the IOP_RESET. Previous
kernels did not attempt to reset the adapter and that is why it surfaced
as a regression in his hands.

The current list of aacraid based cards that use Sunrise Lake:

9005:0285:9005:02b5     Adaptec 5445
9005:0285:9005:02b6     Adaptec 5805
9005:0285:9005:02b7     Adaptec 5085
9005:0285:9005:02c3     Adaptec 51205
9005:0285:9005:02c4     Adaptec 51605
9005:0285:9005:02ce     Adaptec 51245
9005:0285:9005:02cf     Adaptec 51645
9005:0285:9005:02d0     Adaptec 52445
9005:0285:9005:02d1     Adaptec 5405
9005:0285:9005:02b8     ICP     ICP5445SL
9005:0285:9005:02b9     ICP     ICP5085SL
9005:0285:9005:02ba     ICP     ICP5805SL
9005:0285:9005:02c5     ICP     ICP5125SL
9005:0285:9005:02c6     ICP     ICP5165SL
9005:0285:108e:7aac     SUN     STK RAID REM
9005:0285:108e:0286     SUN     STK RAID INT
9005:0285:108e:0287     SUN     STK RAID EXT
9005:0285:108e:7aae     SUN     STK RAID EM

All of these are publicly released with IOP_RESET enabled. So there is
no immediate need for this patch.
Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      9859c1aa
    • S
      [SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking · b90f90d2
      由 Salyzyn, Mark 提交于 
      Customer running an application that issues SYNCHRONIZE_CACHE calls
directly noticed the broad stroke of the current implementation in the
aacraid driver resulting in multiple applications feeding I/O to the
storage causing the issuing application to stall for long periods of
time. By only waiting for the current WRITE commands, rather than all
commands, to complete; and those that are in range of the
SYNCHRONIZE_CACHE call that would associate more tightly with the
issuing application before telling the Firmware to flush it's dirty
cache, we managed to reduce the stalling. The Firmware itself still
flushes all the dirty cache associated with the array ignoring the
range, it just does so in a more timely manner.
Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b90f90d2
    • A
      [SCSI] add easyRAID to the no report luns blacklist · 80b1c7bd
      由 akpm@linux-foundation.org 提交于 
      According to http://bugzilla.kernel.org/show_bug.cgi?id=5953, the
easyRAID returns rubbish to REPORT LUNS.

Cc: Natalie Protasevich <protasnb@gmail.com>
Cc: Hans-Christian Armingeon <mog.johnny@gmx.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      80b1c7bd
  3. 27 7月, 2007 8 次提交
  5. 26 7月, 2007 2 次提交
  7. 25 7月, 2007 3 次提交
  9. 24 7月, 2007 5 次提交
  11. 23 7月, 2007 14 次提交