]> www.infradead.org Git - users/jedix/linux-maple.git/commit
SCSI: hpsa: Use LUN reset instead of target reset
authorStephen M. Cameron <scameron@beardog.cce.hp.com>
Thu, 26 Jul 2012 16:34:10 +0000 (11:34 -0500)
committerMaxim Uvarov <maxim.uvarov@oracle.com>
Mon, 8 Oct 2012 14:47:29 +0000 (07:47 -0700)
commit8c81e8539b869d4d22e4059704b95fd1af5d74c1
treec795becb032fcc3674a58c1e1b290d2a5f86c921
parentb3aa44d1ddc65a2e7e818cf6ced8dc03ad56e6a4
SCSI: hpsa: Use LUN reset instead of target reset

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 <scameron@beardog.cce.hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/scsi/hpsa.c