4 messages in org.freebsd.freebsd-scsiRe: ncr:2: ERROR (0:18)| From | Sent On | Attachments |
|---|---|---|
| B. Richardson | Aug 13, 1998 6:33 pm | |
| Stefan Esser | Aug 14, 1998 3:08 pm | |
| Justin T. Gibbs | Aug 15, 1998 2:33 pm | |
| B. Richardson | Aug 25, 1998 4:29 pm |
| Subject: | Re: ncr:2: ERROR (0:18) | |
|---|---|---|
| From: | B. Richardson (rabt...@aye.net) | |
| Date: | Aug 25, 1998 4:29:16 pm | |
| List: | org.freebsd.freebsd-scsi | |
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 rabt...@orion.aye.net
On Sat, 15 Aug 1998, Stefan Esser wrote:
On 1998-08-13 21:33 -0400, "B. Richardson" <rabt...@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 majo...@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message