From: jag@decvax.DEC.COM (John A. Gallant UEG)
Subject: Re: CAM (was Re: Would there be any interest in splitting this group?)
Reply-To: jag@zk3.dec.com
Organization: OSF Engineering, Digital Equipment Corp.
Date: Mon, 4 Jan 1993 19:02:34 GMT

In article <38228@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
>jag@zk3.dec.com writes:

>>    All of the disk devices that we know about will complete the current
>>sector and then enter the Unit Attention condition.  This way the drivers
>>on the systems, single or multi-initiator can recover or terminate their
>>current I/O.  At least from one point of view, a companies liability
>>paranoia, it is not the system software that is corrupting the media.
>
>	A multi-initiator system may well not recover from that.  Since the
>other initiators are of course disconnected, they will not normally notice
>the unit attention condition, they'll merely wait for the target to reselect
>them (which it won't).  I'm not sure you can count on all initiators being
>able to notice a hard-reset, and I'm pretty certain you can't count on
>most initiators to handle error recovery from it.

    There has to be a different set of criterion for systems, both in 
hardware and software, if they wish to play in a multi-initiator
environment.  It is my opinion that an off the shelf $15 adaptor card
does not have a prayer of working in a multi-initiator environment.
There is a *LOT* of work that has to go into the support of multi-initiator.
One of the minimums is dealing with hard resets.  A system has to make the
assumption that one of the other systems can have a problem and will have
to make use of the big RED switch on the side of the bus.  In CAM there
was the entire async-callback sequence that allowed the peripheral
device drivers to be notified for things just like RESET.

>	If a device active but disconnected was a non-direct access device,
>the IO may be impossible to recover.

    The system software may be able to recover the I/O, but for worst case
the I/O can be terminated and returned to the user.

>>    Well, I hope at least, that we - (who worked on it) can continue to
>>be accessable on the network and the BBS.  It is very unfortunate that the
>>target mode sections, and the HBA engine sections did not get the level 
>>of involvement that the other section went through.
>
>	I've gotten mail from one of the original target mode guys (the
>person who was pushing phase-cog mode), and he thought that ONLY those
>requests were allowed.  As I said before, this obviously isn't clear as it
>stands.  Perhaps this can be handled as a request for interpretation...

    Mike's stuff really only dealt with the phase-cog mode.  His original
work included the description and overview.  The processor mode was 
kind of shoe-horned in, with not as much work and forethought as Mike's.
Heck, Mike even has/(had) a real product using it, and the processor mode
was all paper.  There are many holes that people are finding by looking
at the spec.  The stuff that you, I, and Usenet etal are slinging
back and forth, is a prime example of what one finds when you look
under the hood.

>>    The spec at this point is not changeable, the public review and the
>>following voting period is not a trivial process.  To change even a word
>>in the spec would involve another N months of "process".  From my
>>perspective I would rather have the spec a reality, with it's flaws, rather
>>than still having it bouncing in and out of the committee.  The 
>>SCSI-2 spec had similar problems and this is one of the reasons that
>>it has been "delayed" over a year.
>
>	I was afraid of that.  I agree I'd rather have a spec than none,
>but I'm getting the feeling that the spec is, shall we say, not quite ready -
>especially when it comes to target processor mode (phase-cog seems to be
>in better shape, if for no other reason other than it defers everything to
>the driver).

    At the time of spec there was only one vendor that was using any
of the target mode(s), and this was an *internal* effort.  Perhaps 
the CAM working group can take some time during the work on the next 
generation CAM spec to produce a TIB using the input from the companies
that are attempting to implement these modes.  Your work in this 
direction is a great base to start with.

>	Excluding processor-mode, it has some flaws but most are merely
>vagueness or lack of clarity (other than that address sizes should be OSD,
>not fixed at 4 bytes).

    The 32/64/128/... pointer size issue was one that was fixed very
early on.  The primary members of the CAM committee were the DOS/adaptor
vendors, and at the time 64 bits was not a reality.  Those of us who
had 64's comming down the pike realized that we would have to deal 
with it at a source level and plan on working on it within the next
CAM spec.  There was the goal that the CCB would look the same across
the OSD's.  Especially with U*nx running in the PC hardware space this
was a goal worth keeping.

>>    Sorry, I don't understand ?
>
>	By your interpretation, if a request sense command comes in, and the
>SIM has no internal sense stored for that initiator, it uses the request
>sense CCB handed in with Enable LUN.  If, before the driver makes the
>request sense CCB available again, another request sense (from any initiator)
>comes in, the SIM will have to return BUSY.  While legal, I think it's best
>to avoid returning busy to request sense where possible.  In fact, there's
>no need for request sense at all here - it must be default (no error) data,
>since there's no way to associate it with an I_T_x nexus, in which case the
>SIM could handle it perfectly easily itself (it already has to store and
>return sense data for initiators anyways).

    This is possible, but I would like to keep the SIM out of the loop, WRT
dealing with creating any CCB data, unless it has to.  I can see where
the other initiator can re-issue the REQUEST SENSE on a busy condition
with the knowledge that is the behavior.  On the flip side why is the
other initiator sending a REQUEST SENSE CDB out of the blue anyway ?
Any REQUEST SENSE CDBs should idealy be part of any HBA or CAM autosense
functionality.

-- 
John A. Gallant                                jag@zk3.dec.com
Software Engineer - OSF Engineering Group
Digital Equipment Corp. (603) 881-2472

        In the common people there is no wisdom, no penetration, no
        power of judgment.
    Marcus Cicero
Newsgroups: comp.periphs.scsi