Date: Tue, 25 Aug 1998 19:29:37 -0400 (EDT) From: "B. Richardson" <rabtter@aye.net> To: Stefan Esser <se@FreeBSD.ORG> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ncr:2: ERROR (0:18) Message-ID: <Pine.SGI.3.95.980825192346.17554A-100000@orion.aye.net> In-Reply-To: <19980815000822.A1587@mi.uni-koeln.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Replaced the cable, replaced the MB, and got an active terminator. The "ncr0:2: ERROR" message is gone but every few days I get these Aug 20 18:21:38 rabtter /kernel: ncr0: timeout ccb=f1026000 (skip) Aug 20 18:21:38 rabtter /kernel: ncr0: timeout ccb=f1026800 (skip) Aug 20 18:21:46 rabtter /kernel: ncr0: timeout ccb=f1026400 (skip) and the filesystems freeze. Any hints, tips, suggestions? - Barrett Richardson rabtter@orion.aye.net On Sat, 15 Aug 1998, Stefan Esser wrote: > 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?Pine.SGI.3.95.980825192346.17554A-100000>