linux-toradex.git/drivers/scsi/hpsa.c, branch v3.4.45

SCSI: hpsa: dial down lockup detection during firmware flash

2012-10-21T16:27:58+00:00

commit e85c59746957fd6e3595d02cf614370056b5816e upstream.

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: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: hpsa: Use LUN reset instead of target reset

2012-10-07T15:32:28+00:00

commit 21e89afd325849eb38adccf382df16cc895911f9 upstream.

It turns out Smart Array logical drives do not support target
reset and when the target reset fails, the logical drive will
be taken off line.  Symptoms look like this:

hpsa 0000:03:00.0: Abort request on C1:B0:T0:L0
hpsa 0000:03:00.0: resetting device 1:0:0:0
hpsa 0000:03:00.0: cp ffff880037c56000 is reported invalid (probably means target device no longer present)
hpsa 0000:03:00.0: resetting device failed.
sd 1:0:0:0: Device offlined - not ready after error recovery
sd 1:0:0:0: rejecting I/O to offline device
EXT3-fs error (device sdb1): read_block_bitmap:

LUN reset is supported though, and is what we should be using.
Target reset is also disruptive in shared SAS situations,
for example, an external MSA1210m which does support target
reset attached to Smart Arrays in multiple hosts -- a target
reset from one host is disruptive to other hosts as all LUNs
on the target will be reset and will abort all outstanding i/os
back to all the attached hosts.  So we should use LUN reset,
not target reset.

Tested this with Smart Array logical drives and with tape drives.
Not sure how this bug survived since 2009, except it must be very
rare for a Smart Array to require more than 30s to complete a request.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: hpsa: fix handling of protocol error

2012-10-02T17:30:08+00:00

commit 256d0eaac87da1e993190846064f339f4c7a63f5 upstream.

If a command status of CMD_PROTOCOL_ERR is received, this
information should be conveyed to the SCSI mid layer, not
dropped on the floor.  CMD_PROTOCOL_ERR may be received
from the Smart Array for any commands destined for an external
RAID controller such as a P2000, or commands destined for tape
drives or CD/DVD-ROM drives, if for instance a cable is
disconnected.  This mostly affects multipath configurations, as
disconnecting a cable on a non-multipath configuration is not
going to do anything good regardless of whether CMD_PROTOCOL_ERR
is handled correctly or not.  Not handling CMD_PROTOCOL_ERR
correctly in a multipath configaration involving external RAID
controllers may cause data corruption, so this is quite a serious
bug.  This bug should not normally cause a problem for direct
attached disk storage.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

[SCSI] hpsa: add some older controllers to the kdump blacklist

2012-02-19T15:40:51+00:00

Some other older controllers also do have problems to perform a kdump.
Adding controllers to this list means that the driver will signal
this non-ability via a resettable flag correctly.
The unsupported list was created after a consultation with HP.

Signed-off-by: Tomas Henzl 
Acked-by: Mike Miller 
Signed-off-by: James Bottomley

[SCSI] hpsa: use find_first_zero_bit

2012-02-19T14:08:57+00:00

Use find_first_zero_bit to find the first cleared bit in a memory region.

This also includes the following minor changes.
- Use bitmap_zero
- Reduce unnecessary atomic bitops usage

Signed-off-by: Akinobu Mita 
Acked-by: Stephen M. Cameron 
Signed-off-by: James Bottomley

[SCSI] hpsa: update device attributes when they change

2012-02-19T14:08:57+00:00

Certain types of changes to devices should not be interpreted as a device
change that would cause the device to be removed and re-added.  These include
RAID level and Firmware revision changes.  However, these attribute changes DO
need to be reflected in the controller info structure's dev structure list, so
that sysfs and /proc info files for the devices will reflect the new values.

Signed-off-by: Scott Teel 
Acked-by: Stephen M. Cameron 
Signed-off-by: James Bottomley

[SCSI] hpsa: improve naming on external target device functions

2012-02-19T14:08:56+00:00

Reduce confusion and inaccuracy caused by dated naming of vars and functions
referring to external target devices.

CURRENT NAMING:                PROPOSED NAMING:

"MSA2xxx devices"              "external target devices"
msa2xxx_model                  ext_target_model
is_msa2xxx                     is_ext_target
add_msa2xxx_enclosure          add_ext_target_dev
nmsa2xxx_enclosures            n_ext_target_devs

Signed-off-by: Scott Teel 
Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley

[SCSI] hpsa: eliminate 8 external target limitation

2012-02-19T14:08:56+00:00

Driver limits SAS external target IDs to range 1-8.
Need to increase limit and clean up overlapping concepts of targets and paths
in the code.

There are several defined constants that control this:
HPSA_MAX_TARGETS_PER_CTLR     16
MAX_MSA2XXX_ENCLOSURES        32
HPSA_MAX_PATHS                8

We can condense this to one constant:
MAX_EXT_TARGETS               32

SAS switches allow for 8 connections, and there is capacity for 4 switches per
enclosure in largest blade enclosure type.

Signed-off-by: Scott Teel 
Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley

[SCSI] hpsa: refactor hpsa_figure_bus_target_lun

2012-02-19T14:08:56+00:00

It should call hpsa_set_bus_target_lun rather
than individually setting bus, target and lun.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley

[SCSI] hpsa: make target and lun match what SCSI REPORT LUNs returns

2012-02-19T14:08:56+00:00

Some distros have a "rescan-scsi-bus.sh" script which depends on
SCSI REPORT LUNs not reporting something different than what the
driver tells the kernel, even if the driver uses scan_start and
scan_finished methods of the SCSI host template to override the
usual SCSI midlayer discovery code.  Previously, 1 was added to
the LUN to make room to insert the RAID controller device at
LUN 0.  Now, the RAID controller is moved to bus 3, and 1 is no
longer added to the LUN.  However, SCSI REPORT LUNS on Smart Array
doesn't report physical devices like tape drives or auto-loaders
as it turns out, so those particular device types still won't match.
Generally the logical drives are reported first however, so at
least those should match.

Signed-off-by: Stephen M. Cameron 
Signed-off-by: James Bottomley