Subject: Re: NCR Driver Problems
To: Christoph Badura <>
From: Stefan Esser <>
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 Esser, Zentrum fuer Paralleles Rechnen		Tel:	+49 221 4706021
 Universitaet zu Koeln, Weyertal 80, 50931 Koeln	FAX:	+49 221 4705160
 ==============================================================================			  <se@ZPR.Uni-Koeln.DE>