[lkml]   [1998]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 3940UW Driver Locks the Machine
Gerard Roudier wrote:
> > 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.

Correct. However, in the current aic7xxx code we maintain the queue of
commands to be sent in kernel space, and the controller DMAs those commands
down. So, when this happens, we can easily just pause the sequencer, remove
the commands waiting but not sent yet, update the queue tail position to
reflect the number of commands we removed, then unpause the sequencer after
changing a few flags so the command will get sent untagged instead of
tagged. This assumes that the device rejecting the tagged command will
reject all tagged commands, and hence there won't be any outstanding
commands at the time of the rejection. We make this assumption because,
like you, if a drive randomly rejects tag commands it's horribly broken as
far as I'm concerned and someone else can write a firmware update :)

> 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.

I don't take into account all possible behaviours. I make one assumption,
that no device randomly rejects tags, they either accept them or reject
them, and from that point I simply stop tagged queueing on the first reject
I get for a tagged command (although, I do admit, if the reject comes on one
of our ordered Q tags, then I don't blow off tagging completely, just the
ordered tags).

> 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.

The one exception to this, which prompted me to put the code in, was that
certain OEM drive resellers were shipping decent hard drives out with the
DQue bit set. Since the drives were actually capable of tagged queueing,
and high enough performance to benefit from it, this was reasonable.
Especially when you consider that without the code, the driver went into an
abort/reset loop continually resetting the drive because it was failing on
tagged commands. The drives in question were IBM DFS series drives shipped
by Sun and Apple.


Doug Ledford <>
Opinions expressed are my own, but
they should be everybody's.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:41    [W:0.056 / U:1.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site