headers
Tejun Heo | 1 Sep 2005 03:17
Picon

Re: [RFC] libata new EH document

Luben Tuikov wrote:
> On 08/30/05 06:26, Tejun Heo wrote:
> 
>>Albert Lee wrote:
>>
>>
>>>>4. Corresponding scmd's result code is set to
>>>>  SAM_STAT_CHECK_CONDITION and qc->scsidone() callback is called
>>>>  directly.  As we haven't filled sense data,
>>>>  scsi_determine_disposition() will return FAILED and SCSI EH will
>>>>  be scheduled.  Note that as we directly call qc->scsidone(), qc is
>>>>  left intact.
>>>>
>>>>
>>>
>>>Could we get the sense data before calling qc->scsidone()?  (Using the 
>>>proposed separate
>>>EH qc can keep the original qc intact.)
>>>
>>>The issue:
>>>When a DVD drive returns MEDIUM_ERROR in the sense data, libata doesn't 
>>>retry the command.
>>>
>>>For libata, when scsi_softirq() calls scsi_decide_disposition() and 
>>>scsi_check_sense() to determine
>>>how to handle the result, scsi_check_sense() always returns "fail" since 
>>>the sense data is not there
>>>yet. The sense data is requested later in the libata error handler. But 
>>>the command has already been
>>>considered as an "error".
(Continue reading)

Permalink | Reply | 48 comments |
headers
Jeff Garzik | 1 Sep 2005 04:22
Picon
Favicon

Re: [RFC] libata new EH document

Tejun Heo wrote:
>  IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> mapping as long as possible.  And, in the suggested framework, it's 
> guaranteed that no other command can come inbetween CHECK_SENSE and 
> REQUEST_SENSE.
> 
>  Requesting sense from EH, calling scsi_decide_disposition() on the 
> sense and following the verdict should achieve the same effect as 
> emulating autosense.  Is there any compelling reason to break one qc to 
> one command mapping?

Yes, you should have one qc <-> one ATA/ATAPI command.  That's why, in 
the NCQ scenario, I wanted to make sure that one qc was always reserved 
for error handling:  REQUEST SENSE or READ LOG EXT, most importantly.

For SAT layer MODE SELECT translations, that implies multiple calls to 
qc_new/qc_issue/qc_complete before completing the overall SCSI command. 
  The same for handling sata_sil mod15write:  I am beginning to feel 
like the mod15write workaround might be best implemented in a manner 
that caused libata-scsi (not sata_sil) to create/issue/complete multiple 
ATA commands.

The only problem you run into is that a qc may be active during EH, when 
you need another qc.  So avoiding recursive details becomes an issue.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeff Garzik | 1 Sep 2005 04:22
Picon
Favicon

Re: [RFC] libata new EH document

BTW I still have three of your documents to review and comment on. 
Haven't forgotten about them.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Sep 2005 04:42
Picon

Re: [RFC] libata new EH document

 Hello, Jeff.

On Wed, Aug 31, 2005 at 10:22:17PM -0400, Jeff Garzik wrote:
> Tejun Heo wrote:
> > IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> >mapping as long as possible.  And, in the suggested framework, it's 
> >guaranteed that no other command can come inbetween CHECK_SENSE and 
> >REQUEST_SENSE.
> >
> > Requesting sense from EH, calling scsi_decide_disposition() on the 
> >sense and following the verdict should achieve the same effect as 
> >emulating autosense.  Is there any compelling reason to break one qc to 
> >one command mapping?
> 
> 
> Yes, you should have one qc <-> one ATA/ATAPI command.  That's why, in 
> the NCQ scenario, I wanted to make sure that one qc was always reserved 
> for error handling:  REQUEST SENSE or READ LOG EXT, most importantly.

 Having an extra (as opposed to reserved) EH qc doesn't break one qc
<-> one command mapping.

 a. All EH commands are non-NCQ.
 b. Inside EH, no other command is allowed.

 So, we can allocate a qc which does not have a corresponding NCQ tag.
This qc will never be used for normal commands.  It's used only for
internal commands when no other qc can be active.

 If we don't have an extra qc for EH, as non-NCQ devices have only one
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luben Tuikov | 1 Sep 2005 05:30
Picon
Favicon

Re: [RFC] libata new EH document

--- Tejun Heo <htejun <at> gmail.com> wrote:
>   IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> mapping as long as possible.  And, in the suggested framework, it's 

Yes, that makes sense.

> guaranteed that no other command can come inbetween CHECK_SENSE and 
> REQUEST_SENSE.

That's good.

>   Requesting sense from EH,

Done in an ATA eh handler.

> calling scsi_decide_disposition() on the 
> sense 

Done in SCSI Core.

> and following the verdict should achieve the same effect as
> emulating autosense.

Yes, precisely.

> Is there any compelling reason to break one qc to 
> one command mapping?

?
(Continue reading)

Permalink | Reply | 40 comments |
headers
Luben Tuikov | 1 Sep 2005 05:33
Picon
Favicon

Re: [RFC] libata new EH document

--- Jeff Garzik <jgarzik <at> pobox.com> wrote:

> Tejun Heo wrote:
> >  IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> > mapping as long as possible.  And, in the suggested framework, it's 
> > guaranteed that no other command can come inbetween CHECK_SENSE and 
> > REQUEST_SENSE.
> > 
> >  Requesting sense from EH, calling scsi_decide_disposition() on the 
> > sense and following the verdict should achieve the same effect as 
> > emulating autosense.  Is there any compelling reason to break one qc to 
> > one command mapping?
> 
> 
> Yes, you should have one qc <-> one ATA/ATAPI command.  That's why, in 

