NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/periphs/scsi/6285

Internet Message Format | 1992-12-30 | 5.9 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!spool.mu.edu!hri.com!noc.near.net!mv!chillon!decvax.dec.com!decvax.DEC.COM!jag
From: [e-mail] (John A. Gallant UEG)
Newsgroups: comp.periphs.scsi
Subject: Re: CAM (was Re: Would there be any interest in splitting this group?)
Message-ID: <[e-mail]>
Date: 30 Dec 92 17:38:29 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]
Sender: [e-mail] (Usenet News System)
Reply-To: [e-mail]
Organization: OSF Engineering, Digital Equipment Corp.
Lines: 99
Nntp-Posting-Host: witsend.zk3.dec.com

Well I am back, after an emergency appendectomy.  This was no way to spend
two weeks around the Holidays!  I did get a chance to play a lot of my
kids S-Nintendo game :-)

In article <[e-mail]>, [e-mail] (Randell Jesup) writes:
>[e-mail] writes:
>>    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.

    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.

>>    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.

    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.

>>    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.  .........................

    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.

>    .......................................  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.

    From the KISS method, it should only have to be the original Enable LUN
CCB.

>>    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).

    Sorry, I don't understand ?

>    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?

    In trying to dig out from under my mail and Usenet folders I "saw" your
mail, I have not had the opportunity to read it and study it.  I hope to
within the next couple of working days.

--
John A. Gallant                                [e-mail]
Software Engineer - OSF Engineering Group
Digital Equipment Corp. [phone]

        In the common people there is no wisdom, no penetration, no
        power of judgment.
    Marcus Cicero