Subject: Re: NCR Driver Problems
To: Christoph Badura <bad@flatlin.ka.sub.org>
From: Stefan Esser <se@zpr.uni-koeln.de>
List: current-users
Date: 01/24/1996 16:34:43
On Jan 24, 2:10, Christoph Badura wrote:
} Subject: Re: NCR Driver Problems
} Stefan Esser wrote:
} >It is well possible, that it fully supports tags.
} >It is just picky about non-tagged commands (even
} >NOP commands) sent when any tagged command is
} >active.
}
} And it has every right to do so:
}
} SCSI-2 7.8: " An initiator may not mix the use of tagged and untagged
} queuing for I/O processes to a logical unit, except during a
} contingent allegiance or extended contingend allegiance condition ..."
}
} 7.8.2: "An I/O process received without a queue tag message, while
} there are any tagged I/O commands in the command queue from the same
} initiator, is an incorrect initiator connection (see 7.5.2), unless
} there is a contingent allegiance or extended contingent allegiance
} condition."
Yes, I have a copy of the SCSI-2 spec. and I knew
about this. But thanks for the quotation, anyway.
} The same holds when a target receives a tagged command while a
} untagged command from the same initiator is in its command queue.
Yes, sure.
} I figure the problem isn't with the generic SCSI code but with your
} driver violating the standard.
The GENERIC SCSI code issues the start unit command,
and the driver sends it to the drive. It includes a
simple tag message, if tags are in use on this drive.
Now there seem to be drives that don't like that
START STOP UNIT command being accompanied by a tag.
And there seem to be drives, that do some kind of
soft reset, making the drive unresponsive for as
much as a second or two.
And those cause problems.
Now, where is the problem in my driver ?
The GENERIC code should remember, whether a drive has
been started (i.e. opened), and should not send any
more START UNIT requests.
STefan
--
Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160
==============================================================================
http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>