24 Mar, 2011

1 commit

  • Added new hardware device 0x28b interface for PMC-Sierra's SRC based
    controller family.

    - new src.c file for 0x28b specific functions
    - new XPORT header required
    - sync. command interface: doorbell bits shifted (SRC_ODR_SHIFT, SRC_IDR_SHIFT)
    - async. Interface: different inbound queue handling, no outbound I2O
    queue available, using doorbell ("PmDoorBellResponseSent") and
    response buffer on the host ("host_rrq") for status
    - changed AIF (adapter initiated FIBs) interface: "DoorBellAifPending"
    bit to inform about pending AIF, "AifRequest" command to read AIF,
    "NoMoreAifDataAvailable" to mark the end of the AIFs

    Signed-off-by: Mahesh Rajashekhara
    Signed-off-by: James Bottomley

    Mahesh Rajashekhara
     

02 Nov, 2010

1 commit

  • "gadget", "through", "command", "maintain", "maintain", "controller", "address",
    "between", "initiali[zs]e", "instead", "function", "select", "already",
    "equal", "access", "management", "hierarchy", "registration", "interest",
    "relative", "memory", "offset", "already",

    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Jiri Kosina

    Uwe Kleine-König
     

17 Sep, 2010

1 commit


17 May, 2010

2 commits

  • Problem description:
    --------------------

    The problem reported by one of the customer was when a logical array
    is deleted(from the SDK, from the GUI, from arcconf) then the
    corresponding physical device (/dev/sdb, for example) is not removed
    from the Linux namespace. So you end up with a "dead" device
    entry. And some of the linux tools go slightly wonky.

    Solution:
    ---------

    Based on the notification from FW, the driver calls
    "scsi_remove_device" for the DELETED drive. This call not only informs
    the scsi device status to the SCSI mid layer and also it will remove
    corresponding scsi device entries from the Linux sysfs.

    Signed-off-by: Mahesh Rajashekhara
    Signed-off-by: James Bottomley

    Rajashekhara, Mahesh
     
  • Problem description:
    --------------------

    When the JBOD is created from the OS using Adaptec Storage Manager
    utility device is not available under FDISK until a system restart is
    done.

    Solution:
    ---------

    AIF handling: If there is a JBOD drive added to the system, identify
    the old one with scsi_device_lookup() and remove it to enable a fresh
    scsi_add_device(); else the new JBOD is not available until reboot.

    Signed-off-by: Mahesh Rajashekhara
    Signed-off-by: James Bottomley

    Rajashekhara, Mahesh
     

18 Jan, 2010

1 commit

  • These particular problems were reported by Cisco and SAP and customers
    as well. Cisco reported on RHEL4 U6 and SAP reported on SLES9 SP4 and
    SLES10 SP2. We added these fixes on RHEL4 U6 and gave a private build
    to IBM and Cisco. Cisco and IBM tested it for more than 15 days and
    they reported that they did not see the issue so far. Before the fix,
    Cisco used to see the issue within 5 days. We generated a patch for
    SLES9 SP4 and SLES10 SP2 and submitted to Novell. Novell applied the
    patch and gave a test build to SAP. SAP tested and reported that the
    build is working properly.

    We also tested in our lab using the tools "dishogsync", which is IO
    stress tool and the tool was provided by Cisco.

    Issue1: File System going into read-only mode

    Root cause: The driver tends to not free the memory (FIB) when the
    management request exits prematurely. The accumulation of such
    un-freed memory causes the driver to fail to allocate anymore memory
    (FIB) and hence return 0x70000 value to the upper layer, which puts
    the file system into read only mode.

    Fix details: The fix makes sure to free the memory (FIB) even if the
    request exits prematurely hence ensuring the driver wouldn't run out
    of memory (FIBs).

    Issue2: False Raid Alert occurs

    When the Physical Drives and Logical drives are reported as deleted or
    added, even though there is no change done on the system

    Root cause: Driver IOCTLs is signaled with EINTR while waiting on
    response from the lower layers. Returning "EINTR" will never initiate
    internal retry.

    Fix details: The issue was fixed by replacing "EINTR" with
    "ERESTARTSYS" for mid-layer retries.

    Signed-off-by: Penchala Narasimha Reddy
    Signed-off-by: James Bottomley

    Penchala Narasimha Reddy Chilakala, ERS-HCLTech
     

