basic domain validation patches
Matthew Jacob
lydianconcepts at gmail.com
Mon Nov 6 23:36:20 UTC 2006
I haven't heard anything- please take the time to review these changes.
On 11/2/06, mjacob at freebsd.org <mjacob at freebsd.org> wrote:
>
> See http://people.freebsd.org/~mjacob/DV_PATCHES
>
> The ANSI document on Domain Validation gives an algorithm for doing
> Basic Domain Validation as, in part:
>
> Send an INQUIRY command to a SCSI device 3 times- twice with the
> default transfer agreement and once with the transfer agreement set
> to the fastest supported values. The Basic test fails when the first
> 36 bytes of data returned at the negotiated synchronous speed does not
> match the data received at the asynchronous transfer speed. In
> addition, the Basic test fails if a CRC error (or parity error for
> non-DT clocking) or a timeout occurs. If data miscompare occurs, the
> test should be repeated (e.g., this could be due to the target changing
> INQUIRY data during SCSI device initialization). After a finite number
> of retries, if data miscompare recurs then fall-back should be
> attempted (see 5.5.2).
>
> and 5.5.2 has:
>
> If Basic or Enhanced tests fail, a fall-back setting is set and the
> tests are performed again. The recommended fall-back order is:
>
> 1. fast-160
> 2. fast-80
> 3. fast-40 (with DT clocking enabled)
> 4. fast-40 (with ST clocking enabled)
> 5. fast-20
> 6. fast-10; and
> 7. asynchrnous transfer.
>
> I've done an implementation interwoven into the probe code in cam_xpt
> such that the following occurs..
>
> The normal sequence is:
>
> ...
> INQUIRY (short)
> INQUIRY (long)
> ...
> ('default' sync settings are enabled)
> ...
> PROBE_TUR_FOR_NEGOTIATION
> <END>
>
> I've changed <END> to be:
>
> PROBE_TUR_FOR_NEGOTIATION
> PROBE_INQUIRY_BASIC_DV1
> ...
> PROBE_INQUIRY_BASIC_DV2
> ...
>
> The idea here is to leverage the two initial INQUIRY commands done at
> async mode and compare with the last known one and to do *two*
> additional INQUIRY commands (at speed) to see if they compare with the
> last ASYNC long INQUIRY command. If they don't, we can do backoff and
> just re-enter the state machine at PROBE_TUR_FOR_NEGOTIATION.
>
> The backoff doesn't do DT/ST settings, but just simply increments the
> sync_period factor until we hit 0xf (5 MHz) and then drops to async.
>
> I don't mess with PPR settings on the theory that the SIM will do the
> right thing with PPR settings depending on the values of sync period and
> offset.
>
> By doing fault injection (e..g, failed compares) I've done some testing
> and this *appears* to do what one would want.
>
> Any comments? I *know* there are people out there on this list who have
> more experience with DV than I do so I'd appreciate some comments.
>
> -matt
>
>
>
>
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"
>
More information about the freebsd-scsi
mailing list