>>>>>>>>>>>>>> Begin Original Message <<<<<<<<<<<<<<<<<
>
>From: mondics@tartan.com (Brian R. Mondics)
>
>
>Configuration:
>
> Sun 3/60
> OS - SunOS 4.1.1
> ROM - 1.6
> DISK - CDC Wren 94171-307
>
>Presently I have the machine booting from the Wren-IV off a generic
>kernel and the disk is jumpered as drive #0.
>
>I would like to boot the machine off the same drive, but have the
>drive be another drive number other than 0.
>
>I changed the drive # to a 1 and tried to boot using b sd(0,8,0),
>the result was "Device not found".
>
>How can I get this machine to boot off of the Wren IV at any drive #
>other than 0 ?
>
>Thanks for your help.
>
>Brian R. Mondics
>Tartan Inc. | Fax - (412) 856-3636
>300 Oxford Drive | Tel - (412) 856-3600
>Monroeville, PA 16146 | INTERNET - mondics@tartan.com
>
>>>>>>>>>>>>>> End Original Message <<<<<<<<<<<<<<<<<
This message from Michael Helm appears to be the correct answer.
>From mike@fionn.lbl.gov Thu Oct 31 14:11:09 1991
>
>I'm trying to recall exactly what I learned during
>a similar experiment -- I think the problem turned out
>to be that the 3/60 would only look at sd0, no matter
>what, something in the boot prom forced things to be that
>way.
The problem seems to be related to booting off of anything other
than sd0 when the drive has a embedded controller. I do not have any
non embedded controller so I was unable to verify this.
I must say its quite frustrating getting any support out of Sun
Microsystems regarding Sun3 machines.
Thanks to the following people.
mike@fionn.lbl.gov (Michael Helm)
geertj@ica.philips.nl (Geert Jan de Groot)
"Hilarie Orman" <ho@cs.arizona.edu>
keves@meaddata.com (Brian Keves - Consultant)
John MacAuley <hacksaw@julian.uwo.ca>
Kenton C. Phillips <kenton@space.mit.edu>
kevins%Aus@Sun.COM (Kevin Sheehan {Consulting Poster Child})
jack@devnull.mpd.tandem.com (Jack Bell)
Some people suggested booting from sd(1,0,0), sd(0,1,0), sd(0,2,0),
sd(0,4,0), sd(0,8,0) and sd(0,16,0). I felt there was enough
confusion about what to boot from that I would include the following
information I received from Sun Software support.
THE SCSI CONNECTION -PART I
After several abortive attempts, I have decided to supply this
information in 2 parts. This is not going to be a full technical detailing
of the entire SCSI spec, nor will it include obscure abilities that are
not in use by normally operating Sun systems. The purpose here is to
supply enough information to be able to understand the concepts and be able
to configure a system that has either embedded, non-embedded or both kinds
of controllers in one systems.
When you see sd(0,0,0) or sd(0,18,1) or sd(1,10,0), what do the
numbers really mean?
The first number in the field represents the number of the SCSI host
interface resident on the bus of the system. Currently only two host adapters
are supported in a deskside unit or a rack, while a desktop such as a 3/60
can only have one SCSI host interface. Therefore, on a deskside or a rack
you could see sd(0,x,x) or sd(1,x,x) where the 1 represents the second host
adapter. While on a desktop you would never try to access a SCSI device
with anything but (0,x,x).
The second number represents the TARGET ID number (the number of the
controller), multiplied by the number 8 (for the eight possible devices allowed
by SCSI spec for each target), plus the logical unit number (or LUN of the
device, Sun only recognizes 0 or 1 of the possible 8), and this total is then
written in HEX.
The TARGET ID is the number of either an external type controller,
like the Adaptec or Emulex MD21, or one of the new embedded controllers.
SCSI spec allows eight targets, of these we are concerned with the first
six targets, numbered 0 through 5. 0, 1, 2, and 3, are the targets for
disk drives, while 4 and 5 are reserved for tape devices, which will be
discussed at the end of this explanation.
With an external controller it is possible to have two disks per
target, for a total of 8 disks, although the kernel is only set up for 6.
Each disk is addressed as either 0 or 1 (the LUN) in relation to its
controller.
TABLE 1 - Non-embedded
Target -> 0 1 2 3
/ \ / \ / \ / \
LUN -> 0 1 0 1 0 1 0 1
| | | | | | | |
UNIX sd# -> 0 1 2 3 4 5 6 7
With the new embedded controllers it is only possible to have
one disk per target, and this is always LUN 0 to the target. Therefore,
it is the target ID that is set on the device, and not the LUN of the unit.
Don't confuse target 1 with sd1, target 1 is sd2. Also target 2 is sd4, etc.
With embedded devices there are only 4 disks possible, and as you can
see below there are no odd numbered disks.
TABLE 2 - Embedded
Target -> 0 1 2 3
/ \ / \ / \ / \
LUN -> 0 na 0 na 0 na 0 na na = not allowed
| | | |
UNIX sd# -> 0 2 4 6
Because each target has a possible 8 devices by the SCSI spec,
the actual scsi-number (scsi#) for the first device of each target is
eight greater than the previous one. This is the reason for using the
multiple 8 when finding the central notation in sd(x,x,x). For booting
purposes this number is written in HEX, possibly for ease of implementation
in the boot prom. In the kernel this number is written in decimal form.
I will refer to the decimal as seen in the kernel as the "scsi#", and
the HEX notation that goes in sd(x,X,x) or st(x,X,x) as the "scsi-hex#".
Possibly the following table will help clarify this:
TABLE 3
TARGET ID -> 0 1 2 3 4 5
/ \ / \ / \ / \ / \ / \
LUN -> 0 1 0 1 0 1 0 1 0 na 0 na
| | | | | | | | | |
scsi# -> 0 1 8 9 16 17 24 25 32 40
| | | | | | | | | |
scsi-hex# -> 0 1 8 9 10 11 18 19 20-(0) 28
| | | | | | | | | |
UNIX sd# -> 0 1 2 3 4 5 6 7 st0 st1
The following section from the kernel shows the scsi#'s
in relation to the sd#'s, compare with TABLE 3.
controller si0 at vme24d16 ? csr 0x200000 priority 2 vector siintr 0x40
controller si1 at vme24d16 ? csr 0x204000 priority 2 vector siintr 0x41
tape st0 at si0 drive 32 flags 1
tape st1 at si0 drive 40 flags 1
tape st2 at si1 drive 32 flags 1 <- target 4, host 2
tape st3 at si1 drive 40 flags 1 <- target 5, host 2
disk sd0 at si0 drive 0 flags 0
disk sd1 at si0 drive 1 flags 0
disk sd2 at si0 drive 8 flags 0
disk sd3 at si0 drive 9 flags 0
disk sd4 at si0 drive 16 flags 0
disk sd6 at si0 drive 24 flags 0
Using this scheme we can find out what the middle number of the
sd(x,x,x) notation should be for any device (except for the 4/60 which
makes an adjustment in the NVRAM to fool the system and us).
Using sd6, or LUN 0 at target 3 the problem works as follows:
TARGET ID 3 x 8 = 24 + LUN 0 = 24 in HEX it is 18
Thus we boot the device sd6 as sd(0,18,0)
In order to boot from sd2 it goes as follows:
TARGET ID 1 x 8 = 8 + LUN 0 = 8 in HEX it is 8
Thus we boot sd2 as sd(0,8,0)
The tape drives at targets 4 and 5 are referred to as st0 and st1,
and currently we can only boot from st0. Even though the SCSI number for st0
is 20, and by the rules you should use >b st(0,20,0) to get a " Boot: " prompt
when loading an OS tape, we don't (see TABLE 3). Due to an adjustment in the
boot prom, the tape drive st0 is always seen as st(0,0,0) and we always
start OS tapes with >b st() or st(0,0,0). The unit st1 however, is
called up at the scsi-hex address of st(0,28,x).
The last number in the st or sd(x,x,x) notation refers to a file
or partition respectively. On a tape it refers to the number of the tape
file you wish to access, such as MUNIX at file 5 of an OS tape 1, or of
course the Boot: file which is always file 0. On a disk drive this number
refers to the partition that you wish to access. Partition a = 0, b = 1,
c = 2, d = 3, e = 4, etc. This is why when you load a copy of MINIROOT
into the swap partition b, it goes into (x,x,1).
Just as an example, if you wanted to boot from partition d located
on sd3, the usage would be: >b sd(0,9,3)vmunix
This is the end of PART I. In Part II, I will go through the
various ways our systems now look at the scsi devices, and their relation to
loading the OS and suninstall.
I hope this explaination has helped those of you who were, like
most of us, very confused with all the different numbers being used.
If anyone has any questions, corrections, clarifications, or additions that
they think might be helpful, please email me directly at kenh@quantum, and
I will post an addendum. Congratulations to all who got this far.
Ken Harris (Field Tech Support)
THE SCSI CONNECTION - PART II
This section of SCSI information will be organized into various
sections: termination requirements for various layouts; multi-disk systems
with external, embedded, and mixed controllers using a standard configuration;
and the 3/80 and the 4/330 which use standard nomenclature but have the order
of the disks changed. The 4/60 is a special case and will be discussed in
Part III. I am certain that not every case will be covered, nor will all
of the many questions be answered. Once again I am trying to give a basic,
usable, overview of the situation in hopefully understandable terms.
Some of the configurations described are not considered supported.
Sun at this time does not officially support embedded and non-embedded
devices on the same host. Examples given are only for the purpose of
understanding the layout and addressing schemes. While there may be many
systems you know of with both embedded and non-embedded devices attached,
please remember that this is NOT A SUPPORTED CONFIGURATION at this time,
and may never be. This is for your own information only, do with it what
you want to.
TERMINATION
SCSI bus termination should always go at the end of the bus line.
The numerical order of the controllers is not important as long as the last
one in line on the daisy chain is the one to carry the termination. If an
external plug-in terminator is used, then it is the end of the bus and
there should be no termination on the controller boards, including embedded
disks and any tape drives.
In a 3/160, 3/260, or 4/260 type pedistal the terminators are normally
located on the tape controller, even when the standard (seperate controller)
internal disks are present.
In a shoebox the terminators are on the disk controller, and the
last shoebox carries the termination. If you have a shoebox with two
disks, the command cable is daisy-chained and the end drive has a terminating
resistor pack on its interface card, the first disk should have none. Don't
confuse this with the terminators which may be found on the embedded type
disks as those are for the controllers.
The pbox and the lunchbox have no internal terminators, when they
are at the end of the chain they use a plug-in external terminator.
The 3/80 uses a double ended bus that has internal termination
for the internal drives and requires an external terminator at the end of
the scsi chain when anything external is attached. Also inside the 3/80
the internal termination is of the removable type. Three sips on the cpu were
the original style and were replaced by the large connector insert type that
goes between the first drive and the cpu. It, by the way, goes in with
the large, center, keying slot facing the first drive location, which is the
corner position. One or the other type of internal terminator should be
present, but not both.
The 4/330 has three sips on a board, under the little plate toward
the rear, under the top cover. If an external device is attached, the sips
must be moved to the locations marked storage, and an external terminator
is used on the peripheral.
The 3/470 and 4/370, Rocky desksides, have the termination perminantly
installed on a board at the upper rear of the pedistal. Any external SCSI
devices must be attached between the cpu and and the SCSI tray input or on
a second scsi host adapter.
STANDARD MULTI-DISK SETUP
For the sake of easy reference I am including TABLE 3
from SCSI ADDRESSING PART I below:
TABLE 3
TARGET ID -> 0 1 2 3 4 5
/ \ / \ / \ / \ / \ / \
LUN -> 0 1 0 1 0 1 0 1 0 na 0 na
| | | | | | | | | |
scsi# -> 0 1 8 9 16 17 24 25 32 40
| | | | | | | | | |
scsi-hex# -> 0 1 8 9 10 11 18 19 20-(0) 28
| | | | | | | | | |
UNIX sd# -> 0 1 2 3 4 5 6 7 st0 st1
A 3/160, 3/260, or 4/260 with one or two internal SCSI disks, will
have only one controller for both disks and the disks will be sd0 and sd1.
The newer machines like the 3/470 and the 4/370, which are in the Rocky
Deskside pedistal, can hold up to 4 SCSI devices internally, and are of the
embedded type. It can be two tapes and two disks(st0, st1, sd0, sd2), one
tape and three disks (st0, sd0, sd2, sd4), or four disks (sd0, sd2, sd4, sd6).
EXAMPLE 1:
3/60 with two shoeboxes, one has disk and tape, the other has
two disks. Leave the terminators on the disk controller in the box with
the tape and the controller should be target 0. The controller for the
two disks is target 1 and has termination removed. The box with the
termination goes at the end of the chain.
shoebox shoebox
3/60----------|sd2, sd3|---------|st0, sd0|
| | | |
Target 1 Target 4 Target 0 (terminated)
Notice there is no sd1 in this case because there is physically
no room for the second disk on target 0 in the shoebox because of the tape
drive unit which takes up that space.
This is a standard supported configuration which has been in use
for a long time now, and fairly well understood.
EXAMPLE 2:
4/110 that is tapeless but has a shoebox with two disks, and you
want to add a pbox with a tape and embedded-type disk drive. The existing
shoebox is set up as target 0 and the disks are sd0 and sd1, controller
is terminated. Set the new disk as target 1 and it will be sd2, and put
it between the cpu and the existing disks, no new termination is needed.
The following is NOT A SUPPORTED CONFIGURATION.
pbox shoebox
4/110----------|st0, sd2|--------------|sd0, sd1|
| | | |
Target 4 Target 1 Target 0 (terminated)
Almost all Sun systems follow this basic routine, using the numbers
as shown in Table 3, and arranging them with sd0 as the booting disk and the
rest in ascending order.
This makes suninstall very straight forward.
Miniroot is loaded into swap at sd(0,0,1) and when the disk form
comes up it shows the root disk in the first position on the left as below,
from a 3/470 with three disks.
DISK FORM [DEL=erase one char of input data] [RET=end of input data]
-----------------------------------------------------------------------------
Attached Disk Devices :
[ sd0] [ sd2] [ sd4]
Disk Label : x[edit default] [edit existing]
Free Hog Disk Partition : [d] [e] [f] [g] x[h]
Display Unit : x[Mbytes] [Kbytes] [blocks] [cylinders]
Logic tells you to pick the left most disk first and put root, swap,
and usr there, and perhaps making the other disks one large partition each.
This being done, you select your software and start the installation, and
the install runs to completion.
3/80 AND 4/330 DIFFERENCE
With the 3/80 and the 4/330 there is a twist to this basic setup.
The same numbers are used to reference the devices, but the devices are used
in a different order. Both the 3/80 and the 4/330 see their SCSI devices in
the same way so reference to one includes the other. These machines have
the first internal disk set up as Target 3, sd6, and we are directed to load
the operating system on this disk. A second internal disk will be set up
as Target 1, sd2. Two internal disks is a common configuration, with a tape
drive and possibly more disks externally. The external disks will be set up
using Targets 0 and 2, with possibly two disks per target if shoeboxes are
used (NOT SUPPORTED).
A possible combination could be: A 3/80 with two internal disks, a
shoebox with two disks, and a pbox with tape and disk. There are several
ways to put this together, terminate the controller in the shoebox and put
it at the end of the chain, or use an external terminator and put either of
the units last (NOT SUPPORTED).
4/330
3/80--------------|pbox|----------------|shoebox|
| | |
Target 3(sd6) Target 2(sd4) Target 0(sd0, sd1)
Target 1(sd2) Target 4(st0) (terminated controller
or external plug)
So far so good! The kernel sees all of these devices just the same
as it always has, the targets, the scsi numbers, and the sd's all match the
standard convention shown in Table 3. The difficulty with these two systems
comes with suninstall, which lists disk drives in order of lowest sd# to the
highest sd#. If you had the above situation, suninstall would list the
five drives in order [sd0], [sd1], [sd2], [sd4], and [sd6]. The problem
lies in the fact that with these two systems the OS belongs on sd6 which is
the first internal disk, but it's listed last. Even when there are only
the two internal disks and no others the suninstall confusion persists with
the diskform appearing as follows:
DISK FORM [DEL=erase one char of input data] [RET=end of input data]
-----------------------------------------------------------------------------
Attached Disk Devices :
[ sd2] [ sd6]
Disk Label : x[edit default] [edit existing]
Free Hog Disk Partition : [d] [e] [f] [g] x[h]
Display Unit : x[Mbytes] [Kbytes] [blocks] [cylinders]
You have loaded miniroot to sd(0,18,1) and then booted the system
with Boot: sd(0,18,1)vmunix, as per the installation guide. You start
suninstall, enter the host information, and then go to the disk form (above).
You pick [ sd2] first (which seems logical), and then put the root, swap,
usr, and maybe home partitions there, and then make the next disk, which is
[ sd6], one or two partitions (which many people do), pick your software,
and start the installation. Now you've got problems.
What happens at this point is suninstall re-labels the disks,
then does a "newfs" on the created partitions. When it gets to the area
that was swap on sd6, it writes over miniroot, and the system crashes.
If you then try to re-load miniroot to sd(0,18,1) the system claims that
there is no such device and fails. This is because that partition does
indeed no longer exist. You must now load MUNIX and re-label sd6 so that
it once again has a root and swap area. Then you start all over and try
to run the installation again, making sure that root and swap are on sd6.
This problem stems from several areas of inadequacy.
1) The 4/330 and the 3/80 are the only systems that are different in this
way and it is very easy to get confused or forget.
2) The installation manual states:
"If you are installing a SPARCsystem 300 or a Sun-3/80, your
internal disk device is sd6."
3) The above statement is confusing because you may have several internal
disk devices, and it is not true for a 4/370 which uses sd0 as the
first internal disk. The 4/330 and 4/370 are identical cpu's, why the
difference?
4) Where the installation manual discusses changing the size of partitions
it makes the following statement:
"If changes are required, the first three partitions on the disk
must be labeled using the format program. This is necessary for the
first disk (disk0) only. As the root and swap partitions reside on
the first disk (disk0), the remaining disks (disk1,...) are available
for other purposes and therefore not affected by this restriction.
The sizes of partitions "a" and "b" can be changed in suninstall on
all disks other than disk0."
5) Suninstall will not allow the size of root to be changed, nor will it
allow the size of swap to be decreased, so long as they reside on sd0.
This is a fail-safe to keep miniroot from being destroyed during the
installation.
THIS HAS BEEN DEFEATED ON THE 4/330 AND 3/80.
On these two machines root and swap are put on sd6 where suninstall can't
stop those partitions from being altered, thus killing the installation.
So remember, pick the second disk first and the first disk second,
except on the second Thursday of the third month of every other odd year.
I sincerely apologize for the length of this paper. I tried to
address the issues as briefly as I could and still get the points across.
Once again, congratulations to all who managed to get this far. Please
don't expect an explanation of the 4/60 until after the first of the year.
Ken Harris (Field Tech Support)
>From kenh@EBay Tue Jan 9 17:21:54 1990
To: crosstalk@caladan.EBay, tstech@Sun.COM
Subject: SCSI III - The 4/60
THE 4/60 SCSI LAYOUT
This will be short and to the point. In a nutshell the 4/60 is
unlike any other Sun product in the way that it looks at the scsi devices.
Do not try to compare the 4/60 SCSI structure to other systems or use the
standard mapping sequence on it.
4/60 ALL OTHERS
Target 0 = sd3 bsd(0,3,0) Target 0 = sd0 bsd(0,0,0)
Target 1 = sd1 bsd(0,1,0) Target 1 = sd2 bsd(0,8,0)
Target 2 = sd2 bsd(0,2,0) Target 2 = sd4 bsd(0,10,0)
Target 3 = sd0 bsd(0,0,0) Target 3 = sd6 bsd(0,18,0)
Please refer to Table 3 in SCSI
PARTS I & II for an explanation
of the above layout.
The 4/60 Target vs. sd# relationship is set up in the NVRAM under
the parameter sd-targets. It reads sd-targets 31204567. The relationship
follows through in the kernel:
scsibus0 at esp # declare first scsi bus
disk sd0 at scsibus0 target 3 lun 0 # first hard SCSI disk
disk sd1 at scsibus0 target 1 lun 0 # second hard SCSI disk
disk sd2 at scsibus0 target 2 lun 0 # third hard SCSI disk
disk sd3 at scsibus0 target 0 lun 0 # fourth hard SCSI disk
tape st0 at scsibus0 target 4 lun 0 # first SCSI tape
tape st1 at scsibus0 target 5 lun 0 # second SCSI tape
If you are attaching a Pbox or a Shoebox to a 4/60 and that device
is addressed as Target 0, it will come up on the system as sd3. The fact
that it is addressed as Target 0 will not interfere with the sd0 inside the
machine because it is actually Target 3. Confused? You're not alone.
Just remember the first internal disk is Target 3 but is called sd0,
and it boots sd(0,0,0). If there is only an external disk and it is set up
as Target 0, the system sees it as sd3 and it boots as sd(0,3,0).
Ken Harris (Field Tech Support)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:17 CDT