Subject: Re: quick patch for LUNs on SCSI-I devices
To: Jason Thorpe <>
From: Justin T. Gibbs <>
List: tech-kern
Date: 09/02/1996 12:41:12
>[ Taking this from private mail to tech-kern... ]
>On Mon, 02 Sep 1996 08:27:10 -0700 
> "Justin T. Gibbs" <> wrote:
> > But NetBSD always probes for multiple LUNs right?  I thought of this too,
> > in that you may be able to "clone" the version from LUN 0 before probing
> > the higher luns so you never set it incorrectly, but I think you might
> > lose on SCSI->SCSI or SCSI->ESDI bridges.
>No ... In the case where the device is "ancient", (i.e. version & 
>SID_ANSII == 0), LUNs are not checked, or in the case where a NOLUNS 
>quirk exists for the device.  In the case of ancient devices that _do_ 
>have working LUN support (i.e. the Emulex MD21), we have a FORECELUNS quirk.

Exactly.  So, the behavior now is to send the lun information to SCSI II
devices until we know that they are in fact SCSI II devices.  Hopefully
this doesn't break any SCSI II devices.

>Note that in the current model, the LUN won't get set on the first try of 
>the device, which will be LUN 0 ... unless the user explicitly 
>confgigured a device at lun 1 or something ...

It will get set, it will just be 0.

>The cases where it breaks are a direct result of scsi_link not being 
>right in our autoconfiguration model; it attempts to squish the target 
>layer and lun layer (and, in some cases, the adapter layer!) all into 
>I'm working on some changes to the SCSI code which will solve the 
>maxtarget and the above lun problem in one fell-swoop, in a nice 
>(somewhat BSDI-like) manner... essentally, the device tree will look like:
>ahc* at pci? dev ? function ?
>scsibus* at ahc? channel ?
>tg* at scsibus* target ?
>sd* at tg? lun ?
>st* at tg? lun ?
>cd* at tg? lun ?
>ch* at tg? lun ?
>ss* at tg? lun ?
>uk* at tg? lun ?
>(Note, this is how the SCSI bus is logically arraned anyhow :-)
>Solves maxtarget, because then our autoconfig code does all the dynamic 
>allocation, and it's layered properly.  Solves the LUN problem because 
>when tg? is attached, only lun 0 will be checked for device existence, 
>and the correct SCSI version will be known for the later device at lun ? 

Hmm.  I wonder how SCSI->SCSI and SCSI->ESDI bridges will handle setting
the LUN in the CDB.  Hopefully it gets striped before getting sent to the
final device.

You still need to have the adapter export its maxtarget and maxlun
information in its attach args to the scsibus.  SCSI-III allows up
to 64bits for the target ID, LUN, and tag identifier with each
specific bus implmentation defining its own upper bounds <= 64.
In the code on my machine, this information is stored in the

 * The adapter_link connects an adapter to a particular bus.
struct scsi_adapter_link
        struct  scsi_adapter *adpt_switch;  
        void    *adpt_softc; 
        int     adpt_unit;              /* XXX should be provided by config */
        int     adpt_flags;  
#define         SADPT_BOUNCE            0x01    /* needs DMA bounce buffer */
#define         SADPT_TARGET_OPS        0x02    /* Supports target ops  */
        int     adpt_channel;  
        int     adpt_target;  
        int     adpt_maxtarget;  
        int     adpt_maxlun;  
        int     adpt_openings;  
        int     adpt_tagged_openings;  

> -- save the ancient forests - -- 
>Jason R. Thorpe                             
>NASA Ames Research Center                               Home: 408.866.1912
>NAS: M/S 258-6                                          Work: 415.604.0935
>Moffett Field, CA 94035                                Pager: 415.428.6939

Justin T. Gibbs
  FreeBSD: Turning PCs into workstations