[3714] in linux-scsi channel archive
Re: ncr53c8xx-2.6 feature freeze. Need testers.
daemon@ATHENA.MIT.EDU (Richard Waltham)
Fri Apr 17 14:52:34 1998
From: Richard Waltham <dormouse@farsrobt.demon.co.uk>
To: groudier@club-internet.fr (Gerard Roudier)
Date: Fri, 17 Apr 1998 19:09:09 +0100 (BST)
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.980414162316.2243A-100000@localhost> from "Gerard Roudier" at Apr 14, 98 05:08:59 pm
Gerard Roudier wrote:
>
>
> On Tue, 14 Apr 1998, Ion Badulescu wrote:
>
> > Anyway, this problem is still present, together with the timeouts
> > generated by the same drive:
>
> > ncr53c875-0: restart (scsi reset).
> > ncr53c875-0-<5,0>: extraneous data discarded.
>
> Strange!
>
> > ncr53c875-0: enabling clock multiplier
> > ncr53c875-0: copying script fragments into the on-board RAM ...
> > ncr53c875-0: command processing resumed
> > ncr53c875-0-<5,0>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
> > ncr53c875-0-<6,0>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
> > ncr53c875-0-<5,0>: ordered tag forced, umap/smap=a4705351/4000.
> > ncr53c875-0-<5,0>: phase change 2-7 10@00fbd234 resid=4.
> > ncr53c875-0-<5,0>: ordered tag forced, umap/smap=a6de1255/a4501251.
> > ncr53c875-0-<5,0>: phase change 2-7 10@00fbd430 resid=4.
>
> This message indicates that the device switched from COMMAND PHASE to
> MESSAGE IN PHASE after having accepted some command bytes but not
> all the bytes (residual size = 4).
> This is weird since there is IMO no relevant message available that can
> be sent to an initiator when something goes wrong during command phase.
> The minimum SCSI command size is 6, so the device did accept at least
> 2 bytes.
> This is probably not a spurious COMMAND PHASE due to glitches or bad
> signal driving since the device did accept at least 2 bytes, but it could
> be a spurious MESSAGE IN PHASE (???).
> It could also be possible that the device decided to send a DISCONNECT
> message, but it should not IMO enter the COMMAND PHASE and then abort it.
> There is some timing differences between 2.5f and 2.6i and it is not
> the first time a SEAGATE ST15150N does work with some driver version
> and fails with some another one.
>
I've seen this type of behaviour occur in a couple of different situations,
but both due to the drive detecting some sort of error during the command
phase.
On one particular drive an illegal command would cause command phase to
terminate after one byte. The other was when the drive detected a parity
error while receiving the command. It would immediately switch to message in
without receiving the whole of the command.
Unusual but I think perfectly legal and of course could also happen during a
data out phase.
BTW the drive was a tape unit but I can't remember the type. It was a while
ago.
Bye for now
Richard
--
Richard Waltham | Work: richard@digtalinterface.demon.co.uk
At home in | Home: dormouse@farsrobt.demon.co.uk
Southampton UK | 100421.1276@compuserve.com
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
