* Do not check event bits on locked up controllers to
  see if they need to be rescanned.
* Do not initiate any device rescans on controllers
  which are known to be locked up.
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>

When rescanning for logical drives, store information about whather
raid offload is enabled for each logical drive, and update the driver's
internal record of this.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.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 "mode 1" io accelerated commands, the command tag is in
a different location than for commands that go down the normal
RAID path, so the abort handler needs to take this into account.
Signed-off-by: NScott Teel <scott.teel@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>

When commands sent down the "fast path" fail, they must be re-tried down the
normal RAID path.  We do this by kicking i/o's back to the scsi mid layer with
a DID_SOFT_ERROR status, which causes them to be retried.  This won't work for
SG_IO's and other non REQ_TYPE_FS i/o's which could get kicked all the way back
to the application, which may have no idea that the command needs resubmitting
and likely no way to resubmit it in such a way the that driver can recognize it
as a resubmit and send it down the normal RAID path.  So we just always send
non REQ_TYPE_FS i/o's down the normal RAID path, never down the "fast path".
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.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>

This is normally optional, but for SSD Smart Path support (in
subsequent patches) it is required.
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>

There is an extended report luns command which contains
additional information about physical devices.  In particular
we need to get the physical device handle so we can use an
alternate i/o path for fast physical devices like SSDs so
we can speed up certain i/o's by bypassing the RAID stack
code in the controller firmware.
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>

Commit 254f796b updated
the driver to use 16 MSI-X vectors, despite the fact that
older controllers would provide only 4.
This was causing MSI-X registration to drop down to INTx
mode. But as the controller support performant mode, the
initialisation will become confused and cause the machine
to stall during boot.

This patch fixes up the MSI-X registration to re-issue
the pci_enable_msix() call with the correct number of
MSI-X vectors. With that the hpsa driver continues to
works on older controllers like the P200.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

We were clobbering the SCSI status and setting
cmd->result = DID_SOFT_ERROR << 16; to get a retry,
but better to let the mid layer handle the unit
attention.
Signed-off-by: NMatt Gates <matthew.gates@hp.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Immediately following a hard board reset, There are some
mandatory delays during which we must not access the board
and during which we might miss the "not ready" status,
therefore it is a mistake to look for and expect to see
the "not ready" status.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This used to be the default, but at some point the firmware guys
changed the default and I failed to notice.  Now to get unit
attention notifications, you must twiddle a bit indicating you
want them.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The field contains more bits than just the one
to indicate whether scsi prefetch should be turned on.
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>

Remove PCI ID for the never shipped P822se.
Signed-off-by: NMike Miller <mike.miller@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: NScott Teel <scott.teel@hp.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

We were leaking a command buffer if a DMA mapping error was
encountered in the CCISS_BIG_PASSTHRU ioctl.
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>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The hardware guys tell us that after initiating a software
reset via the doorbell register we need to wait 5 seconds before
attempting to talk to the board *at all*.  This means that we
cannot watch the board to verify it transitions from "ready" to
to "not ready" then back "ready", since this transition will
most likely happen during those 5 seconds (though we can still
verify the reset happens by watching the "driver version" field
get cleared.)
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There's no point in trying since it can't work, and if you do
try, it will just hang the system on shutdown.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

A return value of 1 is interpreted as an error.  See pci_driver.
in local_pci_probe().  If you're wondering how this ever could
have worked, it's because it used to be the case that only return
values less than zero were interpreted as failure.  But even in
the current kernel if the driver registers its various entry
points with the kernel, and then returns a value which is
interpreted as failure, those registrations aren't undone, so
the driver still mostly works.  However, the driver's remove
function wouldn't be called on rmmod, and pci power management
functions wouldn't work.  In the case of Smart Array, since it
has a battery backed cache (or else no cache) even if the driver
is not shut down properly as long as there is no outstanding
i/o, nothing too bad happens, which is why it took so long to
notice.

Requesting backport to stable because the change to pci-driver.c
which requires driver probe functions to return 0 occurred between
2.6.35 and 2.6.36 (the pci power management breakage) and again
between 3.7 and 3.8 (pci_dev->driver getting set to NULL in
local_pci_probe() preventing driver remove function from being
called on rmmod.)
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

We inadvertantly discarded the scsi status for aborted commands.
For some commands (e.g. reads from tape drives) these can't be retried,
and if we discarded the scsi status, the scsi mid layer couldn't notice
anything was wrong and the error was not reported.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Some host adapters do not pass commands through to the target disk
directly. Instead they provide an emulated target which may or may not
accurately report its capabilities. In some cases the physical device
characteristics are reported even when the host adapter is processing
commands on the device's behalf. This can lead to adapter firmware hangs
or excessive I/O errors.

This patch disables WRITE SAME for devices connected to host adapters
that provide an emulated target. Driver writers can disable WRITE SAME
by setting the no_write_same flag in the host adapter template.

