Tagged Queueing and Dque Bit

[Mike Bilow]

Daniel M. Eischen wrote in a message to Mike Bilow:

> After I figured out the Dque bit, and reset it to zero, it worked flawlessly
> with tagged queueing enabled.
>
> So I would suggest, that the driver should check also the Control Mode
> Page (if available), and should honor the Dque bit (fall back to not use 
> tagged queueing if Dque is set).

 DME> The driver is not in the business of making it's own SCSI
 DME> commands and sending them to the target.  The mid-level SCSI
 DME> code and target drivers do this.  The mid-level SCSI code
 DME> detects whether the drive is capable of doing tagged
 DME> queueing and sets a bit in the SCSI request structure that
 DME> the driver looks at.  If this bit is set, and tagged
 DME> queueing is enabled in the driver, then you're going to get
 DME> tagged queueing.

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.

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