Agree.

> the NCQ scenario, I wanted to make sure that one qc was always reserved 
> for error handling:  REQUEST SENSE or READ LOG EXT, most importantly.

Yes.

> For SAT layer MODE SELECT translations, that implies multiple calls to 
> qc_new/qc_issue/qc_complete before completing the overall SCSI command. 
>   The same for handling sata_sil mod15write:  I am beginning to feel 
> like the mod15write workaround might be best implemented in a manner 
> that caused libata-scsi (not sata_sil) to create/issue/complete multiple 
> ATA commands.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Sep 2005 05:44
Picon

Re: [RFC] libata new EH document

 Hi, Luben.

On Wed, Aug 31, 2005 at 08:30:27PM -0700, Luben Tuikov wrote:
> --- Tejun Heo <htejun <at> gmail.com> wrote:
> >   IMHO, it's a good idea to maintain one qc to one ATA/ATAPI command 
> > mapping as long as possible.  And, in the suggested framework, it's 
> 
> Yes, that makes sense.
> 
> > guaranteed that no other command can come inbetween CHECK_SENSE and 
> > REQUEST_SENSE.
> 
> That's good.
> 
> >   Requesting sense from EH,
> 
> Done in an ATA eh handler.
> 
> > calling scsi_decide_disposition() on the 
> > sense 
> 
> Done in SCSI Core.
> 
> > and following the verdict should achieve the same effect as
> > emulating autosense.
> 
> Yes, precisely.
> 
> > Is there any compelling reason to break one qc to 
> > one command mapping?
(Continue reading)

Permalink | Reply | 38 comments |
headers
Luben Tuikov | 1 Sep 2005 06:38
Picon
Favicon

Re: [RFC] libata new EH document

--- Tejun Heo <htejun <at> gmail.com> wrote:
>  As implementing autosensing will probably need rewriting failed qc
> for REQUEST SENSE command, I'm opposing it.  My proposal is to do the
> following, which, in effect, should be equivalent to autosensing.
> 
>  1. ATAPI CHECK SENSE occurs
>  2. libata fails the command
>  3. SCSI sees failure code but no sense data, SCSI EH invoked
>  4. libata EH invoked
>  5. REQUEST SENSE
>  6. sense data acquired
>  7. scsi_decide_disposition() called (this needs to be exported from SCSI)
>  8. libata handles the failed qc according to the verdict.

Hmm, yes.  It sounds good, except can you make it so that step 3
doesn't exist, ever.  This means that you would _reduce_ the
double "bouncing" between eh's _and_ implement autosense.

SCSI Core should never know what happened.  I.e. if the command
has completed with CHECK SENSE, sense data _is_ present => "autosense".

> This is very similar to what SCSI EH currently does for commands
> without sense data.

Yes, you're right -- it is very similar to what SCSI EH currently does.
Unfortunately it isn't quite correct.

>  As ATAPI device's queue depth is always one (ignoring SERVICE cruft
> everyone seems to hate), I don't think there will be any noticeable
> performance penalty as James was describing in the other mail in this
(Continue reading)

Permalink | Reply | 36 comments |
headers
Tejun Heo | 1 Sep 2005 07:44
Picon

Re: [RFC] libata new EH document


  Hello, Luben.

Luben Tuikov wrote:
> --- Tejun Heo <htejun <at> gmail.com> wrote:
> 
>> As implementing autosensing will probably need rewriting failed qc
>>for REQUEST SENSE command, I'm opposing it.  My proposal is to do the
>>following, which, in effect, should be equivalent to autosensing.
>>
>> 1. ATAPI CHECK SENSE occurs
>> 2. libata fails the command
>> 3. SCSI sees failure code but no sense data, SCSI EH invoked
>> 4. libata EH invoked
>> 5. REQUEST SENSE
>> 6. sense data acquired
>> 7. scsi_decide_disposition() called (this needs to be exported from SCSI)
>> 8. libata handles the failed qc according to the verdict.
> 
> 
> Hmm, yes.  It sounds good, except can you make it so that step 3
> doesn't exist, ever.  This means that you would _reduce_ the
> double "bouncing" between eh's _and_ implement autosense.
> 

  libata EH is invoked from SCSI EH via hostt->eh_strategy_handler(), so 
they're one - libata EH uses SCSH EH framework to operate.  I'm having 
hard time understanding what you mean by 'double bounncing'.

> SCSI Core should never know what happened.  I.e. if the command
(Continue reading)

Permalink | Reply | 34 comments |
headers
Jeff Garzik | 1 Sep 2005 07:54
Picon
Favicon

Re: [RFC] libata new EH document

On Thu, Sep 01, 2005 at 02:44:00PM +0900, Tejun Heo wrote:
>  Can you please elaborate why getting sense data from EH is bad idea 
> for ATAPI?  For more advanced SCSI transports, I agree with you that 
> autosensing is necessary with queueing and multiple initiator and etc, 
> but I don't really see how requesting sense from EH would be bad for ATAPI.

The long term direction for the SCSI core seems to be that of
requiring auto-sensing.

libata is simply being lazy:  while the SCSI core continues to support
kicking the EH thread when sense is missing, it's preferred for libata
to reuse that infrastructure.

Auto-sensing (and READ LOG EXT for NCQ errors) requires either an
FSM or a kernel thread, to initiate a secondary qc for REQUEST SENSE.
Since the common infrastructure already exists for this, libata reuses
the existing SCSI EH kernel thread.

We should move libata-scsi to auto-sensing, but it's not an urgent priority.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 32 comments |

Gmane