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