From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 15 04:45:46 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2753616A403 for ; Wed, 15 Nov 2006 04:45:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B57743D66 for ; Wed, 15 Nov 2006 04:45:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAF4jcrS098364; Tue, 14 Nov 2006 21:45:43 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455A9B72.4000605@samsco.org> Date: Tue, 14 Nov 2006 21:45:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Matthew Jacob References: <7579f7fb0611142023l614c0d3bj4559c0b26b5817b8@mail.gmail.com> In-Reply-To: <7579f7fb0611142023l614c0d3bj4559c0b26b5817b8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: basic domain validation patches- 3rd and final call X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 04:45:46 -0000 Go for it! Matthew Jacob wrote: > Please review, or these will be going in as the basis for ongoing > work. They aren't perfect, but I believe that they are a sorely needed > start. Speak now or forever hold your piece. > > On 11/2/06, mjacob@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 >> >> >> I've changed 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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"