From owner-freebsd-stable Mon Apr 8 12:08:16 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA18706 for stable-outgoing; Mon, 8 Apr 1996 12:08:16 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA18344 Mon, 8 Apr 1996 12:07:19 -0700 (PDT) Received: by Sisyphos id AA14399 (5.67b/IDA-1.5); Mon, 8 Apr 1996 21:06:39 +0200 Message-Id: <199604081906.AA14399@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 8 Apr 1996 21:06:38 +0200 In-Reply-To: Charles Owens "Re: -stable and NCR problems?" (Mar 25, 10:43) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Charles Owens Subject: Re: -stable and NCR problems? Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mar 25, 10:43, Charles Owens wrote: } Subject: Re: -stable and NCR problems? } On Fri, 22 Mar 1996, Stefan Esser wrote: } } > That's the infamous handshake timeout ... } > This feature seems to do more harm than good, } > and I'll apply the following patch to -stable } > (it has been in current for some time already): } } I'm giving the patch a try. } } >From time to time I also see the following. Is it related to the above } problem? } } Mar 25 07:53:32 dingo /kernel: sd0(ncr0:0:0): M_DISCONNECT received, but datapointer not saved: } Mar 25 07:53:32 dingo /kernel: data=2b9d78 save=2b9d78 goal=2b9e8c. Sorry for the delay, but I had no net access for two weeks ... The message indicates, that a SCSI device disconnected without sending a SAVE DATA POINTER message before all data for the current command had been transfered. This is sometimes done for error recovery, but usually only for tape devices. The drive is expected to reselect again, and the interrupted transfer will restart at the same point, were it started last time (and not where it had been interrupted). This might be an indication of a SCSI data transfer problem. I'll have to reread the SCSI specs to give a more detailed answer ... (I'm not sure whether there are SCSI drives, that disconnect without sending a CHECK CONDITION status (which would lead to some other diagnostic being printed after the lines you included) to recover from an SCSI parity error.) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se