Summary: scsi drive params in config file

Date: Thu Apr 02 1992 - 11:43:18 CST

I asked,

> [We've] all seen, I presume, scsi device configuration lines like
> the following from the SunOS kernel config file. Now, can someone
> tell me what the exact correlation is between the 3-digit "drive"
> parameter and the scsi unit number?
> ]tape st0 at sc0 drive 040 flags 1
> ]disk sd0 at sc0 drive 000 flags 0
> ]disk sd1 at sc0 drive 001 flags 0

I got responses from: (Keith F. Pilotti) (Scott Butler)
mks! (Andy Toy) (Matt Goheen) (Daniel Trinkle) (John Valdes) (Russ Poffenberger) (Mike Smith) (Fabrice Le Metayer)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)

John's, which follows, is probably the most succinct. The key to the least
significant digit is to recall (or learn!) that scsi disks can have "logical
unit numbers" that subdivide devices within one scsi id (which Sun calls

>The initial zero in 0nn is to signify that this is an octal constant. The
>second digit is indeed the scsi id of the device. The third digit is for
>the logical unit number. This is used only with disks without an embedded scsi
>controller. An example is the Emulex EDSI->SCSI adapter found on SCSI based
>3/160's (among others), to which one can attach two EDSI disks. In this case,
>the scsi id is that of the adapter, and the lun 0 and 1 correspond to the
>first and second drive attached to the adapter, respectively. All scsi disks
>nowadays come with their own scsi controller, so lun will always be 0 for
>these. For the flags field, a 0 indicates a disk device, a 1 indicates a
>tape device (a 2 indicates a CD-ROM drive). These specification lines are
>different for desktop sparcs, BTW (eg., SS1, SS1+, SS2). See sd(4), st(4),
>and sr(4) man pages for more info.

Scott adds,

>Most devices today have embedded SCSI controlers and only support one
>device at for each SCCI id. However I have a shoebox with two drives
>in it using an Emulex MD-21 controller. One is at logical unit 0, the
>other at logical unit 1. Both use the same SCSI controller.

I thus presume that the pre-coded drives 001 and 011 in the config file are
hold-overs (hangovers?) from 3/160 or similar setups (as Russ says, "from
the stone age, when non-embedded devices roamed the earth"), and that
sd1, sd3, etc can be reassigned to other scsi id's (with luns 0). I'll be
trying that within a week.

Andy quotes from the st man page (Aha! That's the relevant doc, along with
the pages for sd and sr) which describes the flags bitmap, at least for st
(tape) devices:

Bit 0 ...the device does NOT support disconnect/reconnect.
Bit 1 ...the driver should negotiate ... for synchronous SCSI transfers.
Bit 2 ...the device does NOT support parity.
Bit 3 ...standard commands that are going to transfer a small amount of data
         can, if nothing else is active, avoid doing a disconnect.
Bit 4 ...the device supports multiple luns active simultaneously.
Bit 5 ...the device supports only simple (COMMAND_COMPLETE) SCSI messages.
Bit 6 ...commands combining optimizations can be performed.

On the other hand, as Matt says:

>The flags field is passed to the SCSI driver on boot up. The sd(4) and
>st(4) pages explicitly state that a 0 means this is a SCSI disk device
>and that a 1 means that it is a SCSI tape device.

Fabrice Le Metayer forwarded a compilation that came through sun-managers
on a previous similar question (which I must have missed, sorry), which
included the note:

>The flags entry is actually an index into a table for the proper device
>subroutines. 0 is for disk, 1 for tapes, 2 for CD, &c.

And it was mentioned that the "Guide to writing a device driver" should be
consulted along with the sd/st/sr man pages.

Thanks very much to all who responded, this is a great help. If I get
more responses yet, I'll post an update only if there's something really
new and interesting.

I will keep all the responses around for a while in case anyone wants to
e-mail me for the uneditted lot.

Chip Campbell

Sunnybrook Health Science Centre (University of Toronto)
Toronto, Ontario, Canada

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:40 CDT