Date: Sun, 04 Feb 2001 21:57:10 -0800 From: Mike Smith <msmith@freebsd.org> To: Tom Samplonius <tom@sdf.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tags and the mly driver Message-ID: <200102050557.f155vBs00494@mass.dis.org> In-Reply-To: Your message of "Sun, 04 Feb 2001 20:22:56 PST." <Pine.BSF.4.05.10102042009270.14471-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Since we can't determine via camcontrol negotiate whether it supports
> > tagged queueing, we can look at the inquiry data.
Well, the array supports multiple outstanding commands per logical unit
(it wouldn't make a lot of sense if it didn't), but there's no need to
have tags associated with them (since the driver/adapter protocol
contains the equivalent of the 'tag' already).
> > 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.
How do we go about telling the transport layer that multiple commands per
target is OK, but that we don't care about tags?
More specifically, the limit on total outstanding commands is per HBA,
not per channel or per target.
> 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.
This is separate, and probably represents a problem in either the
firmware of the adapter (possible) or in my handling of the queues
between the driver and the adapter (more likely, although I have searched
long and hard for race conditions and not had much luck actually catching
any).
> 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.
Actually, the driver should probably block attempts to access the
enclosure device as well as disks listed in the array config, since the
controller is meant to handle these. The driver doesn't actually attach
to it - this is the generic CAM code.
I'm not sure what's up with non-disk devices going away; again, probably
a bug in the passthrough command handling.
> I don't much care about the dpt issue as much as the mly one. The dpt
The mly adapter *should* support up to the maximum number of commands
supprted by the adapter per logical unit (eg. if the adapter supports
512 commands, you should be able to have that many outstanding per unit).
The fact that it appears not to be doing this now is a bug, and I need to
fix it. Thanks for mentioning it - Ken, if you have any suggestions
based on the code in sys/dev/mly/mly_cam.c, I'd be thankful.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
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?200102050557.f155vBs00494>