[1002] in linux-scsi channel archive
Re: ncr53c8xx panic
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sat Nov 23 15:25:56 1996
Date: Sat, 23 Nov 1996 22:22:18 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Dan Hollis <goemon@sasami.anime.net>
cc: linux-scsi@vger.rutgers.edu, linux-raid@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95L01at.961123012727.19360A-100000@sasami.anime.net>
On Sat, 23 Nov 1996, Dan Hollis wrote:
> Linux 2.0.25
>
> When it crashed (I had to write this down by hand)
> ----------------
> ncr53c810-0:3: ERROR (80:48) (8-28-0) (8/13) @ (14c0:88030000).
> script cmd = 18000000
I have script offsets. 14c0 is inside data_out script part:
[...]
resel_lun = 0bd8
resel_tag = 0c20
data_in = 0c80
data_out = 149c
aborttag = 1cb8
[...]
The script processor was sending the first segment of data when it has
been interrupted.
In my opinion, it is an underflow or overflow.
That means that number of ACKs have been different from number of REQs.
In asynchronous mode each byte is handshaked. In synchronous mode, this
handshake use a kind of pacing that is negotiated by host and device.
For NCR, this pacing is generally negotiated to 8.
Regardless of mode (sync or async), #ACK must be same as #REQ.
It is very probably a scsi bus problems:
- Cable (cross fingers or pay too much for them)
- Termination (actives are better)
- Cable length (1.5s meter is good, 3 meters can be too much)
- Cable closed to metallic components (must be > 2 mm)
- Etc ...
Gerard.