[jejb: fix up rejections due to eh_deadline patch]
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch removes the PCI ID of a cancelled Smart Array.
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Since commit 0998d063
(device-core: Ensure drvdata = NULL when no driver is bound),
the driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Changes the version of hpsa so we know something has changed. Please consider
this for inclusion.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch does a bit of housekeeping for hpsa. Change lowercase alpha hex
digits to uppercase for consistency within the driver. Also moves the P822se
in the tables to keep controllers of each family grouped together.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add the marketing names for HP Smart Array Gen8 controllers. Also removes an
unused ID. Please consider this for inclusion.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch adds the PCI ID's for HP Smart Array Gen9 controllers. Please
consider this patch for inclusion.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Tyops should be fixed.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

 section Signed-off-by: John Kacur <jkacur@redhat.com>

On a 3.6-rt (real-time patch) kernel we are seeing the following BUG
However, it appears to be relevant for non-realtime (mainline) as well.

[   49.688847] hpsa 0000:03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
[   49.749928] scsi0 : hpsa
[   49.784437] BUG: using smp_processor_id() in preemptible [00000000
00000000] code: kworker/u:0/6
[   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
[   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
3.6.11.5-rt37.52.el6rt.x86_64.debug #1
[   49.784471] Call Trace:
[   49.784512]  [<ffffffff812abe83>] debug_smp_processor_id+0x123/0x150
[   49.784520]  [<ffffffffa009043a>] enqueue_cmd_and_start_io+0x5a/0x100
[hpsa]
[   49.784529]  [<ffffffffa00905cb>]
hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
[   49.784537]  [<ffffffff812b09c8>] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784544]  [<ffffffff812b09c8>] ? swiotlb_dma_mapping_error+0x18/0x30
[   49.784553]  [<ffffffffa0090701>]
hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
[   49.784562]  [<ffffffffa0093558>]
hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
[   49.784571]  [<ffffffffa00935ea>]
hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
[   49.784580]  [<ffffffffa00963df>] hpsa_update_scsi_devices+0x11f/0x4f0
[hpsa]
[   49.784592]  [<ffffffff81592019>] ? sub_preempt_count+0xa9/0xe0
[   49.784601]  [<ffffffffa00968ad>] hpsa_scan_start+0xfd/0x150 [hpsa]
[   49.784613]  [<ffffffff8158cba8>] ? rt_spin_lock_slowunlock+0x78/0x90
[   49.784626]  [<ffffffff813b04d7>] do_scsi_scan_host+0x37/0xa0
[   49.784632]  [<ffffffff813b05da>] do_scan_async+0x1a/0x30
[   49.784643]  [<ffffffff8107c4ab>] async_run_entry_fn+0x9b/0x1d0
[   49.784655]  [<ffffffff8106ae92>] process_one_work+0x1f2/0x620
[   49.784661]  [<ffffffff8106ae20>] ? process_one_work+0x180/0x620
[   49.784668]  [<ffffffff8106d4fe>] ? worker_thread+0x5e/0x3a0
[   49.784674]  [<ffffffff8107c410>] ? async_schedule+0x20/0x20
[   49.784681]  [<ffffffff8106d5d3>] worker_thread+0x133/0x3a0
[   49.784688]  [<ffffffff8106d4a0>] ? manage_workers+0x190/0x190
[   49.784696]  [<ffffffff81073236>] kthread+0xa6/0xb0
[   49.784707]  [<ffffffff815970a4>] kernel_thread_helper+0x4/0x10
[   49.784715]  [<ffffffff81082a7c>] ? finish_task_switch+0x8c/0x110
[   49.784721]  [<ffffffff8158e44b>] ? _raw_spin_unlock_irq+0x3b/0x70
[   49.784727]  [<ffffffff8158e85d>] ? retint_restore_args+0xe/0xe
[   49.784734]  [<ffffffff81073190>] ? kthreadd+0x1e0/0x1e0
[   49.784739]  [<ffffffff815970a0>] ? gs_change+0xb/0xb

-------------------

This is caused by
enqueue_cmd_and_start_io()->
        set_performant_mode()->
                smp_processor_id()
Which if you have debugging enabled calls debug_processor_id() and triggers the warning.

The code here is
 c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;

Since it is not critical that the code complete on the same processor,
but the cpu is a hint used in generating the ReplyQueue and will still work if
the cpu migrates or is preempted, it is safe to use the raw_smp_processor_id()
to surpress the false positve warning.
Signed-off-by: NJohn Kacur <jkacur@redhat.com>
Acked-by: NStephen 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>

When the driver calls scsi_done and after that frees it's internal
preallocated memory it can happen that a new job is enqueud before
the memory is freed. The allocation fails and the message
"cmd_alloc returned NULL" is shown.
Patch below fixes it by moving cmd->scsi_done after cmd_free.
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>

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: NJames Bottomley <JBottomley@Parallels.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: NJames Bottomley <JBottomley@Parallels.com>