Re: 2.1.111: IDE DMA disabled?

Doug Ledford (
Thu, 30 Jul 1998 18:25:59 -0500

Gerard Roudier wrote:
> On Thu, 30 Jul 1998, Doug Ledford wrote:
> > Older Fireballs don't support tagged queueing. Newer Fireballs support it,
> > but have fixed tagged queue depths (8 for the Stratus and 15 for the
> > Tempest). However, the Tempest firmware will corrupt itself and become
> > totally useless if you keep 15 commands open for the majority of the time on
> > an extended basis. The drive will require a complete power cycle before it
> > will come back to life.
> Are these tagged queue depths so documentated by QUANTUM?

Nope, experimentally derived.

> > The Atlas drives also have a fixed maximum queue
> > depth of 32 commands, but will return QUEUE_FULL for conditions other than
> Hmmm ...
> I remember having read that the recommended queue depth for the Atlas II
> on AIX is 38.

The 32 for Atlas I drives is from Quantum tech support. If they recommend
38 on AIX it must be that AIX is really slow to send out commands. LAst I
heard, they only recommended 7 to 8 on Novell.

> I did get a try with an Atlas II using 64 tags and I remember it was
> capable to accept so many commands sometimes.
> The Viking II is documented as accepting a fixed maximum of 64 commands.
> Donnot know how it is supposed to behave in multi-initiator environment,
> but my guess is that this is also the maximum for the total amount of
> commands at any time and certainly not the maximum per initiator.
> > QUEUE_FULL if it simply isn't capable of taking another command at the
> A device can return QUEUE FULL status at any time when it receives a
> tagged command.

Sure, I'm not saying it can't. Just that some times a BUSY status instead
of QUEUE_FULL status would make more sense, but that Quantum doesn't use
BUSY at all as far as I can tell. It's their choice, since what they are
doing is legal by the spec, I just happen to think it's less intelligent
than it could be.

> The initiator has no handle on the thing which is stated
> to be full by the device. The SCSI specs are so about this status and are
> not going to change AFAIK.
> Gerard.


Doug Ledford <> Opinions expressed are my own, but they should be everybody's.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at