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

Masao Fukuchi
2004-04-16T01:29:25Z

I checked my test report.

Moore, Eric Dean wrote:
>Which IOCSTATUS is returned when reproducing
>this issue that provides infinite loop?
>
>Here are the meanings of IOCSTATUS from the manual:
>
>MPI_IOCSTATUS_SCSI_TASK_TERMINATED - A SCSI Task Management request
>has terminated I/O.

- no inifinite loop

>MPI_IOCSTATUS_SCSI_IOC_TERMINATED - A IOC has terminated the SCSI I/O.
>This is typically an abort or bus reset initiated by the IOC.

- cut ATN signal
-> repeat SCSI_IOC_TERMINATED with LogInfo=0x11010100(bug! MID not found)
- cut DB signal
-> repeat command timeout and SCSI_IOC_TERMINATED

>MPI_IOCSTATUS_SCSI_EXT_TERMINATED - An external source has terminated the
>SCSI I/O. This is typically a bus reset from another initiator.

- I've not seen this message before.

>MPI_IOCSTATUS_SCSI_PROTOCAL_ERROR - An unrecoverable bus protocal error
>has terminated the SCSI I/O.

- cut I/O signal
-> repeat SCSI_PROTOCOL_ERROR
- cut MSG signal
-> repeat SCSI_PROTOCOL_ERROR

>
>On Wednesday, April 14, 2004 11:24 PM, Masao Fukuchi wrote:
>
>>
>>
>> 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
>>