07 Apr, 2009

2 commits


30 Dec, 2008

1 commit


03 May, 2008

1 commit

  • As JBOD devices (really just Simple Single Drive Volumes exported to
    the SCSI channel) are managed, they fail to update correctly when the
    driver triggers a SCSI scan. In addition, the ability to change
    multiple arrays or JBODs at the same time was resulting in dropped
    scans, set up a mechanism to issue a list of single target scans on a
    single configuration change notification from the Firmware.

    Performed some additional sundry cosmetic code style cleanups.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Mark Salyzyn
     

02 May, 2008

1 commit

  • On Apr 21, 2008, at 8:42 PM, Yinghai Lu wrote:
    > bisected to:
    >
    > commit e6990c6448ca9359b6d4ad027c0a6efbf4379e64
    > Author: Mark Salyzyn
    > Date: Mon Apr 14 14:20:16 2008 -0400
    >
    > [SCSI] aacraid: Fix down_interruptible() to check the return value

    The return value for down_interruptible was incorrectly checked!
    updated patch enclosed.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Mark Salyzyn
     

19 Apr, 2008

1 commit


16 Apr, 2008

1 commit


08 Apr, 2008

1 commit

  • replace all:
    little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
    expression_in_cpu_byteorder);
    with:
    leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder);
    generated with semantic patch

    Signed-off-by: Marcin Slusarz
    Acked-by: "Salyzyn, Mark"
    Signed-off-by: Andrew Morton
    Signed-off-by: James Bottomley

    Marcin Slusarz
     

12 Feb, 2008

1 commit


24 Jan, 2008

6 commits

  • The cards being added are supported in a limited sense already through
    family matching, but we needed to add some functionality to the driver
    to expose selectively the physical drives. These Physical drives are
    specifically marked to not be part of any array and thus are declared
    JBODs (Just a Bunch Of Drives) for generic SCSI access.

    We report that this is the second patch in a set of two, but merely
    depends on the stand-alone functionality of the first patch which adds
    in that case the ability to report a driver feature flag via sysfs. We
    leverage that functionality by reporting that this driver now supports
    this new JBOD feature for the controller so that the array management
    applications may react accordingly and guide the user as they manage
    the controller.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • I was amazed at how much embedded space was present in the aacraid
    driver source files. Just selected five files from the set to clean up
    for now and the attached patch swelled to 73K in size!

    - Removed trailing space or tabs
    - Removed spaces embedded within tabs
    - Replaced leading 8 spaces with tabs
    - Removed spaces before )
    - Removed ClusterCommand as it was unused (noticed it as one triggered by above)
    - Replaced scsi_status comparison with 0x02, to compare against SAM_STATUS_CHECK_CONDITION.
    - Replaced a long series of spaces with tabs
    - Replaced some simple if...defined() with ifdef/ifndef

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • Added support to respond to enclosure service events
    (controller AIFs) to add, online or offline physical targets
    reported to sg. Also added online and offlining of arrays.
    Removed an automatic variable definition in a sub block that
    hid an earlier definition, determined to be inert as the
    sub-block use did not interfere. Bumped the driver versioning
    to stamp the addition of this feature.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • In experiments in the lab we managed to trigger an Adapter firmware
    panic (BlinkLED) coincidentally while several pass-through ioctl
    command from the management software were outstanding on a bug only
    present on a class of RAID Adapters that require a hardware reset
    rather than a commanded reset. The net result was an attempt to time
    out the management software command as if it came from the SCSI layer
    resulting in an OS panic.

    Adapters that use commanded reset, management commands are returned
    failed by the Adapter correctly. The adapter firmware panic that
    resulted in this condition was also resolved, and there were no
    adapters in the field with this specific firmware bug so we do not
    expect any field reports. This is a rare or unlikely corner condition,
    and no reports have ever been forwarded from the field.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • Big endian systems issues discovered in the aacraid driver. Somewhat
    reverses a patch from November 7th of last year that removed swap
    operations because they formerly were being assigned to an u8 array
    when they should have been assigned to an le32 array.

    This patch is largely inert for any little endian processor
    architecture. It resolves a bug in delivering the BlinkLED AIF event
    to registered applications when the adapter or associated hardware was
    reset due to ill health. A rare corner case occurrence, also largely
    unnoticed by any as it was a new (untested!) feature.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • aacraid.cache parameter, Disable Queue Flush commands:
    bit 0 - Disable FUA in WRITE SCSI commands
    bit 1 - Disable SYNCHRONIZE_CACHE SCSI command
    bit 2 - Disable only if Battery not protecting adapter supplied Cache

    e.g.: aacraid.cache=7 will disable the FUA and SYNCHRONIZE_CACHE
    commands if the adapter has reported that it's cache is battery backed
    up.

    This parameter permits experimentation with tradeoffs between
    performance and caching policy.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     

