From owner-freebsd-scsi Sun Jun 2 14:45:49 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12983 for freebsd-scsi-outgoing; Sun, 2 Jun 1996 14:45:49 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA12972 for ; Sun, 2 Jun 1996 14:45:43 -0700 (PDT) Received: by Sisyphos id AA21668 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Sun, 2 Jun 1996 23:45:02 +0200 Message-Id: <199606022145.AA21668@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 2 Jun 1996 23:45:01 +0200 In-Reply-To: Tony Kimball "ncr scsi Qs" (May 29, 0:45) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Tony Kimball Subject: Re: ncr scsi Qs Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On May 29, 0:45, Tony Kimball wrote: } Subject: ncr scsi Qs } } Since switching from an Adaptec 1542CF ISA to a CSC NCR PCI scsi } controller, my ancient Micropolis drive has been filling my logs } with this stuff: } } May 28 23:25:36 compound /kernel: sd1(ncr0:2:0): RECOVERED ERROR info:1857e6 asc:3,0 Peripheral device write fault } May 28 23:25:36 compound /kernel: , retries:4 } May 28 23:25:36 compound /kernel: sd1(ncr0:2:0): extraneous data discarded. } May 28 23:25:36 compound /kernel: sd1(ncr0:2:0): COMMAND FAILED (9 0) @f10d3400. } May 28 23:30:09 compound /kernel: sd1(ncr0:2:0): RECOVERED ERROR info:1b6aa5 asc:3,0 Peripheral device write fault } May 28 23:30:09 compound /kernel: , retries:4 Hmm, I'm not sure about the exact definition of the ASC info the drive returns, but it appears to be a problem detected by the firmware which leads to the current command being aborted. This does not seem to be a SCSI bus parity problem, since the message would be different ... } Is this a familiar problem for anyone? I had the adaptec turned down } to 8MB/sec in order to accomodate this drive. Is there any way to } throttle back the scsi bus xfers on the ncr controller? Yes, sure: # ncrcontrol -t 2 -s sync=8 will reduce the sync. transfer speed the driver is willing to negotiate to at most 8MHz. The -t limits the following options to just the target selected (ID 2 in this case). See the "ncrcontrol" man page for details and further options. 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