Tagged Queueing and Dque Bit

[Doug Ledford]

On 07-Jan-98 Mike Bilow wrote:
> 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.

That's the problem, the INQUIRY command doens't go out until we are already
up in normal operation.  At init time we don't have the faintest clue what
devices are actually on the bus.  Additionally, since the mid-level SCSI
code doesn't bother to send out a mode page read command, we can't even peak
into that, we would end up peeking at the same data as the mid level SCSI
code and breaking just like it does.

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

Well, at the low level driver we really shouldn't spend much time figuring
out what's the underlying problem, etc.  We should be concentrating on
making things work.  Well, if a drive blows up when you send an identify
byte with the tagged queue bits set, then that's a pretty good indication we
shouldn't be doing that :)  So, we work around it.  It's kind of a failsafe
type thing to cover the condition we've been talking about as well as
covering cases of drives with a bogus firmware that claim to do tagged
queueing but can't for reasons other than the Dque bit.

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

Bingo, I think you have the Gold medal now! :)  Why does IBM and Seagate
ship their drives that way?  Especially since getting in with a SCSI mode
page editor is a *very* dangerous task for the uninitiated?  Are they
looking for something to increase the work load in an otherwise underworked
tech support and RMA staff?

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

That would almost be a wise thing for someone to add to their distribution
and what not.  At boot up have scsiinfo get the mode page configuration from
each device found, and on hard disks, check for the following things: AWRE
and Dque that matches the INQUIRY info on tagged queueing.  If it doesn't
pass these tests, then query the user about setting the AWRE bit and either
setting or clearing the Dque bit, then rebooting the machine.  That could
solve *many* a users problems and additionally makes the system more robust
when it comes to adding new drives.  This way, the new drives that come frmo
the factory in a fubared config state would get fixed up the first time you
boot with them.  That would be ideal if you ask me.

Now, someone could argue that you can't get to the scsiinfo program and the
script if the boot drive won't run because of tagged queueing issues, but
that isn't a concern unless you are replacing a dead root drive, and then
you can have the boot disk from the distributor do the same thing, problem
fixed.

----------------------------------
E-Mail: Doug Ledford <dledford at dialnet.net>
Date: 07-Jan-98
Time: 00:21:42
----------------------------------