Re: [RFC][PATCH]SCSI signal(I/O) failure causes no response

Masao Fukuchi
2004-04-15T05:24:18Z

I saw following IOC status by my test tool.
MPI_IOCSTATUS_SCSI_TASK_TERMINATED
MPI_IOCSTATUS_SCSI_IOC_TERMINATED

But for these IOC status, I saw some kind of error like another
IOC status or timeout just before(or after) the above IOC
status.

I think the SCSI_PROTOROL_ERROR has a some different meaning from
others.

Masao Fukuchi

Moore, Eric Dean wrote:
>For this particular issue, Mr Masao Fukuchi has a
>scsi bus test analyzer, in which he set the C/D signal
>to low during read operation. The MPT firmware
>returned MPI_IOCSTATUS_SCSI_PROTOCAL_ERROR, which from
>the mpt manual means " An unrecoverable bus protocal error
>as terminated the SCSI I/O" and the driver will
>return DID_RESET.
>
>Here are some of the other cases which return
>DID_RESET, however I doubt were returned with
>Mr Masao Fukuchi's test anaylzer:
>
>MPI_IOCSTATUS_SCSI_TASK_TERMINATED
>MPI_IOCSTATUS_SCSI_IOC_TERMINATED
>MPI_IOCSTATUS_SCSI_EXT_TERMINATED
>
>
>
>On Wednesday, April 14, 2004 9:28 AM, James Bottomley wrote:
>
>>
>>
>> On Tue, 2004-04-13 at 20:07, Masao Fukuchi wrote:
>> > 1.Fusion MPT driver issues read command to its firmware.
>> > (our server has LSI53C1030 as SCSI adapter)
>> > Then the firmware returns protocol error for the command.
>> > Fusion MPT driver makes DID_RESET status by protocol error
>> > and sends it to SCSI midlayer.
>> >
>> > 2.SCSI midlayer analyzes the status from LLD.
>> > SCSI midlayer schedules command retry because the status is just
>> > DID_RESET status.
>> > (When the status has DID_RESET plus some sense code, the retry
>> > sequence depends on the sense code. But when the status has only
>> > DID_RESET, SCSI midlayer schedules command retry)
>> >
>> > Sequence 1. and 2. are repeated infinitely and it causes no
>> response.
>> >
>> > To prevent this problem, I proposed Eric Moore to change
>> the DID_RESET
>> > status to DID_SOFT_ERROR in fusion MPT driver.
>> > But he suggested me to change SCSI midlayer to prevent
>> infinite loop.
>>
>> Well, there clearly is a problem, because we can't retry no-rety
>> commands that return DID_RESET (like tape commands or fastfail).
>>
>> However, DID_RESET is supposed to be returned for events where it was
>> determined that the command was lost because the bus or
>> device was reset
>> (either as part of error handling or because an external entity issued
>> the reset). Since these events, if they originate externally, can be
>> beyond the control of the device, making retryable commands subject to
>> the retry limit would be asking for unnecessary I/O errors because of
>> something we couldn't do anything about.
>>
>> Why is the LSI driver returning DID_RESET for the problem (i.e. is it
>> some type of external bus reset, or is something else going on)?
>>
>> James
>>
>>
>-
>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