Date: Sat, 15 Aug 1998 00:08:22 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: "B. Richardson" <rabtter@aye.net>, freebsd-scsi@FreeBSD.ORG Cc: Stefan Esser <se@FreeBSD.ORG> Subject: Re: ncr:2: ERROR (0:18) Message-ID: <19980815000822.A1587@mi.uni-koeln.de> In-Reply-To: <Pine.SGI.3.95.980813211349.21619B-100000@orion.aye.net>; from B. Richardson on Thu, Aug 13, 1998 at 09:33:45PM -0400 References: <Pine.SGI.3.95.980813211349.21619B-100000@orion.aye.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1998-08-13 21:33 -0400, "B. Richardson" <rabtter@aye.net> wrote: > > I am jinxed. I fought the "Timed out while idle" with and adaptec 3940 > for a month and finally ditched it a day before Justin posted the > sequencer file and got a Diamond Fireport 40. Played with > termination/cables for weeks with a 2.2 6/29 snapshot. Reinstalled > 2.2.5 (had a CD handy) with the Diamond Fireport 40, ran some > bonnie test for a few hours, and put my cacheing server live today. > After about 8 hours this happens (chunks of dmesg output below). > Lovely error message is after Drives/controllers. > ------- Lovely error message ------------ > > ncr0:2: ERROR (0:18) (1-21-302) (10/9d) @ (script 6cc:19000000). SIST = 0x18 => Gross Error + Reselected by Another Device The "Gross Error" condition is what caused the transfer to fail. Seems there is some electrical problem, or the Viking violates the SCSI protocol. The conditions that set the Gross Error bit in the SCSI Interrupt Status Register are: 1) Data Underflow (more data requested by target than available) 2) Data Overflow (more data sent by target than expected) 3) Offset Underflow ([target mode only, does not apply]) 4) Offset Overflow (target exceeded max. sync. offset) 5) Phase Change (with outstanding synchronous offset) 6) Residual data (data left over in sync. FIFO) All these conditions are most probably caused by a lost REQ or ACK. In order to exclude case 4) you could try patching the NCR driver to negotiate a lower "offset". The bus phase seems to have been DATA IN, which corresponds to the NCR command "MOVE TABLE" with DATA IN bus phase (0x19000000). Everything I see indicates, that there is handshake problem on the SCSI bus. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980815000822.A1587>