The tag number is defined as an 8 bit value, so anything between 0 and
255 are valid. If the device is so busted that it thinks only 0 to 31
(or some other arbitrary range of tags) is valid, then I won't bother
supporting TCQ on that device.
> As you know, when only the TAG (order+#tag) is rejected by a device, then
> the initiator is required to handle the command as an untagged command.
This is *exactly* the situation that the code in question in my driver
is designed to detect. This is the condition that should exist any time
we get the device is refusing tagged commands message.
> If the drive behaves so when some other commands are disconnected, then an
> OVERLAPPED COMMAND condition may occur. Some device may decide to behave
> so when they are in some initialization process, but if they do when they
> are full ready to operate then I agree that they must be rudely
> blacklisted.
> BTW, I donnot intend to support such crap devices with the ncr driver.
Neither do I. However, due to the fact that my driver and your driver
aren't necessarily seeing the same thing on these drives, I've removed
it from the blacklist and disabled the TCQ by default in my driver for
the 2.2.0 release. After I can take a look at this drive in more detail
and see what's really taking place (and possibly fix my driver if there
is something wrong in the rejection code) then I'll be more prepared to
actually claim it is or isn't broken :)
> > > I donnot remember having received any problem report for TCQ involving a
> > > DPES-31080. But since I donnot have such an hard disks, I cannot tell more
> > > about these drives.
> > >
> > > I have some drives that return QUEUE FULL sometimes:
> > > Atlas I L912, Atlas II LXY4, Cheatah2 0004.
> > > I didn't upgrade the Atlases since they are fine for testing and I never
> > > lost a single bit using them. The Cheetah needs to be flooded with
> > > something like 50 commands at a time with write cache enabled in order to
> > > start returning QUEUE FULL. I didn't remember any of these disks having
> > > ever rejected a SCSI command with TCQ enabled on my system.
> > > BTW, could you let me know the way used by the drive to reject tagged
> > > commands. Does it send a M_REJECT message when it is supplied with
> > > the ORDER TYPE + TAG message?
> >
> > That's handled separately and in that case it only disables the ordered
> > tags....
>
> ??? I donnot understand what you mean at this point.
Most commands are sent as SIMPLE_QUEUE_TAG commands, but the driver will
detect when a device will accept the SIMPLE tags but rejects
ORDERED_QUEUE_TAGs and then it only disables use of the
ORDERED_QUEUE_TAGs instead of disabling tagged queueing entirely.
> Tell me if I am wrong, but I understand that you have decided to blacklist
> the DPES drive since you have personnaly observed some misbehaviour of the
> drive on some of your system. Even if it will appear that you are right
> about the drive bug, this way to proceed for black-listing devices seems
> to be also bogus. I think it should be also black-listed. ;-)
No, I did send a patch to Linus to remove it from the blacklist. I went
on the assumption that something was wrong, but I specifically drew you
(and any others that might have been lurking as well) into the
conversation for either confirmation or rejection of that blacklist
entry.
> If you want to seriously check if the drive really deserves your
> punishment, why not to post to the list some proposal of testings that
> users that have such drives will be able to try and report you results?
I'd rather just get my hands on one of those drives so I can see what's
really taking place with it :)
--
Doug Ledford <dledford@redhat.com>
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/