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

Internet Message Format | 1992-12-31 | 6.3 KB

Path: sparky!uunet!cbmvax!jesup
From: [e-mail] (Randell Jesup)
Newsgroups: comp.periphs.scsi
Subject: Re: CAM (was Re: Would there be any interest in splitting this group?)
Message-ID: <[e-mail]>
Date: 31 Dec 92 18:47:31 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <37943@cbmvax.
Organization: Commodore, West Chester, PA
Lines: 118

commodore.co <[e-mail]>
Sender:
Reply-To: [e-mail] (Randell Jesup)
Followup-To:
Distribution:
Organization: Commodore, West Chester, PA
Keywords:

[e-mail] writes:
>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 :-)

    Glad you're back.  That's not how I would want to spend the holidays
(or any days, for that matter).

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

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

    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.

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

[processor-mode list of CCB's...]
>>>    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.

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

>>>    The enable lun CCB is rejected or accepted as a whole, this includes

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

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

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

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

--
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
[e-mail]  BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.