System Probing with SCC lun devices

James Smart USG smart at
Sun Jan 5 06:28:59 PST 1997

* From the SCSI Reflector (scsi at, posted by:
* James Smart USG <smart at>

Hi Larry,

In your first message you pushed the point that you had to have
an SCC host driver present and that it had to be used cooperatively
with the probe mechanism. I simply noted that there was no need to
have separate components to do this.

This is not to say that your probe mechanism must not be scsi I/II/III
and command set (device type) aware. In this point we agree, as your
last message indicates. In the pursuit of minimizing the amount of awareness
in the probe element, I fully support the move of the Report Luns command
into SPC as per recent conversations on the scsi reflector.

My response also noted another concern in this area, namely devices that
have some SCSI-3ness integrated into them (e.g. they support some SCSI-3
commands, etc), but for compapatibility reasons report themselves as SCSI-2
in their Inquiry data (even when the device is on a SCSI-3 only medium).
Such cases have the potential of defeating the "awareness" rules being
implemented in the probe element and possibly the peripheral drivers as well.

-- James

>Date: Fri,  3 Jan 97 13:53:31 PST
>From: Larry Chen <larryc at>
>Subject: Re: System Probing with SCC lun devices 
>To: James Smart USG <smart at>
>Cc: serial_solutions at, scsi at
>Hi James,
>Thanks for your reply. I have added additional comments
>On Fri, 3 Jan 1997 16:21:38 -0500  James Smart USG wrote:
>>Hi Larry,
>>You don't have to be a SCC peripheral driver to send
>>a Report Luns command.
>Reality check. The Report Luns command is mandatory
>only for the SCC device type. I don't think it is common
>practice to issue unsupported SCSI commands during 
>System probing. The Lowest Common Denominator (lcd) approach 
>is "commonly" followed (in order to support all the
>various peripheral device types and all SCSI I, II, and III levels).
>The safest (i.e. lcd) approach would be something like the
>After a first stage probe (i.e., say 0-63 luns), the second 
>stage probe could send the Report Luns command to only the 
>SCC luns in order to finish populating the CAM edt. That
>why I originally stated the SCC driver had to be part
>of the configuration driver - because the second stage probe
>is SCC aware.
>Bye for now.
>>In most cases, the probing element is
>>independent from the peripheral drivers (so that the appropriate
>>drives can thereafter attach to the appropriate device that's
>>known to be in existence) or each peripheral driver is told to
>>look at the device and see if it recognizes the device. 
>>As such, the probing element can pick and choose the commands
>>used to complete the probe.
>>So, using Report Luns seems reasonable to me. I do wonder if there's
>>a better way than trial and error to determine when it's best to
>>use Report Luns. The basic assumption being that Report Luns is only
>>present on a SCSI-3 device. If Lun 0 returns a type indicating SCSI-2
>>(which also means it may not indicate an SCC device type) what's the
>>best method to continue probing with ?
>>-- James
>>------- Begin Forwarded Message
>>Date: Fri,  3 Jan 97 12:19:09 PST
>>From: Larry Chen <larryc at>
>>Subject: System Probing with SCC lun devices
>>To: scsi at, serial_solutions at
>>Sender: owner-serial_solutions
>>* From the serial_solutions Reflector, posted by:
>>* Larry Chen <larryc at>
>>* To post to this Reflector, send email addressed to serial_solutions at
>>In a typical System probing methodology, the
>>configuration driver must probe for luns and populate
>>the equipment device table (edt in CAM terminology)
>>before any of the other peripheral device drivers are 
>>It has been suggested that the Report Luns command
>>can be issued to SCC lun to determine the
>>the other non-SSC lun(s) that are behind the array
>>controller device.
>>If this is the case, the SCC host driver must now be
>>part of the configuration driver. The SCC host driver
>>must issue a Report Luns command and populate the
>>equipment device table (edt in Cam terminology) before
>>any of the Non-SCC drivers are initialized (and claim
>>their luns).
>>Is this an acceptable System probing methodology for
>>the System folks?
>>Larry Chen                 Tel: 408.383.1600 (x116)
>>Maximum Strategy, Inc.     Fax: 408.383.1616
>>801 Buckeye Court       E-mail: larryc at
>>Milpitas, CA 95035
>>------- End Forwarded Message
>>James Smart                                            email: smart at
>>Alpha UNIX Systems - Digital Equipment Corp.           Phone: 603-881-2472
>>110 Spit Brook Road,    Nashua, NH  03060              Fax  : 603-881-2257
>>Disclaimer: My statements and opinions reflect my own thinking and are not
>>   necessarily reflective of any employer or association.
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at

More information about the T10 mailing list