Re: [RFC] libata new EH document

2005-09-07 Thread Jeff Garzik
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

Re: [RFC] libata new EH document

2005-09-02 Thread Stefan Richter
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 more

Re: [RFC] libata new EH document

2005-09-01 Thread James Bottomley
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

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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 being lazy:

Re: [RFC] libata new EH document

2005-09-01 Thread Jeff Garzik
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

Re: [RFC] libata new EH document

2005-09-01 Thread James Bottomley
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 contingent

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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

Re: [RFC] libata new EH document

2005-09-01 Thread Jeff Garzik
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

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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 Contingent

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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. That's this

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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 fundamental level.

Re: [RFC] libata new EH document

2005-09-01 Thread Luben Tuikov
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. That's this

Re: [RFC] libata new EH document

2005-08-31 Thread Tejun Heo
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

Re: [RFC] libata new EH document

2005-08-31 Thread Jeff Garzik
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

Re: [RFC] libata new EH document

2005-08-31 Thread Jeff Garzik
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

Re: [RFC] libata new EH document

2005-08-31 Thread Tejun Heo
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

Re: [RFC] libata new EH document

2005-08-31 Thread Luben Tuikov
--- 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. That's

Re: [RFC] libata new EH document

2005-08-31 Thread Luben Tuikov
--- 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.

Re: [RFC] libata new EH document

2005-08-31 Thread Luben Tuikov
--- 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 fails

Re: [RFC] libata new EH document

2005-08-31 Thread Tejun Heo
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 CHECK

Re: [RFC] libata new EH document

2005-08-30 Thread Tejun Heo
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

Re: [RFC] libata new EH document

2005-08-29 Thread Tejun Heo
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 to