> In this case, my driver detects when a device sends us a MSG_REJECT
> message right after a tag queue message and then handles it. The start
> of all of this was caused by this very action happening
> repeatedly/reliably on an IBM drive. Take a look in the current code at
> the REJECT_MSG code in handle_seqint() to see what I'm talking about.
Are you sure that the device is rejecting the tag because it does not
want more tags? Could it be possible that it is just confused by the tag
numbering (too great tag number)?
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.
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.
> > 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.
[ ... ]
> > It has been reported that some drives may work reasonnably using a
> > small number of tags, and even just using 2 tagged commands instead of
> > untagged commands may lower significantly command latency.
>
> Then again, on the Quantum Fireball ST and TM drives, tag queueing
> doesn't make any difference due to shitty firmware, so this is obviously
> drive dependant :)
And probably benchmark dependant :)
Some impressive results that are sometimes reported with IDE disks let me
think that most widely-used benchmarks are way-stupid.
Flames expected from IDE lovers. ;-)
> > Replacing the NOTQ flag by some numbers of tags (maximum and suggested for
> > example) should probably be more relevant in my opinion. We should not
> > miss that for 2.3.
>
> Even though enabling TCQ by default works for 99.999% of all users, it
> looks like I'm going to have to turn it back off due to things like
> these broken drives......
As you know, everything that involves computers _is_ buggy and sometimes
much buggy. However, these buggy things often work for numerous people.
If we wanted to blacklist everything that is bogus, then we would just
have to simply blacklist everything, and only accept to deal with
basic features. ;)
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. ;-)
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?
Regards,
Gerard.
-
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/