Date: Mon, 5 Feb 2001 15:28:04 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Tom Samplonius <tom@sdf.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <20010205152804.A85729@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.05.10102042009270.14471-100000@misery.sdf.com>; from tom@sdf.com on Sun, Feb 04, 2001 at 08:22:56PM -0800 References: <20010204213541.A79966@panzer.kdm.org> <Pine.BSF.4.05.10102042009270.14471-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 04, 2001 at 20:22:56 -0800, Tom Samplonius wrote:
> On Sun, 4 Feb 2001, Kenneth D. Merry wrote:
>
> > > After increasing the number of tags to 4, I did run "camcontrol tags da0
> > > -v" repeatedly, and noticed that dev_active varied between 0 and 4.
> > > However, da0 hung a short while later, just after outputting an error
> > > message from the mly driver.
> >
> > Were there any error messages when it hung? Does the device claim to
> > support tagged queueing in its inquiry information? (dmesg or camcontrol
> > inquiry da0 should tell you)
> >
> > Since we can't determine via camcontrol negotiate whether it supports
> > tagged queueing, we can look at the inquiry data.
> >
> > If it doesn't support tagged queueing, then increasing the tags is probably
> > a bad idea. We should probably have a check in the transport layer that
> > rejects any attempt to raise the number of tags above 1 if the device
> > doesn't support tagged queueing.
>
> Yes, the mly driver reported an error. I mentioned it in a previous
> e-mail, and it eludes me now. Something about receiving a completion for
> an invalid/unknown slot.
>
> If it doesn't support tags, wouldn't it die immediately, rather than try
> to use them for a minute or so, and then hang the disk? Since, the tag
> handling is likely done completely within the mly driver, it seems like
> something could be done to at least prevent the hang from occuring even if
> tags can't be used.
A lot of the tag handling is done in the transport layer, actually. The
transport layer decides how many transactions to queue to the HBA driver.
So if the transport layer thinks the HBA can handle tagged queueing, it
will queue more than one transaction to the device at a time.
> "camcontrol inquiry da0" isn't helpful:
>
> pass0: <RAID 5 online > Fixed Direct Access SCSI-2 device
> pass0: Serial Number
> camcontrol: error getting transfer settings
>
>
> dmesg isn't much more helpful:
>
> da0 at mly0 bus 2 target 0 lun 0
> da0: <RAID 5 online > Fixed Direct Access SCSI-2 device
> da0: 34680MB (71024640 512 byte sectors: 255H 63S/T 4421C)
For the dmesg at least, you would have gotten a 'Tagged Queueing Enabled'
message if the device were capable of it, even though the transfer settings
aren't printed out.
> I do get the following messages just before the probe messages:
>
> mly0: physical device 0:8 gone
> mly0: physical device 0:8 gone
> mly0: physical device 0:8 gone
> mly0: physical device 0:8 gone
> mly0: physical device 0:8 gone
>
> I've always assumed this is the SAF-TE device builtin the enclosure. The
> Mylex card deals with the SAF-TE device events directly, and I think this
> is an attempt by the mly driver to attach it. Again, lots of assumptions.
> Either way, it seems harmless. Everything is 100% stable as long as tags
> = 1.
I don't know what that message is about, but from what I can see, we should
only be sending one command to that device at a time, and there shouldn't
be any way we could send any more, since the device doesn't claim to
support tagged queueing.
So, in short, it doesn't look like your problem is related to trying to
increase the tags, since I don't think you can.
To verify this, try:
camcontrol tags da0 -N 4 -v
If the output looks like this:
{lindon:/usr/home/ken:22:0} camcontrol tags cd0 -N 4 -v
(pass4:ahc4:0:0:0): tagged openings now 4
(pass4:ahc4:0:0:0): dev_openings 1
(pass4:ahc4:0:0:0): dev_active 0
(pass4:ahc4:0:0:0): devq_openings 1
(pass4:ahc4:0:0:0): devq_queued 0
(pass4:ahc4:0:0:0): held 0
(pass4:ahc4:0:0:0): mintags 2
(pass4:ahc4:0:0:0): maxtags 255
Then you can't do tagged queueing and the settings aren't having any
effect. If dev_openings + dev_active are greater than 1, we've got a
problem, since we shouldn't be allowing that to happen for a device that
doesn't claim to support tagged queueing.
> > There is a quirk entry for the DPT volumes to disable serial number
> > inquiries and probing multiple luns. It bogusly sets mintags to 0, though.
> > In general mintags and maxtags should be 0 and 0 for devices that don't
> > support tagged queueing, 2 and 255 for devices that do, or some other range
> > of values for devices that can't properly handle queue fulls.
> >
> > So the DPT quirk entry should be changed, but how it should be changed
> > depends on whether or not it supports tagged queueing. What does dmesg or
> > camcontrol inquiry say about either array?
> >
> > That should tell you whether the device itself believes it supports tagged
> > queueing.
>
> I don't much care about the dpt issue as much as the mly one. The dpt
> driver at least seems to be support two outstanding IOs, which is much
> better than one. I've brought dpt as another example of a virtual SCSI
> disk driver. The dpt driver, limited to 2 openings, seems quite stable.
> I've never seen a problem with it under 3.5-STABLE. I've never attempted
> to increase the number of tags though.
>
> "camcontrol inquiry da0", where da0 is attached via a dpt driver:
>
> pass0: <DPT RAID-1 07M0> Fixed Direct Access SCSI-2 device
> camcontrol: error getting transfer settings
Yeah, camcontrol bails if the get transfer settings CCB fails, although
you'll still see 'Tagged Queueing Enabled' in the dmesg if the array
actually supports it.
My guess is that the DPT driver reports queue full until we've reduced the
number of tags to 2, thus the reason you get two.
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010205152804.A85729>