From owner-freebsd-current Wed Mar 15 17:43:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA04648 for current-outgoing; Wed, 15 Mar 1995 17:43:03 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA04642 for ; Wed, 15 Mar 1995 17:43:02 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id RAA09025; Wed, 15 Mar 1995 17:41:56 -0800 From: Poul-Henning Kamp Message-Id: <199503160141.RAA09025@ref.tfs.com> Subject: Re: Problems with SCSI drive & ncr To: dufault@hda.com (Peter Dufault) Date: Wed, 15 Mar 1995 17:41:56 -0800 (PST) Cc: bvickers@bossanova.ICS.UCI.EDU, current@FreeBSD.org In-Reply-To: <199503160133.UAA02099@hda.com> from "Peter Dufault" at Mar 15, 95 08:33:30 pm Content-Type: text Content-Length: 740 Sender: current-owner@FreeBSD.org Precedence: bulk > There was a posting on comp.periphs.scsi about this and the Sun > system was complaining about a "vendor specific" code asc:47 ascq:0, > but I looked at the spec and don't see that this can be anything > but parity error. > > If anyone has any ideas holler. In general, if you see parity errors, you see weird stuff. The chances of the parity-error to be caught is not something to bet the ranch on. Could we make a scsi-test program, which somehow tests the cable & termination by sending a lot of data forth and back, without writing it to the disk ? -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant'