ATAPI corruption found

ATAPI corruption found

[Jeff Garzik]

When atapi_qc_complete() takes the error path, completes the SCSI 
command, SCSI EH runs, and the code attempts to complete the SCSI 
command again, this time with scsi_finish_command().

Ideally what we should be doing is simply not completing the SCSI 
command until REQUEST SENSE is complete, more accurately simulating 
autosense.

I should have a fix in the next day or so, unless somebody beats me to it.

	Jeff

Re: ATAPI corruption found

[Tejun Heo]

  Hi, Jeff.

Jeff Garzik wrote:
> 
> When atapi_qc_complete() takes the error path, completes the SCSI 
> command, SCSI EH runs, and the code attempts to complete the SCSI 
> command again, this time with scsi_finish_command().

  Umm.. that's how it worked until now by design.  Can you elaborate how 
corruption occurs?

> 
> Ideally what we should be doing is simply not completing the SCSI 
> command until REQUEST SENSE is complete, more accurately simulating 
> autosense.
> 
> I should have a fix in the next day or so, unless somebody beats me to it.

  Hehheh, nobody beat you. :-)

-- 
tejun

Re: ATAPI corruption found

[Jeff Garzik]

Tejun Heo wrote:
> 
>  Hi, Jeff.
> 
> Jeff Garzik wrote:
> 
>>
>> When atapi_qc_complete() takes the error path, completes the SCSI 
>> command, SCSI EH runs, and the code attempts to complete the SCSI 
>> command again, this time with scsi_finish_command().
> 
> 
>  Umm.. that's how it worked until now by design.  Can you elaborate how 
> corruption occurs?

It completes the SCSI command twice.  Once in atapi_qc_complete(), and 
once in ata_qc_timeout().

And I doubt it has ever -really- worked as hoped...

	Jeff

Re: ATAPI corruption found

[Tejun Heo]

  Hello, Jeff.

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>>
>>  Hi, Jeff.
>>
>> Jeff Garzik wrote:
>>
>>>
>>> When atapi_qc_complete() takes the error path, completes the SCSI 
>>> command, SCSI EH runs, and the code attempts to complete the SCSI 
>>> command again, this time with scsi_finish_command().
>>
>>
>>
>>  Umm.. that's how it worked until now by design.  Can you elaborate 
>> how corruption occurs?
> 
> 
> It completes the SCSI command twice.  Once in atapi_qc_complete(), and 
> once in ata_qc_timeout().

  I hope I'm not completely misunderstanding what you're saying.  If so, 
please be kind enough to point out.

  When a SCSI LLDD reports failure of a command to midlayer, several 
actions can be taken.  scsi_decide_disposition() determines what to do 
depending on which result code LLDD reports and what content the sense 
buffer contains.  Some commands are just reported upward 
(scsi_finish_command), some retried and other are passed on to EH for 
further recovery action.

  When a scmd is handed off to EH,

- it isn't finished yet.
- it will be finished or retried by calling either scsi_finish_command()
   or scsi_queue_insert().

  So, when EH is needed, SCSI ML passes the scmd to EH without finishing 
it and EH is responsible of what to do with the scmd.

  This is exactly what's going on w/ ATAPI request sensing.  libata asks 
SCSI ML to invoke EH for the scmd by completing a scmd with CHECK_SENSE 
but without sense data, so SCSI ML invokes EH to read sense data and 
actually determine what to do.  libata EH is invoked and it reads sense 
data and finishes the scmd with the sense data.  AFAIK, this is how SCSI 
EH works.

> And I doubt it has ever -really- worked as hoped...

  With proper fixes to libata EH, it works.  I can definitely tell you 
that and I think Albert can also verify that ATAPI request sensing 
works.  libata EH currently has some issues with stuff like 
synchronization with normal processing and etc, but it's nothing 
fundamental.  After all, that's how SCSI EH works.

  If I'm being stupid here, please point out.  I'll hit my head as hard 
as I can and take a long tearful shower.  :-)

  Thanks.

-- 
tejun