Tagged Queueing and Dque Bit

[Mike Bilow]

Doug Ledford wrote in a message to Mike Bilow:

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

 DL> That's a nightmarish prospect, peeking into command request
 DL> buffers after completion but before returning it to the mid
 DL> level code.  No, I don't think that's a real option.

No, no... I meant doing it as a one-shot deal at boot time, during driver
initialization.  I agree that doing it on a continuing basis would be insane.

 DL> On the other hand, the latest version of the seqeuncer and 
 DL> kernel code code that I'm working on from FreeBSD includes 
 DL> support for detecting drives that claim to do tagged queueing 
 DL> but then blow up when you send tagged commands.  In that case, 
 DL> the driver disables tagged queueing internally for that device 
 DL> and sends everything as untagged commands.  This should be 
 DL> sufficient to solve the problem people are seeing from these 
 DL> devices.

That's a partial solution: it gets the drive working, but makes no attempt to
diagnose the underlying problem or give hints toward a real solution.

Look at this from the perspective of the person writing the firmware inside the
IBM drive which manifested this problem.  The firmware probably allocates a
bunch of internal buffers for the queued commands, figuring out how much space
will be needed on the basis of, among other things, the DQue bit.  Why waste
the buffers if they are not accessible?  Your partial fix would show this as a
broken drive, when the truth is that it is just optimized for a very strict
compliance with the SCSI specification.

I admit that it is a mystery to me why IBM ships their drive with DQue asserted
by default, just as it is a mystery to me why Seagate ships their drives with
AWRE disabled by default.  When I saw the post on this problem, my first
thought was to wonder how much of our problems with tagged queueing and
supposedly bad drives have been attributable to this issue.

Carrying the comments made by you and Dan further, maybe we're all looking at
the wrong fundamental problem.  I said in an earlier message that correct mode
page configuration was really a user responsibility, although most users are
not really capable of dealing with it.  Perhaps the real solution here is a
userland utility that builds from ScsiInfo to make suggestions and detect these
oddball settings, a sort of SCSI Lint?  Any of the text-handling languages such
as Perl could be used to parse the output of ScsiInfo.
 
-- Mike