kernel.git/drivers/scsi/hpsa.c, branch linux-3.6.y

SCSI: hpsa: Use LUN reset instead of target reset

2012-10-07T15:39:35Z

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-09-18T11:29:30Z

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 Cc: stable@vger.kernel.org Signed-off-by: James Bottomley

[SCSI] hpsa: dial down lockup detection during firmware flash

2012-05-10T08:19:39Z

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

[SCSI] hpsa: add new RAID level "1(ADM)"

2012-05-10T08:18:24Z

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

[SCSI] hpsa: factor out hpsa_free_irqs_and_disable_msix

2012-05-10T08:17:51Z

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

[SCSI] hpsa: refine interrupt handler locking for greater concurrency

2012-05-10T08:17:26Z

Use spinlocks with finer granularity in the submission and completion paths to allow concurrent execution for multiple reply queues. In particular, do not hold a spin lock while submitting a request to the device, nor during most of the interrupt handler. Signed-off-by: Matt Gates Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: use multiple reply queues

2012-05-10T08:16:25Z

Smart Arrays can support multiple reply queues onto which command completions may be deposited. It can help performance quite a bit to arrange for command completions to be processed on the same CPU from which they were submitted to increase the likelihood of cache hits. Signed-off-by: Matt Gates Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: factor out tail calls to next_command() in process_(non)indexed_cmd()

2012-05-10T08:15:46Z

This is in order to smooth the way for upcoming changes to allow use of multiple reply queues for command completions. Signed-off-by: Stephen M. Cameron Signed-off-by: Matt Gates Signed-off-by: James Bottomley

[SCSI] hpsa: do aborts two ways

2012-05-10T08:15:16Z

When aborting a command, the tag is supposed to be specified as 64-bit little endian. However, some smart arrays expect the tag of the command to be aborted to be specified in a strange byte order. How to tell which sort of Smart Array firmware we're dealing with is not obvious. However, because of the way we construct our tags, the values of any outstanding tag when specified with the "strange" byte order will not collide with the value specified in the correct order. That means we can safely attempt the abort both ways. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley

[SCSI] hpsa: add abort error handler function

2012-05-10T08:14:29Z

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