Tagged Queueing and Dque Bit

[Daniel M. Eischen]

> I think there's a design problem here.  Devices usually return data in response
> to the INQUIRY command out of ROM, including the state of the CmdQue bit which
> indicates whether tagged queueing capability exists.  It is then up to the
> initiator to enable or disable tagged queueing through the DQue bit on the
> Control Mode Page, and should at the same time configure the QErr bit to
> determine whether unexecuted commands in the queue are to be aborted when an
> error occurs.  If the mid-level SCSI code is depending solely upon the INQUIRY
> response without either reading or writing the Control Mode Page, then this is
> a clear error that needs to be fixed -- it may solve a lot of problems.

I don't have the Linux mid-level SCSI code handy, but it is indeed
checking the INQUIRY response and setting the tagged queueing bit
in the Scsi_Device structure.  This bit in the device structure,
along with driver configuration options, are the only things
that the driver looks at in determining whether to perform tagged
queueing or not.  Whoever sets this bit (the Linux mid-level SCSI
code) should be the responsible party.  Furthermore, SCSI commands
should come from the Linux mid-level SCSI code and not from the
driver (with the exception of the sense request).

>  DME> If a fix is to be made for this, it belongs in the mid-level
>  DME> SCSI code.

> That makes some sense, but I see no reason we could not at least perform a
> sanity check and warn about any inconsistency.  We're in the middle: if the
> mid-level SCSI code is telling us to do tagged queueing and the device is
> telling us it has tagged queueing disabled, it seems we are in a good position
> to notice this and do something about it.

Ahh, but we're not in a good position to do this.  And when you think
about how this affects other drivers you'll see why it is better
in the mid-level SCSI code anyways - why have duplicate code in
each driver doing exactly the same thing?

Dan Eischen
deischen at iworks.InterWorks.org