From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.periphs.scsi
Subject: CAM (was Re: Would there be any interest in splitting this group?)
Date: 16 Dec 92 07:50:06 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

jag@zk3.dec.com writes:
>In article <37702@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
>>[ data-in-underrun is "not bad", data-in-overrun generates error,
>>  data-out-underrun is "not bad", data-out-overrun requires hard Reset(!!!!) ]
>>
>>	While your reasoning seems valid, can you tell me where it says this
>>in the spec?  If it doesn't, should it?  ...............................
>
>    It is not in the spec.   When we were discussing it in the committee
>it was like "self evident".  

	Hmm, obviously not self-evident enough...

>
>>......................................?  I can conceive of arguments for
>>a number of different interpretations of how over/underrun should be
>>handled.  If I were implementing it from the spec, I probably would have
>>created an implementation that disagreed with yours.  I think this point
>>needs clarification.  Also, a hard bus reset seems IMMENSELY drastic!
>>What if some other device was writing to a tape from a buffer when it saw
>>reset?  Etc, etc.  I agree writing non-provided data has it's problems too,
>>but I think hard reset is worse!  The peripheral driver submitted the request.
>>Either it didn't provide enough data (bug in driver), or the device is
>>requesting more data than the command specified (can this ever happen due to
>>noise/reflections?)
>
>    In any event an this occurring in DATA OUT is an error, either a bug
>in the driver or a bug in the device/Hardware.  Digital as a company
>has this "thing" about data corruption.  We figured that it was "better"
>to risk loosing Tape position, rather than writting 0's over some Banks
>accounting data base.  At least I would be perturbed if my checking accout
>balance suddenly went from "near zero" to zero :-).

	You can lose a hell of a lot more than tape position.  For example,
what if another disk is currently disconnected and writing data?  A hard bus
reset might make it stop (I _hope_ not in mid-sector, but I could certainly
see it happening - in fact I suspect it's the normal case).  I think that
such an overrun should be the driver's problem to deal with, rather than
potentially corrupting unrelated transactions on the bus.  I would implement
this as writing 0's (or BAD BAD BAD..., I don't care), and return a residual
as mentioned.  I could see also setting ATN and ABORTing, and returning an
error for the status (as well as a residual value).  I just can't see
hard bus reset being a reasonable alternative, even in a single-initiator
environment, let alone a multi-initiator environment.

>>	Can't you assert ATN, transfer 0's until you get a message out,
>>then send ABORT, ABORT_TAG, or TERMINATE_IO_PROCESS?  That at least seems
>>possible...
>
>    We to this for DATA IN at least.  I was kind of in favor of sending 
>out on the bus, "Dump sh*t".  This way the user could "see" what ended
>up on the disk, (but I was out voted in one of our design reviews :-).

	Too bad I wasn't there... ;-)

>    These were choose for being the most useful.  There should be no
>reason why any other CDB can not be added to the list on the Enable LUN.
>The list of "things" to check in the CAM spec is really there to show 
>you what level of checking the SIM should perform.

	Good, that's what I hoped.  This really needs to be made more clear
in the spec, not everyone implementing it will have as good access as I do
to people who were involved in writing it.

>>........  This may seem to be semantic quibbling, but I've had other people
>>tell me they implemented other commands for processor mode, and I was unsure
>>enough I wanted to ask.  Also, it says the invalid ones will be rejected.
>>What about valid CCB's in the same Enable LUN request?  Are they rejected?
>>Are they merely ignored and the Enable LUN rejected?  If the invalid ones are
>>rejected, and the Enable LUN is rejected, and valid ones are not, is there
>>a guarantee that the invalid ones will be rejected before the Enable LUN is
>>rejected?  This is way too fuzzy.
>
>    The enable lun CCB is rejected or accepted as a whole, this includes
>the CCBs that are attached to it, an all or none situation.  If any of
>the CCBs are rejected then the enable lun is failed, along with the CCBs.
>It is up to the peripheral driver to make sure that the enable lun command
>succeeds before it can "use" the CCBs.

	The spec should be updated to say that.  Currently, it says nothing
about the valid ones or the EnableLun itself.  BTW, does "rejecting" here mean
that each and every one of them will be the subject of a callback, or just the
Enable Lun itself?  This also is why it needs to be more clear.

>>>    The processor mode was originaly set to be a "canned" mode.  The

>>	Yes.  So why aren't they supported?  Processor mode allow many
>>more commands than just those 4 (and I still don't see how request sense
>>CCB's work in processor mode).
>
>    The request sense CCB is like an appendix, it does not make a whole
>lot of sense but it has to be there in the event the the "other" system
>should issue a request sense CDB.  At least it can be a was to get general
>status information.

	This should probably be made clear if it's going to be explicitly
mentioned.  Also, if this is the case, shouldn't Request Sense be in the
same catagory as Inquiry?  It's pretty silly to return BUSY for request
sense, especially if this is just meant for "default" sense data (it has to
be "default", since it can't handle I_T_x nexi).

>>>   The phase cognizant mode will really allow you to get down and dirty.

>>	Sort of like the choice between fast food and having to grow your
>>own vegetables and raise your own cows to make hamburger... :-)
>
>    As an OS level person, I tend to "shudder" when I think of trying to
>run phase cognizant mode on one of our disk servers.

	I can relate to that... :-)

>>	How many people have actually implemented this stuff?  I know

>    We will have it as part of our SCSI/NSF failover project, and we
>are using processor mode.  It would be very useful to have an additional
>implementation "note" or something.  There are a number of holes that
>need to be filled.

	Yes, I now have a list of 32 formal questions to submit to the CAM
committee.  You've been quite a help in defining them and pointing out
solutions to some I had missed.  Is this SCSI/NSF project something you
can discuss?  What is it, basically?  VLAN?

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.