Performance tweak, avoid unnecessary function calls.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

No need to check whether interrupt pending for MSI(X) and
conversely, no need to check whether MSI(X) interrupts are
being used when checking if interrupts are pending.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Performance enhancement. Remove spin_locks from the driver.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Empirically, this improves performance slightly (~2% max IOPS) by
allowing cmd_alloc to remember where it left off searching for
free commands between calls instead of always starting its search
at command 0.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NRobert Elliott <elliott@hp.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This means changing the allocator to reference count commands.
The reference count is now the authoritative indicator of whether a
command is allocated or not.  The h->cmd_pool_bits bitmap is now
only a heuristic hint to speed up the allocation process, it is no
longer the authoritative record of allocated commands.

Since we changed the command allocator to use reference counting
as the authoritative indicator of whether a command is allocated,
fail_all_outstanding_cmds needs to use the reference count not
h->cmd_pool_bits for this purpose.

Fix hpsa_drain_accel_commands to use the reference count as the
authoritative indicator of whether a command is allocated instead of
the h->cmd_pool_bits bitmap.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

When using the ioaccel submission methods, requests destined for RAID volumes
are sometimes diverted to physical devices.  The OS has no or limited
knowledge of these physical devices, so it is up to the driver to avoid
pushing the device too hard.  It is better to honor the physical device queue
limit rather than making the device spew zillions of TASK SET FULL responses.

This is so that hpsa based devices support /sys/block/sdNN/device/queue_type
of simple, which lets the SCSI midlayer automatically adjust the queue_depth
based on TASK SET FULL and GOOD status.

Adjust the queue depth for a new device after it is created based on the
maximum queue depths of the physical devices that constitute the
device. This drops the maximum queue depth from .can_queue of 1024 to
something like 174 for single-drive RAID-0, 348 for two-drive RAID-1, etc.
It also adjusts for the ratio of data to parity drives.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NWebb Scales <webbnh@hp.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Instead of kicking the commands all the way back to the mid
layer, use a work queue.  This enables having a mechanism for
the driver to be able to resubmit the commands down the "normal"
raid path without turning off the ioaccel feature entirely
whenever an error is encountered on the ioaccel path, and
prevent excessive rescanning of devices.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The original reasoning behind doing this was faulty.  An error
of some sort would be encountered, accelerated i/o would be
disabled for that logical drive, the command would be kicked
back out to the SCSI midlayer for a retry, and since i/o accelerator
mode was disabled, it would get retried down the RAID path.
However, something needs to turn ioaccellerator mode back on,
and this rescan request was what did that.  However, it was racy,
and extremely bad for performance to rescan all devices, so,
don't do that.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

By not doing maintaining a list of queued commands, we can eliminate some spin
locking in the main i/o path and gain significant improvement in IOPS.  Remove
the queuing code and the code that calls it; remove now-unused interrupt code;
remove DIRECT_LOOKUP_BIT.

Now that the passthru commands share the same command pool as
the main i/o path, and the total size of the pool is less than
or equal to the number of commands that will fit in the hardware
fifo, there is no need to check to see if we are exceeding the
hardware fifo's depth.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Reviewed-by: NRobert Elliott <elliott@hp.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

We have commands reserved for internal use.

This is laying the groundwork for removing the internal
queue of commands from the driver so that the locks that
protect that queue may be removed.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

We need to reserve some commands for device rescans,
aborts, and the pass through ioctls, etc. so we cannot
give them all to the scsi mid layer.

This is in preparation for removing cmd_special_alloc and
cmd_special_free so that we can stop queuing commands internally
in the driver so that we can remove the locks thta protect the
queue that we will no longer have.
Reviewed-by: NScott Teel <scott.teel@pmcs.com>
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Use atomics for commands_outstanding instead of protecting with spin locks.
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Signed-off-by: NStephen M. Cameron <stephenmcameron@gmail.com>
Reviewed-by: NJoe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Clean up issues reported when running sparse.
Signed-off-by: NDon Brace <don.brace@pmcs.com>
Reviewed-by: NWebb Scales <webb.scales@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

CTLR_STATE_CHANGE_EVENT and CTLR_STATE_CHANGE_EVENT_REDUNDANT_CNTRL
do not require rescans to be initiated.  Current firmware filters out
these events already, but some out of date firmware doesn't, so the
driver needs to filter them out too.  Without this change and with out
of date firmware you may see the driver spending a lot of time
scanning devices unnecessarily on some Smart Arrays.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NJustin Lindley <justin.lindley@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

for controllers which support either of the ioaccel transport methods.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NMike Miller <michael.miller@canonical.com>
Reviewed-by: NJoe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Avoid excessive locking by using per-cpu variable for lockup_detected
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Now that we can allocate more than 4 reply queues (up to 64)
we shouldn't try to make them share the same allocation but
should allocate them separately.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NMike Miller <michael.miller@canonical.com>
Reviewed-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

