From owner-freebsd-hackers  Tue Feb 25 11:26:35 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id LAA10169
          for hackers-outgoing; Tue, 25 Feb 1997 11:26:35 -0800 (PST)
Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA10164
          for <hackers@freebsd.org>; Tue, 25 Feb 1997 11:26:32 -0800 (PST)
Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA23323
  (5.67b/IDA-1.5 for <hackers@freebsd.org>); Tue, 25 Feb 1997 20:26:26 +0100
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id UAA02075; Tue, 25 Feb 1997 20:26:23 +0100 (CET)
Message-Id: <19970225202622.HX00195@x14.mi.uni-koeln.de>
Date: Tue, 25 Feb 1997 20:26:22 +0100
From: se@freebsd.org (Stefan Esser)
To: nik@blueberry.co.uk (Nik Clayton)
Cc: hackers@freebsd.org
Subject: Re: 2.1.7: ncr and de driver increasingly fickle
References: <19970225164635.47646@coconut.blueberry.co.uk>
X-Mailer: Mutt 0.60_p2-3,5,8-9
Mime-Version: 1.0
In-Reply-To: <19970225164635.47646@coconut.blueberry.co.uk>; from Nik Clayton on Feb 25, 1997 16:46:35 +0000
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Feb 25, nik@blueberry.co.uk (Nik Clayton) wrote:
> Hi,
> 
> Has anyone else noticed an increased fickleness on 2.1.7 with the ncr and
> the de drivers?
> 
> On my 2.1.5 system, I never heard a complaint from the de driver, and the
> ncr driver might occasionally complain 
> 
>     /kernel: sd1(ncr0:1:0): extraneous data discarded.

Well, this is not a problem caused by the driver, IMHO ...

The number of data transfers requested by the target did not
match the transfer count. This normally indicates SCSI cable
problems, since it means either zero or two bytes have been
sent in a previous bus phase.

For synchronous transfers, you may also receive a gross error
in such situations. It is caused by a FIFO over- or underflow
as a result of a lost or doubled byte ...

The driver just counts the bytes transfered, and notices the
mismatch ...

Regards, STefan