From owner-freebsd-scsi Wed Oct 6 14:43:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1670115163 for ; Wed, 6 Oct 1999 14:43:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA01887; Wed, 6 Oct 1999 14:43:36 -0700 Date: Wed, 6 Oct 1999 14:43:36 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Gerard Roudier Cc: "Justin T. Gibbs" , Vadim Belman , scsi@FreeBSD.ORG Subject: Re: 'Unexpected busfree' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The behaviour of those old peripherals does not look that bad to me, > even if some better one may be possible. > > Since SCSI parity bit mostly protects against single bit error, a SCSI BUS > that experiences oftently SCSI parity errors has some non negligible > probability to lead to undetected data corruptions. So, dropping the BUS > is such a situation is quite acceptable and warn user about possible BUS > problem, provided that the unexpected bus free condition is loudly > reported to him by the system. > > The SCSI device may elect to try to recover by restoring the saved > pointers. This may look more user-friendly but will increase the risk of > silent data corruption as seen by user. May-be the most clever device > decision should be to try asap to complete the command with appropriate > sense data, but just dropping the BUS seems to me a more safe device > behaviour than trying to recover from a SCSI parity error. I agree with you. An unexpected bus free shouldn't be a problem. It does make it difficult to use the correct sense key for the next command though as an unexpected bus free is not an indicator to run Request Sense. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message