They are not completely free of cost when disabled and
when enabled emitting debug output for every command
submitted produces far too much output to be useful.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NMike Miller <michael.miller@canonical.com>
Reviewed-by: NWebb Scales <webb.scales@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

The fields "major", "max_outstanding", and "usage_count"
of struct ctlr_info were not used for anything.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Reviewed-by: NMike Miller <michael.miller@canonical.com>
Reviewed-by: NWebb Scales <webb.scales@hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

And while we're at it fix a magic number
Signed-off-by: NJoe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

This allows exposing physical disks behind Smart
Array controllers to the OS (if the controller
has the right firmware and is in "hba" mode)
Signed-off-by: NJoe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Do not expose drives that are undergoing a format immediately
to the OS, instead wait until they are ready before bringing
them online.  This is so that logical drives created with
"rapid parity initialization" do not get immediately kicked
off the system for being unresponsive.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Do no rescan on every events -- way too many rescans are
triggered if we don't filter the events.  Limit rescans
to be triggered by the following set of events:

 * controller state change
 * enclosure hot plug
 * physical drive state change
 * logical drive state change
 * redundant controller state change
 * accelerated io enabled/disabled
 * accelerated io configuration change
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Allow driver to schedule a rescan whenever a request fails on the ioaccel2 path.
This eliminates the possibility of driver getting stuck in non-ioaccel mode.

IOaccel mode (HP SSD Smart Path) is disabled by driver upon error detection.
Driver relied on idea that request would be retried through normal path, and a
subsequent error would occur on that path, and be processed by controller
firmware.  As part of that process, controller disables ioaccel mode and later
reinstates it, signalling driver to change modes.

In some error cases, the error will not duplicate on the standard path,
so the driver could get stuck in non-ioaccel mode.
To avoid that, we allow driver to request a rescan during the next run of the
rescan thread.
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Allow SSD Smart Path for a controller to be disabled by
the user, regardless of settings in controller firmware
or array configuration.

To disable:     echo 0 > /sys/class/scsi_host/host<id>/acciopath_status
To re-enable:   echo 1 > /sys/class/scsi_host/host<id>/acciopath_status
To check state: cat /sys/class/scsi_host/host<id>/acciopath_status
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NJoe Handzik <Joseph.T.Handzik@hp.com>
Signed-off-by: NMike Miller <michael.miller@canonical.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NMike Miller <michael.miller@canonical.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NMike Miller <michael.miller@canonical.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

For shared SAS configurations, hosts need to poll Smart Arrays
periodically in order to be able to detect configuration changes
such as logical drives being added or removed from remote hosts.
A register on the controller indicates when such events have
occurred, and the driver polls the register via a workqueue
and kicks off a rescan of devices if such an event is detected.
Additionally, changes to logical drive raid offload eligibility
are autodetected in this way.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This enables sending i/o's destined for RAID logical drives
which can be serviced by a single physical disk down a different,
faster i/o path directly to physical drives for certain logical
volumes on SSDs bypassing the Smart Array RAID stack for a
performance improvement.
Signed-off-by: NMatt Gates <matthew.gates@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NMike Miller <michael.miller@canonical.com>
Signed-off-by: NDon Brace <brace@beardog.cce.hp.com>
Signed-off-by: NJoe Handzik <joseph.t.handzik@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

For certain i/o's to certain devices (unmasked physical disks) we
can bypass the RAID stack firmware and do the i/o to the device
directly and it will be faster.
Signed-off-by: NMatt Gates <matthew.gates@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Much simpler and avoids races starting/stopping the thread.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

If a fifo full condition is encountered, i/o requests will stack
up in the h->reqQ queue.  The only thing which empties this queue
is start_io, which only gets called when new i/o requests come in.
If none are forthcoming, i/o in h->reqQ will be stalled.

To fix this, whenever fifo full condition is encountered, this
is recorded, and the interrupt handler examines this to see
if a fifo full condition was recently encountered when a
command completes and will call start_io to prevent i/o's in
h->reqQ from getting stuck.

I've only ever seen this problem occur when running specialized
test programs that pound on the the CCISS_PASSTHRU ioctl.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Cap CCISS_BIG_PASSTHRU as well.  If an attempt is made
to exceed this, ioctl() will return -1 with errno == EAGAIN.

This is to prevent a userland program from exhausting all of
pci_alloc_consistent memory.  I've only seen this problem when
running a special test program designed to provoke it.  20
concurrent commands via the passthru ioctls (not counting SG_IO)
should be more than enough.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NTomas Henzl <thenzl@redhat.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Dial back the aggressiveness of the controller lockup detection thread.
Currently it will declare the controller to be locked up if it goes
for 10 seconds with no interrupts and no change in the heartbeat
register.  Dial back this to 30 seconds with no heartbeat change, and
also snoop the ioctl path and if a firmware flash command is detected,
dial it back further to 4 minutes until the firmware flash command
completes.  The reason for this is that during the firmware flash
operation, the controller apparently doesn't update the heartbeat
register as frequently as it is supposed to, and we can get a false
positive.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>