> Gerard Roudier wrote:
> >
> > I donnot have a Jaz device. Based on reports and especially on Richard
> > Waltham testings with such a device, it seems to me that the Jaz may in
> > certain circumstances reject a TAG (after having been selected).
> > The SCSI specs allow that to targets when they are in some initialisation
> > process and, AFAIR, the initiator is invited (required?) to perform the
> > command as if the command was not TAGGED.
> > Implementing such a behaviour is pain in the ass, since several TAGGED
> > commands may have been queued to drivers and/or controllers when a TAG
> > is so rejected.
>
> Well, in practice, this should never be a problem. It would be illegal for
> a device to reject a TAG message when it has outstanding tags already. It
> can do so after a reset or during power on, but in both of those cases, it
> wouldn't have any outstanding commands. At power up, you haven't sent any
A driver that performs one command at a time with each device, or that
controls the SCSI protocol from the C code will probably deal easily
with a TAG having being refused (using a MESSAGE REJECT).
If we want to reduce command latency and allow the controller to process
outstandings commands as quickly as possible we must prepare several
commands per device and queue them to the controller 'firmware'
('sequencer' for the Adaptec, 'SCRIPTS' for the ncr and 'firmware' for
assumed Intelligent Controllers). In such a situation when a TAG is
rejected, we have to reverse all that stuff or at least partially or to
manage this from the C code using interrupts. Remember that, once selected,
only the target can disconnect the BUS and change SCSI phase.
> yet, and after a reset you just blew them all away anyway :) In my
> experience (so far, this is a new feature in my current driver) there aren't
> hardly any devices that reject tag messages after they've indicated during
> an IDENTIFY that they support tags. I also don't have problems after a Bus
In my opinion, a device that rejects TAGS in a non predictive way is
crappy.
> Device Reset or Bus Reset because of the built in delay time I use (to get
> around that initialisation process time period). So, the only devices that
BTW, such a delay has been implemented in the ncr driver since one year.
> should reject tags are ones that indicate in the Identify info that they can
> do tagged queueing, but because of a firmware bug or the status of the DQue
> bit, can't. To date, I don't really know how well that code works because
> this is so rare :) But, when it does happen, my code simply blows away any
> commands it may have already queued up as having been reset and then resends
> the current command as untagged. It assumes the device will *never* accept
> a tagged command and then reject a tagged command while it still has
> commands in its queue (at least not in the sense of immediate rejection
> after the TAG message, it might reject based on other reasons, but we keep
> track of the last message so we know what got rejected). If a device ever
> rejects the TAG message when it has outstanding tagged commands, it damn
> sure better do a bus free next or else be prepared for me to blow it off
> with a Bus Device Reset or a full bus reset. If it goes back into the
> mesg_out phase I'll have no choice but to kill the current transfer and
> since an initiator technically isn't suppossed to do a bus free itself, that
> leaves no alternative but the reset alternatives.
I've considered all that and even more. If someone want to take into
account all compliant and non compliant SCSI device behaviours regarding
Tagged Command Queueing, I am interested in knowing the real gain compared
to the needed effort.
Only high end SCSI devices really gain advantage of tagged commands and
they generally behave well enough with this feature. I doubt that
crappy Jaz devices are really faster with tagged commands and so,
I am not about to spare time for useless improvements.
> > IMO, this would require additionnal complexity in scsi drivers
> > in a way that may affect performances and reliability.
> >
> > Note that the device may claim to be in some initialisation process
> > only after a reset and while it is spinning up.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu