Date: Sun, 4 Feb 2001 21:35:41 -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: <20010204213541.A79966@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.05.10102041929020.14471-100000@misery.sdf.com>; from tom@sdf.com on Sun, Feb 04, 2001 at 07:38:52PM -0800 References: <20010204194302.A79212@panzer.kdm.org> <Pine.BSF.4.05.10102041929020.14471-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 04, 2001 at 19:38:52 -0800, Tom Samplonius wrote:
>
> On Sun, 4 Feb 2001, Kenneth D. Merry wrote:
>
> > On Sun, Feb 04, 2001 at 17:33:16 -0800, Tom Samplonius wrote:
> > >
> > > On Sun, 4 Feb 2001, Mike Smith wrote:
> > >
> > > ...
> > > > I've recently fetched all my controllers back out of storage, so with any
> > > > luck, I'll be able to post a followup to this in a little while with a
> > > > better answer for you.
> > >
> > > It is not hard to replicate. I happen to be using a RAID volume with 3
> > > x 18GB disks. "camcontrol tags da0" says that there is only one opening.
> > > Setting the openings to 4 ("camcontrol tags da0 -N 4") and do a bit of
> > > heavy IO, and it will be hung within a minute.
> >
> > Hmm, that's odd, generally if there is only one opening, that means that
> > tagged queueing is not enabled. We have a default quirk entry in the
> > transport layer to limit any unquirked device to a minimum of two tags, if
> > tagged queueing is enabled.
> >
> > What does 'camcontrol negotiate da0 -v' say? If tagged queueing isn't
> > enabled, I wouldn't think that changing the number of tags would have any
> > effect. In experiments here, bumping the tag count doesn't really work if
> > the device doesn't support tagged queueing:
>
> "camcontrol tags da0 -v" output after a fresh boot:
>
> (pass0:mly0:2:0:0): dev_openings 1
> (pass0:mly0:2:0:0): dev_active 0
> (pass0:mly0:2:0:0): devq_openings 1
> (pass0:mly0:2:0:0): devq_queued 0
> (pass0:mly0:2:0:0): held 0
> (pass0:mly0:2:0:0): mintags 2
> (pass0:mly0:2:0:0): maxtags 255
>
> da0 is a virtual SCSI disk via the mly driver. Since there is only one
> dev_opening, I'm assuming that one IO can be done at a time. Is that
> right?
Right.
> 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.
> > {vladivostok:/usr/home/ken:22:0} camcontrol negotiate cd0 -v
>
> "camcontrol negotiate da0 -v" output:
>
> Current Parameters:
> camcontrol: XPT_GET_TRANS_SETTINGS CCB failed, status 0x6
>
>
> I guess "negotiate" isn't supportted by the mly driver. That seems
> quite typical for virtual disks accessed via a RAID driver.
Yep (from sys/dev/mly/mly_cam.c):
default: /* we can't do this */
debug(2, "unspported func_code = 0x%x", ccb->ccb_h.func_code);
ccb->ccb_h.status = CAM_REQ_INVALID;
break;
}
> The dpt
> driver does the same thing, but the dpt driver does seem to be using up to
> two tags (output from a different system with a DPT SmartRAID IV card):
>
> (pass0:dpt0:0:0:0): dev_openings 2
> (pass0:dpt0:0:0:0): dev_active 0
> (pass0:dpt0:0:0:0): devq_openings 2
> (pass0:dpt0:0:0:0): devq_queued 0
> (pass0:dpt0:0:0:0): held 0
> (pass0:dpt0:0:0:0): mintags 0
> (pass0:dpt0:0:0:0): maxtags 255
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.
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?20010204213541.A79966>