Mailing List Archive

Thomas Bogendoerfer wrote:
>
> I found following in patch-2.2.0-pre7:
>
> +{"IBM","DPES-","*", BLIST_NOTQ | BLIST_NOLUN},
>
> Vendor: IBM Model: DPES-31080 !t Rev: S31K
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> ncr53c810-0-<0,0>: tagged command queue depth set to 8
>
> I'm wondering why the disk above works with tagged command queuing since ages.
> In the pre-7 patch it was only for the DPES-31080, rev S31Q, but now
> it's for every DPES drive (or do I misunderstand something ?). Who thinks
> it's a good idea to blacklist every DPES drive ?
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.
--
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/

On Thu, Jan 14, 1999 at 08:55:54PM +0100, Peter T. Breuer wrote:
> It's ridiculous not to waste 4k of space on a list of config options in
> memory on 256MB servers holding up 30 client machines. It saves time and
> avoids confusion. It helps bug reporting too .. telephone conversation:
> "is your kernel configured for firewalling? .. I don't know! .. please
> zcat /proc/config.gz | mail me@here please .."
I agree. However, if someone *really* hasn't got the 4K to spare why not
make this a configuration option, ie allow /proc/config.gz to be
compiled out of the kernel. Like that everyone will be kept happy.
I suspect that most distributions will compile it in as it makes support
easier.
--
Alain Williams
-
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/

On Thu, 14 Jan 1999, Doug Ledford wrote:
> Thomas Bogendoerfer wrote:
> >
> > I found following in patch-2.2.0-pre7:
> >
> > +{"IBM","DPES-","*", BLIST_NOTQ | BLIST_NOLUN},
> >
> > Vendor: IBM Model: DPES-31080 !t Rev: S31K
> > Type: Direct-Access ANSI SCSI revision: 02
> > Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
> > ncr53c810-0-<0,0>: tagged command queue depth set to 8
> >
> > I'm wondering why the disk above works with tagged command queuing since ages.
> > In the pre-7 patch it was only for the DPES-31080, rev S31Q, but now
> > it's for every DPES drive (or do I misunderstand something ?). Who thinks
> > it's a good idea to blacklist every DPES drive ?
>
> 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.
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?
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. 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.
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.
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/

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/

On Fri, 15 Jan 1999, Doug Ledford wrote:
> 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/

Gerard Roudier wrote:
>
> On Fri, 15 Jan 1999, Doug Ledford wrote:
>
> > 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)?
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/