lkml.org 
[lkml]   [1999]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Blacklist for DPES-*
Gerard Roudier wrote:
>
> On Thu, 14 Jan 1999, Doug Ledford wrote:
>
> > I did. I don't know about Gerard's driver, but mine specifically does print
> > out whenever a device that we set up as tagged queueing capable rejects part
> > of our tagged queueing operation. That's what prompted that change. As for
> > the version issue, most drives in a single family respond identically. If
> > Gerard can confirm that your drive was actually using tagged queueing and that
> > the driver didn't silently disable it, then we can change this around.
>
> The ncr53c8xx driver(s) never disable(s) permanently tagged command
> queuing. It only sets the maximum numbers of tags to the number of
> disconnected commands when a QUEUE FULL status is reported by the device
> and dequeue all commands that are not started yet. It then increases this
> max number of commands by 1 every 1000 good status received up to the
> maximum configured, and so on ...
>
> Obviously, if the device returns QUEUE FULL when only 1 or ZERO commands
> are actually disconnected (happens on Atlas I with L912) tagged queueing
> may then be temporarily disabled.

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.

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

> AFAIR, I haven't any experience of serious TCQ failure with the
> drives I have had to use. The IBM disks I have (S12 and DDRS) and some
> others behaves well for me with TCQ.
> May-be I am just lucky or donnot perform hard enough crash-tests on my
> system.
>
> In my opinion, a blacklist for TCQ that just disallows the feature is too
> rude.

I agree that it's a bad thing. A depth hint for some drives would be
nice.

> 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 :)

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

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

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.033 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site