Darrick J. Wong wrote:
Hrm... does this patch help? You'll get a bunch of ATA/SAS disk errors
printed to the screen if you yank the disk, but at least libsas won't
get stuck waiting for the cache-flush commands to time out.
---
sd will get hung up issuing commands to flush write cache if a SAS device
is unplugged without warning. Change libsas to reject commands to domain
devices that have already gone away.
Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
---
drivers/scsi/libsas/sas_ata.c | 4 ++++
drivers/scsi/libsas/sas_expander.c | 3 +++
drivers/scsi/libsas/sas_port.c | 2 ++
drivers/scsi/libsas/sas_scsi_host.c | 7 +++++++
include/scsi/libsas.h | 1 +
5 files changed, 17 insertions(+), 0 deletions(-)
Seems sane...
diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 0829b55..f5e5213 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -161,6 +161,10 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc)
unsigned int num = 0;
unsigned int xfer = 0;
+ /* If the device fell off, no sense in issuing commands */
+ if (dev->gone)
+ return AC_ERR_SYSTEM;
+
task = sas_alloc_task(GFP_ATOMIC);
if (!task)
return AC_ERR_SYSTEM;
As an aside, issues like this really really imply a need to move libsas
away from the old libata EH stuff (like brking did with ipr, in patches).
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
