[1005] in linux-scsi channel archive
Re: ncr53c8xx panic
daemon@ATHENA.MIT.EDU (Dan Hollis)
Sat Nov 23 18:21:14 1996
Date: Sat, 23 Nov 1996 16:14:05 -0800 (PST)
From: Dan Hollis <goemon@sasami.anime.net>
To: Gerard Roudier <groudier@club-internet.fr>
cc: linux-scsi@vger.rutgers.edu, linux-raid@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.91.961123220749.111A-100000@localhost>
On Sat, 23 Nov 1996, Gerard Roudier wrote:
> 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
> 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 ...
We have tried several cables and terminators. The system runs fine for
some time (days) then crashes.
Isn't there any better error recovery than to blow up completely on the
first error? The Buslogic driver seems to handle error conditions much
better, in that it actually tries very hard to recover (resetting
individual devices, then resorting to scsi bus resets, etc).
-Dan
