Re: [PATCH 2/5] fusion: vmware bug fix prevent inifinite retries

Manon Goo
2007-01-09T18:23:19Z

[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]

Hmm .... why don't w make the whole thing configurable (david implemented
this for us)

+/*
+ * cmd line parameters
+ */
+static int mpt_mpi_busy;
+module_param(mpt_mpi_busy, int, 0);
+MODULE_PARM_DESC(mpt_mpi_busy, " MPT MPI busy workaround for VMWare ESX
(default=0)");
+
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/

typedef struct _BIG_SENSE_BUF {
@@ -704,10 +711,13 @@
sc->resid=0;
case MPI_IOCSTATUS_SCSI_RECOVERED_ERROR: /* 0x0040 */
case MPI_IOCSTATUS_SUCCESS: /* 0x0000 */
- if (scsi_status == MPI_SCSI_STATUS_BUSY)
+ if ((scsi_status == MPI_SCSI_STATUS_BUSY) &&
!mpt_mpi_busy)
sc->result = (DID_BUS_BUSY << 16) |
scsi_status;
- else
+ else {
+ if (mpt_mpi_busy)
+ printk(KERN_INFO "MPT MPI ESX busy
hack enabled ... waiting\n");
sc->result = (DID_OK << 16) | scsi_status;
+ }
if (scsi_state == 0) {
;
} else if (scsi_state &
MPI_SCSI_STATE_AUTOSENSE_VALID) {

The prink(KERN... could be set if mpt_mpi_busy == 2 to make debugging of
the situation optional

Manon

--On 9. Januar 2007 10:17:17 -0600 Michael Reed <mdr@sgi.com> wrote:

>
>
> Moore, Eric wrote:
>> On Monday, January 08, 2007 3:25 PM, James Bottomley wrote:
>>
>>> Right, I sort of suspected something like this. BUSY/QUEUE_FULL
>>> handling was a bit iffy in 2.4; but it was sorted out in the 2003/4
>>> timeframe. Nowadays, I think you want to translate the
>>> MPI_SCSI_STATUS_BUSY directly to SAM_STAT_BUSY (i.e. just remove the
>>> special casing if).
>
> Christoph put in code to limit a command's lifetime to prevent infinite
> loops in the case of QUEUE_FULL and BUSY. (See scsi_softirq_done()
> for implementation.)
>
> DID_OK / COMMAND_COMPLETE / BUSY results in a ADD_TO_MLQUEUE for a retry,
> same as QUEUE_FULL. I don't infinite retries, just a whole lot of them.
> See scsi_decide_disposition().
>
> Mike
>
>>>
>>
>> I think your'e on the same page with the folks from VMware,
>> where the've asked us to go back to our old driver code.
>> Meaning we kill the check for "MPI_SCSI_STATUS_BUSY", instead the sam
>> status
>> is sent back "as is" without changing the DID_OK to DID_BUS_BUSY, etc.
>>
>> My problem with that is whether is breaks the Fibre Channel Folks.
>> Will FC failover solution work properly if we go back to the old code?
>> I add Stephen Shirron and Mike Reed.
>> I don't know. Here is an explanation why that fix was needed back
>> about a year ago:
>>
>>
>> "When a target device responds with BUSY status, the MPT driver was
>> sending DID_OK to the
>> SCSI mid layer, which caused the IO to be retried indefinitely between
>> the mid layer and the
>> driver. By changing the driver return status to DID_BUS_BUSY, the
>> target BUSY status can
>> now flow through the mid layer to an upper layer Failover driver, which
>> will manage the I/O timeout."
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>

Manon Goo
Dembach Goo Informatik GmbH & Co KG
Rathenauplatz 9
D-50674 Köln
Tel: +49 221 801483 0
Mobil: +49 177 8091974
Fax: +49 221 801483 20
Email: manon@dg-i.net

[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]