Date: Sun, 4 Feb 2001 20:22:56 -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.10102042009270.14471-100000@misery.sdf.com> In-Reply-To: <20010204213541.A79966@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
"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)
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.
> > > {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.
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
> 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?Pine.BSF.4.05.10102042009270.14471-100000>