Date: Sun, 4 Feb 2001 19:38:52 -0800 (PST) From: Tom Samplonius <tom@sdf.com> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <Pine.BSF.4.05.10102041929020.14471-100000@misery.sdf.com> In-Reply-To: <20010204194302.A79212@panzer.kdm.org>
index | next in thread | previous in thread | raw e-mail
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?
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.
...
> {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. 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
> Ken
> --
> Kenneth Merry
> ken@kdm.org
Tom
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10102041929020.14471-100000>