12 Jan, 2008

3 commits

  • As reported in http://bugzilla.kernel.org/show_bug.cgi?id=3D9133 it was
    discovered that the PERC line of controllers lacked a key 64 bit
    ScatterGather capable SCSI pass-through function. The adapters are still
    capable of 64 bit ScatterGather I/O commands, but these two can not be
    mixed. This problem was exacerbated by the introduction of the SCSI
    Generic access to the DASD physical devices.

    The fix for users before this patch is applied is aacraid.dacmode=3D0 on
    the kernel command line to disable 64 bit I/O.

    The enclosed patch introduces a new adapter quirk and tries to limp
    along by enabling pass-through in situations where memory is 32 bit
    addressable on 64 bit machines, or disable the pass-through functions
    altogether. I expect that the check for 32 bit addressable memory to be
    controversial in that it can be incorrect in non-Dell non-Intel systems
    that PERC would never be installed under, the alternative is to disable
    pass-through in all cases which could be reported as another regression.

    Pass-through is used for SCSI Generic access to the physical devices, or
    for the management applications to properly function.

    In systems where this patch has disabled pass-through because it is
    unsupportable in combination with I/O performance, the user can choose
    to enable pass-through by turning off dacmode (aacraid.dacmode=3D0) or
    limiting the discovered kernel memory (mem=3D4G) with an associated loss
    in runtime performance. If we chose instead to turn off 64 bit dacmode
    for the adapters with this quirk, then this would be reported as another
    regression.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: Andrew Morton
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     
  • On Wed, Nov 07, 2007 at 01:51:44PM -0500, Salyzyn, Mark wrote:
    > Christoph Hellwig [mailto:hch@infradead.org] sez:
    > > Did anyone run the driver through sparse to see if we have
    > > more issues like this?
    >
    > There are some warnings from sparse, none like this one. I will deal
    > with the warnings ...

    Actually there are a lot of endianess warnings, fortunately most of them
    harmless. The patch below fixes all of them up (including the ones in
    the patch I replied to), except for aac_init_adapter which is really odd
    and I don't know what to do.

    [jejb fixed up rejections and checkpatch issues]

    Signed-off-by: Christoph Hellwig
    Acked-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Christoph Hellwig
     
  • Some of our vendors have requested that our adapters ignore the hardware
    reset attempts during recovery and have enforced this with changes in
    Adapter Firmware. Some of our customers have requested the option to be
    able to reset the adapter under adverse adapter failure, we even had a
    few defects reported here considering it a regression that the Adapter
    could not be reset. This patch addresses this dichotomy. The user can
    force the adapter to be reset if it supports the IOP_RESET_ALWAYS
    command, in cases where the adapter has been programmed to ignore the
    reset, by setting the aacraid.check_reset parameter to a value of -1.

    The driver will not reset an Adapter that does not support the reset
    command(s).

    This patch also fixes and cleans up some of the logic associated with
    resetting the adapter.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     

08 Nov, 2007

2 commits


13 Oct, 2007

1 commit


19 Jul, 2007

1 commit


18 Jun, 2007

1 commit

  • Add the ability for an application to issue a hardware reset to the
    adapter via sysfs. Typical uses include restarting the adapter after it
    has been flashed. Bumped revision number for the driver and added a
    feature to periodically check the adapter's health (check_interval),
    update the adapter's concept of time (update_interval) and block
    checking/resetting of the adapter (check_reset).

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     

06 May, 2007

1 commit


01 Apr, 2007

1 commit

  • Add some likely() and unlikely() compiler hints in some of the aacraid
    hardware interface layers. There should be no operational side effects
    resulting from this patch and the changes should be mostly benign on x86
    platforms.

    Signed-off-by: Mark Salyzyn
    Signed-off-by: James Bottomley

    Salyzyn, Mark
     

