[ On Friday, September 6, 2002 at 11:17:13 (-0700), Matthew Jacob wrote: ]
> Subject: Re: 1.6 on IPC (tagged queuing bug still there)
>
> There was a period of time where the person who was qualifying the drive
> f/w for Sun (Jim Kahn) had a bunch of the drives accepted but then some
> of them had a lot of workarounds done in sd itself (like our quirks).
> This was in the period of 1990 or so thru about 1994 IIRC.

Would that be for SunOS-5 before tagged queuing could be turned off on a
per-target basis?

> The information about which of these drives are around is harder to find
> than it used to be.

True, but that's because there are fewer of those broken drives around
in working order any more -- and thus ever less reason to worry about
them in the first place.

> However, it's likely still to be the case certainly
> as people *consolidate* older sun hardware. You'll get lots of cases of
> people pulling drives from SS1s and SS2s (which did *not* have good
> T-qing support) and drop them into an SS10 (which shipped *way* before
> Zeus was finished).  After all, 3.5" narrow drives are just about only
> useful these days as internal drives in older h/w like this.

I think that's _very_ unlikely, at least for internal drives in an SS10.  :-)

Not only that but most semi-clued Sun "rescuers" know enough to watch
out for overheating problems when using older drives inside the various
sun pizza boxes.  My guess is most cooler running drives will be new
enough to be free of tagged queuing bugs.

> So, the *sensible* engineering manager, planning for a release for a
> class of machines which is *likely* to have broken drives makes the
> feature an *option* with a RTF note that says "here's how to get the new
> feature if you don't have older drives".

OK, then do it across the board on all drivers on all ports, scsipi
enabled or not.

Also, let's ask ourselves why Sun chose to enable tagged queueing by
default, even before there was support to turn it off on a per-target
basis.

Across the board older buggy drives are absolutely going to be the
extreme minority.  Forcing everyone to work for performance that should
be there in the first place just isn't fair.  Those few with buggy
drives that are not yet quirked can be dealt with easily on a one-off
basis.

I'm not talking about this from the point of view of someone who only
cares about the latest new stuff -- I am one of the people who run older
hardware, and especially older Sun hardware, in production (not just for
fun).

> This keeps a project within
> budget

"budget"?  What budget?  NetBSD is not commercial software.  It really
has no real desire or need to fight for market share.  It will not
suffer hugely if a few ancient (and probably failing anyway) drives
can't be used as primary installation targets (i.e. sd0).  There will be
no loss of income to TNF or any NetBSD developers due to increased
support requirements because of problems with an every more vanishingly
small minority of un-quirked buggy old SCSI drives.

> and is more *likely* than not to make the installation experience
> for *everyone* work well.

OK, then turn off tagged queuing in the INSTALL kernels only, but do it
for _all_ drivers on _all_ platforms.  If someone can bot the INSTALL
kernel and do an install or upgrade, but the new GENERIC fails to work
then they can ask for help quriking their drive.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>