> attention to the RFC that Sean Doran pointed me at (rfc2001)-  although I was
	> talking to Bob Snively about this a couple of weeks ago and he and I are a
	> little dubious that pure congestion control is what's needed given the nature
	> of SCSI devices (he's of the opinion that as soon as a QFULL condition is
	> done, jam it to the max- hence my slight unease at anything in QFULL handling
	> that has race conditions or any amount of complexity other than requeing
	> logic).

	I'm not sure this is rigth. It seems that some SCSI devices have a hard limit
	on the number of tag they can handle (for my quantun fireball it seems to be
	around 20), bumping it to the max (256) again would leave to another
	QFULL pretty soon, with a lot of xfer to requeue. We need an algorithm that
	can detect and stay around this limit.


SCSI disks typically can take a queue of 16-32, Fibre-Channel are usually
64.  These are fixed-length queues, so if there are multiple initiators
they are shared between the initiators.

RAID boxes are usually broken:  64-256 tags, but these are shared
among all the LUNs, so if you have 64 commands outstanding on each
of LUNs 0..4, you have no tags available for LUN 5 if you ever want
to send it a command.  You can get a QFULL condition with no outstanding
commands in that case.

What Jim Kahn recommends it to run until you get QFULL, set that as
the limit, then after 1m clear the limit. 

Eduardo