[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170117092025.GA9337@gmail.com>
Date: Tue, 17 Jan 2017 10:20:25 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
David Miller <davem@...emloft.net>,
Bart Van Assche <Bart.VanAssche@...disk.com>,
Christoph Hellwig <hch@...radead.org>, jbaron@...mai.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
sagi@...mberg.me, Sathya Prakash <sathya.prakash@...adcom.com>,
Suganath Prabu Subramani
<suganath-prabu.subramani@...adcom.com>,
Hannes Reinecke <hare@...e.de>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
Chaitra Basappa <chaitra.basappa@...adcom.com>,
dledford@...hat.com, Sreekanth Reddy <sreekanth.reddy@...adcom.com>
Subject: Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
* Martin K. Petersen <martin.petersen@...cle.com> wrote:
> >>>>> "James" == James Bottomley <James.Bottomley@...senPartnership.com> writes:
>
> James> Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough
> James> commands
>
> James> mpt3sas has a firmware failure where it can only handle one pass
> James> through ATA command at a time. If another comes in, contrary to
> James> the SAT standard, it will hang until the first one completes
> James> (causing long commands like secure erase to timeout). The
> James> original fix was to block the device when an ATA command came in,
> James> but this caused a regression with
>
> Broadcom folks: Please test and ack as soon as possible so we can get
> this fix queued up.
>
> Ingo: Since you appear to have hardware, it would be great if you could
> test James' v3 (https://patchwork.kernel.org/patch/9519383/). Sorry for
> the inconvenience.
As per the interdiff below v2->v3 did not change the code in any way, only the
name of the function and a comment, so you can add this to v3 as well:
Reported-by: Ingo Molnar <mingo@...nel.org>
Tested-by: Ingo Molnar <mingo@...nel.org>
Thanks,
Ingo
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 6f9b4c051e4d..830e2c10ba02 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3899,7 +3899,7 @@ _scsih_temp_threshold_events(struct MPT3SAS_ADAPTER *ioc,
}
}
-static int set_satl_pending(struct scsi_cmnd *scmd, bool pending)
+static int _scsih_set_satl_pending(struct scsi_cmnd *scmd, bool pending)
{
struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
@@ -3934,7 +3934,7 @@ _scsih_flush_running_cmds(struct MPT3SAS_ADAPTER *ioc)
if (!scmd)
continue;
count++;
- set_satl_pending(scmd, false);
+ _scsih_set_satl_pending(scmd, false);
mpt3sas_base_free_smid(ioc, smid);
scsi_dma_unmap(scmd);
if (ioc->pci_error_recovery)
@@ -4084,7 +4084,9 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
}
/*
- * Bug work around for firmware SATL handling
+ * Bug work around for firmware SATL handling. The loop
+ * is based on atomic operations and ensures consistency
+ * since we're lockless at this point
*/
do {
if (sas_device_priv_data->ata_command_pending) {
@@ -4092,7 +4094,7 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
scmd->scsi_done(scmd);
return 0;
}
- } while (set_satl_pending(scmd, true));
+ } while (_scsih_set_satl_pending(scmd, true));
sas_target_priv_data = sas_device_priv_data->sas_target;
@@ -4661,7 +4663,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
if (scmd == NULL)
return 1;
- set_satl_pending(scmd, false);
+ _scsih_set_satl_pending(scmd, false);
mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
Powered by blists - more mailing lists