Tejun Heo wrote:
Hello, Jeff, Albert & ATA developers.
This is the final one of recent document series for libata EH - SCSI
EH, ATA exceptions, libata EH and, this one - libata new EH.
This document tries to discuss how to implement new advanced EH. It
also describes some proposed mechanism
Jeff Garzik wrote:
Linux is NOT about big designs. Linus says "do what you must, and no
more."
The scsi subsystem is used in so many divergent areas, its set of
requirements is "big". Therefore its design has to be "big".
The future will bring other "baby steps" that evolve us towards a mor
On 09/01/05 19:01, James Bottomley wrote:
> On Thu, 2005-09-01 at 18:36 -0400, Luben Tuikov wrote:
>
>>So are you claiming that
>>"the error handler clears contingent allegiance conditions" ?
>>
>>Please point me to the lines in the source code where it does this
>>and how it does it.
>
>
>
On 09/01/05 18:27, Jeff Garzik wrote:
>>I think it's only because "it's there" and that it provides
>>a uniform access -- provided by SCSI, _not_ by that particular
>>SCSI implementation.
>
>
> You're correct in one sense, but I still don't think you understand
> Linux development at a fundament
On 09/01/05 19:01, James Bottomley wrote:
> On Thu, 2005-09-01 at 18:36 -0400, Luben Tuikov wrote:
>
>>So are you claiming that
>>"the error handler clears contingent allegiance conditions" ?
>>
>>Please point me to the lines in the source code where it does this
>>and how it does it.
>
>
>
On Thu, 2005-09-01 at 18:36 -0400, Luben Tuikov wrote:
> So are you claiming that
> "the error handler clears contingent allegiance conditions" ?
>
> Please point me to the lines in the source code where it does this
> and how it does it.
That's this bit:
static void scsi_unjam_host(struct
Luben Tuikov wrote:
On 09/01/05 17:46, Jeff Garzik wrote:
This is the same reason a couple RAID drivers use the SCSI layer. It
has nothing to do with SCSI-as-defined-by-T10, and more to do with the
Do you think T10 has anything to offer Linux SCSI Core?
I was attempting to differentiate
On 09/01/05 18:23, James Bottomley wrote:
> On Thu, 2005-09-01 at 18:07 -0400, Luben Tuikov wrote:
>
>>>Well, not really, since it's basic SCSI and the explanation's pretty
>>>long. However, the standards have several pages about it. For your
>>>reading pleasure, I suggest SAM-2 section 5.9.1 Co
Luben Tuikov wrote:
On 09/01/05 17:46, Jeff Garzik wrote:
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.
That makes the most sense ;-)
For libata it doesn't really
On Thu, 2005-09-01 at 18:07 -0400, Luben Tuikov wrote:
> > Well, not really, since it's basic SCSI and the explanation's pretty
> > long. However, the standards have several pages about it. For your
> > reading pleasure, I suggest SAM-2 section 5.9.1 Contingent allegiance
> > (CA) and auto contin
On 09/01/05 17:46, Jeff Garzik wrote:
> This is the same reason a couple RAID drivers use the SCSI layer. It
> has nothing to do with SCSI-as-defined-by-T10, and more to do with the
Do you think T10 has anything to offer Linux SCSI Core?
Luben
> fact that SCSI provides a robust queuei
On 09/01/05 17:55, James Bottomley wrote:
> On Thu, 2005-09-01 at 17:40 -0400, Luben Tuikov wrote:
>
>>>The current SCSI autosense in drivers doesn't require this because we
>>>reuse the existing command that got the contingent allegiance condition.
>>
>>Care to elaborate what "contingent allegian
On 09/01/05 17:46, Jeff Garzik wrote:
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.
>>>
>>>
>>>That makes the most sense ;-)
>>
>>
>>For libata it doesn't really
On Thu, 2005-09-01 at 17:40 -0400, Luben Tuikov wrote:
> > The current SCSI autosense in drivers doesn't require this because we
> > reuse the existing command that got the contingent allegiance condition.
>
> Care to elaborate what "contingent allegiance condition" is,
> how SCSI Core got it, how
Luben Tuikov wrote:
On 09/01/05 09:24, James Bottomley wrote:
On Thu, 2005-09-01 at 01:54 -0400, Jeff Garzik wrote:
The long term direction for the SCSI core seems to be that of
requiring auto-sensing.
No, I don't see the mid-layer error thread handling of this ever going
away.
libata
On 09/01/05 09:24, James Bottomley wrote:
> On Thu, 2005-09-01 at 01:54 -0400, Jeff Garzik wrote:
>
>>The long term direction for the SCSI core seems to be that of
>>requiring auto-sensing.
>
>
> No, I don't see the mid-layer error thread handling of this ever going
> away.
>
>>libata is simply
On Thu, 2005-09-01 at 01:54 -0400, Jeff Garzik wrote:
> The long term direction for the SCSI core seems to be that of
> requiring auto-sensing.
No, I don't see the mid-layer error thread handling of this ever going
away.
> libata is simply being lazy: while the SCSI core continues to support
> k
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 s
Hello, Luben.
Luben Tuikov wrote:
--- Tejun Heo <[EMAIL PROTECTED]> 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 CHEC
--- Tejun Heo <[EMAIL PROTECTED]> 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 f
Hi, Luben.
On Wed, Aug 31, 2005 at 08:30:27PM -0700, Luben Tuikov wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> 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.
>
> >
--- Jeff Garzik <[EMAIL PROTECTED]> 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
--- Tejun Heo <[EMAIL PROTECTED]> 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.
T
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
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-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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_dispositio
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 wi
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
>
On Tue, 2005-08-30 at 17:10 +0800, Albert Lee wrote:
> Could we get the sense data before calling qc->scsidone()? (Using the
> proposed separate
> EH qc can keep the original qc intact.)
Well, the way most SCSI drivers do it today is to turn around the
command returning Check Condition from irq
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-
Tejun Heo wrote:
Hello, Jeff, Albert & ATA developers.
This is the final one of recent document series for libata EH - SCSI
EH, ATA exceptions, libata EH and, this one - libata new EH.
This document tries to discuss how to implement new advanced EH. It
also describes some proposed mechanisms
Oops, typos.
Gotta take a nap.
On Mon, Aug 29, 2005 at 03:11:24PM +0900, Tejun Heo wrote:
> Hello, Jeff, Albert & ATA developers.
>
> This is the final one of recent document series for libata EH - SCSI
> EH, ATA exceptions, libata EH and, this one - libata new EH.
>
> This document tries
Hello, Jeff, Albert & ATA developers.
This is the final one of recent document series for libata EH - SCSI
EH, ATA exceptions, libata EH and, this one - libata new EH.
This document tries to discuss how to implement new advanced EH. It
also describes some proposed mechanisms in detail. I'm a
33 matches
Mail list logo
