From owner-cvs-all@FreeBSD.ORG Tue Jun 3 14:42:12 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E45837B40C; Tue, 3 Jun 2003 14:42:12 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id D922443F75; Tue, 3 Jun 2003 14:42:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from quaver.feral.com (mjacob@quaver.feral.com [192.67.166.210]) by beppo.feral.com (8.12.9/8.12.9) with ESMTP id h53LgBqw048034; Tue, 3 Jun 2003 14:42:11 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 3 Jun 2003 14:42:10 -0700 (PDT) From: Matthew Jacob X-X-Sender: mjacob@mailhost.quaver.net To: Ruslan Ermilov In-Reply-To: <20030603175426.GL79822@sunbay.com> Message-ID: <20030603142113.X48719@mailhost.quaver.net> References: <200306031747.h53Hlmrq096269@repoman.freebsd.org> <20030603175426.GL79822@sunbay.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Matt Jacob cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/mpt mpt.c mpt.h mpt_freebsd.cmpt_freebsd.hmpi_raid.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mjacob@feral.com List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 21:42:13 -0000 > This doesn't have any relation to the problem under HTT+SMP > with mpt(4) I was having, does it? Not directly. I'm sorting through some of the Domain Validation code I got from someboy at LSI-Logic. This current checkin is in support of that. There's a possibility that some of the issues that have been seen (not necessarily yours) are related to weaknesses in MPT firmware when Domain Validation is *not* performed. For example, if I connect an Ultra2 disk to an Ultra320 and have things all negotiate correctly, and then power cycle the Ultra2 disk, the ARQ data (auto request sense) for the subsequent check condition appears to be mangled (I can't decide whether it was shifted by a byte or endian fouled up). Nobody else has ever reported this, so I'm assuming it's due to me not doing DV. Oh well. -mtat