20 Mar, 2007

4 commits

  • Received from Mark Salyzyn,

    This set of fixes improve error handling stability of the driver. A popular
    manifestation of the problems is an NULL pointer reference in the interrupt
    handler when referencing portions of the scsi command context, or in the
    scsi_done handling when an offlined device is referenced.

    The aacraid driver currently does not get notification of orphaned command
    completions due to devices going offline. The driver also fails to handle the
    commands that are finished by the error handler, and thus can complete again
    later at the hands of the adapter causing situations of completion of an
    invalid scsi command context. Test Unit Ready calls abort assuming that the
    abort was successful, but are not, and thus when the interrupt from the adapter
    occurs, they reference invalid command contexts. We add in a TIMED_OUT flag to
    inform the aacraid FIB context that the interrupt service should merely release
    the driver resources and not complete the command up. We take advantage of this
    with the abort handler as well for select abortable commands. And we detect and
    react if a command that can not be aborted is currently still outstanding to
    the controller when reissued by the retry mechanism.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     
  • Received from Mark Salyzyn,

    Outstanding ioctl calls still have some problems with aborting cleanly
    in the face of a reset iop recovery action should the adapter ever enter
    into a Firmware Assert (BlinkLED) condition. The enclosed patch resolves
    some uncovered flawed handling.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     
  • Received from Mark Salyzyn,

    This patch is to resolve a namespace issue that will result from a patch
    expected in the future that adds a new interface; rationalized as
    correcting a long term issue where hw_fib, instead of hw_fib_va, refers
    to the virtual address space and hw_fib_pa refers to the physical
    address space. A small fragment of this patch also cleans up an unused
    variable that was close to the patch fragments.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     
  • Received from Mark Salyzyn,

    This patch updates the adapter restart function to deal with some
    adapters that have specific IOP reset needs. Since the code for
    restarting the adapter was in two places, changed over to utilizing a
    platform function in one place.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     

27 Jan, 2007

1 commit

  • Received from Mark Salyzyn,

    Replace all if/else communication transports with a platform function call.
    This is in recognition of the need to migrate to up-and-coming transports.
    Currently the Linux driver does not support two available communication
    transports provided by our products, these will be added in future patches, and
    will expand the platform function set.

    Signed-off-by Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     

23 Nov, 2006

2 commits

  • Received from Mark Salyzyn:

    Add code to abort outstanding management ioctl fibs when the blinkLED recovery
    is performed. This code is 'clunky' and does not have any real feedback in that
    the reset could progress before the user application has gotten it's
    notification of command completion. We put a schedule() call to delay just the
    right amount for most cases, because we tried a spin and still managed to find
    cases where we would spin forever waiting for the management application to
    acknowledge the impending doom surrounding the cause of the BlinkLED. Will
    cause an oops in the context of the management application if we proceed too
    quickly. I view this as the lesser of many evils since currently if there are
    outstanding management ioctls during a need to reset/recover the adapter, the
    management application just locks up and waits forever. The best practices fix
    for this problem not going to be simple or easy (at least the fixes I imagine
    today); and we found a balance between the needs of the driver to proceed, and
    the applications that locked or confused that would hold back the driver. I
    just do not like the idea of a kernel oops in an application to deal with low
    priority, sluggish or misbehaving applications.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     
  • Received from Mark Salyzyn:

    Blinkled at startup is useful for catching Adapters in a lot of pain, in a
    BlinkLED assert, quickly; rather than waiting several minutes for commands to
    timeout.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp
     

25 Sep, 2006

1 commit


24 Sep, 2006

1 commit

  • Received from Mark Salyzyn:

    Until the system is stabilized, I am suggesting the enclosed
    modification to prevent the driver from tickling the panic. Once sysfs
    and friends are stabilized, the patch may be backed out. We have yet to
    evaluate if we really want to relinquish existing Scsi Devices in any
    case, holding on to them as configuration of arrays comes and goes makes
    some sense as well. As a result, we have opted to pull the lines rather
    than comment them in legacy.

    Signed-off-by: Mark Haverkamp
    Signed-off-by: James Bottomley

    Mark Haverkamp