[3716] in linux-scsi channel archive
Re: ncr53c8xx-2.6 feature freeze. Need testers.
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Fri Apr 17 18:04:46 1998
Date: Fri, 17 Apr 1998 22:28:22 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Richard Waltham <dormouse@farsrobt.demon.co.uk>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <199804171809.TAA26760@farsrobt.demon.co.uk>
On Fri, 17 Apr 1998, Richard Waltham wrote:
> 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.
I did'nt write it was not legal (was wiser :) ).
I just did'nt find in the standard what relevant message the target can
send to the initiator in such a situation (problem detected in COMMAND
PHASE). But I perhaps missed something important.
Indeed, it can send a NOP message, then switch to STATUS PHASE and send
a CHECK CONDITION status. But it would be a lot simpler to directly go to
STATUS PHASE.
BTW, there was a buglet in 2.6i driver version that could explain the
problem above. :-)
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
