Sorry this summary is so late in coming.
>We have an old Sun 3/50 diskless machine that we would like to add a new disk
>to it. We have a 6 month old Sun SLC with a SUN0207 scsi disk that we would
>like to replace with a bigger disk then move the smaller disk to the Sun 3/50.
>
>I connected the SUN0207 scsi disk to the diskless 3/50 using an adapter
>scsi cable and powered on.
>Name: SCSI 1 to SCSI 2 Connector Cable
>Order #: X931H
>Price: $155
>
>I am running a SunOS 4.0.3 generic kernal for the Sun 3/50 and it does not
>seem to be able to access the disk.
>
>On boot up I do not get any error messages.
>
>The /dev/*sd* entries are all there so makedev sd is not necessary.
>
>When I do the following command
># mount /dev/sd0a /mnt
>mount: /dev/sd0a on /mnt: No such device or address
>mount: giving up on:
> /mnt
>
>I have try various device names sd1a, sd2a, ... but nothing I do seems to make
>it access the disk. I have tried changing the number switch setting on the
>back of this disk. What exactly is this number mean and how is it used?
>
>The hardware people at Sun say it can not be done because the firmware of
>the Sun 3/50 and its old host adapter can not handle these newer disks. Could
>anyone out there confirm or unconfirm this. Sun has always given us great
>support but there have been several occasions where they said a particular
>problem could not be solved but was solved later by someone on the net.
>
>Also if anyone has any ideas on how to get around this I would appreciate an
>answer.
>
There were several responses but no working solution. The end result is
management has decided to upgrade the Sun 3/50 to a Sun ELC which will work
with the Sun207 hard disk. This solution is probably better in the long-run
and Sun is giving a great upgrade price. Yes we checked with several
third-party vendors and the saving was insignificant plus the Sun warranty
was the deciding factor. Sorry that this is not a desirable solution for
those of you on a strict budget.
Thanks to all the following who responded.
jason@tfs.COM
scs@wotan.iti.org
>From brent@napa.Telebit.COM Thu Oct 17 11:24:23 1991
>From mcostel@kaman.com Thu Oct 17 11:03:22 1991
>From kevins@Aus.Sun.COM Wed Oct 16 23:52:57 1991
>From deltam!tigger!jt@uunet.UU.NET Wed Oct 16 22:16:47 1991
>From geertj@ica.philips.nl Wed Oct 16 18:41:47 1991
>From zrfp0406@awssn3.rus.uni-stuttgart.de Wed Oct 16 14:22:22 1991
>From geertj@ica.philips.nl Tue Oct 15 16:54:38 1991
>From jim@math.psu.edu Tue Oct 15 16:47:33 1991
>From mikem@juliet.ll.mit.edu Tue Oct 15 16:40:20 1991
>From pam@fimad1.lanl.gov Tue Oct 15 16:38:01 1991
Included are the individual responses, slightly editted.
Thanks again.
p.s. Some people actually responded to my signature saying to the effect
that 'Capitalism with ANY ethics ...'. Well TRUE capitalists are
honest and ethical (a rare bunch). Those that are dishonest or
unethical are really crooks! Hopefully one day environmental crimes
will be dealt with the same or better than today's criminal offenses.
Robert J Wolf, Sun System Admin. DCIEM, CFB Toronto
rwolf@dciem.dnd.ca PO Box 2000 1133 Sheppard Avenue West
uunet!csri.toronto.edu!dciem!rwolf North York (Toronto), Ont., Canada M3M 3B9
Internet: 192.16.207.3 Phone: (416)635-2073 FAX: (416)635-2104
"Capitalism with environmental ethics will benefit the entire world."
-----------------------------------------------------------------------------
>From jason@tfs.COM Tue Oct 15 15:54:55 1991
The first think to check is that the scsi id of the disk is matched to
an id configured in your kernel.
The scsi id is the slave number divided by 8.
-----------------------------------------------------------------------------
>From scs@wotan.iti.org Tue Oct 15 16:37:31 1991
You might carefully check the SCSI address on the disk itself. I believe
that internal disks on an IPC use a weird address like 6. If so, the 3/50
would never see it.
-----------------------------------------------------------------------------
>From pam@fimad1.lanl.gov Tue Oct 15 16:38:01 1991
Perhaps it's the OS level that you have running on your 3/50. I seem
to recall that some of the newer disks were not supported until 4.1.
Pat Max
Los Alamos National Laboratory
pam@lanl.gov
-----------------------------------------------------------------------------
>From mikem@juliet.ll.mit.edu Tue Oct 15 16:40:20 1991
First of all, if the disk was "sd0" on your SLC, then it's jumpered to have
a SCSI ID of 3, and would be known as "sd6" on your 3/50, according to the
config file of a generic 4.0.3 kernel.
(No, it's not intuitive, I know. just trust me on this.)
Second, the Sun engineers may be right, depending on the disk drive. All of
the newer SCSI disks that Sun is delivering are capable of synchronous SCSI.
What normally happens is when your 3/50 tries to establish a connection with
the disk, the disk's SCSI controller offers to communicate synchronously.
The "si" controller in the 3/50 doesn't understand the signals which make up
the synchronous-communication offer, and the two devices get confused and
never even manage to set up a proper asynchronous dialog.
Some disks have a feature which allows you to manually disable the synchronous
SCSI negotiation phase, so the disk will *always* talk asynchronously. I do
not know if this is the case with your particular disk; if it's a Quantum, I
believe you're out of luck. Best bet is to talk directly with the disk
manufacturer; find the nearest technical service representative and ask if
it's possible to disable synchronous scsi on this drive.
If you *can* disable the synchronous negotiation phase, and if you change the
scsi id on your disk, you should be able to use this disk on your 3/50.
Michael Maciolek mikem@juliet.ll.mit.edu (617) 981-3174
Network Engineer --- MIT Lincoln Laboratory Group 43 --- Weather Sensing
------------------------------------------------------------------------------
>From jim@math.psu.edu Tue Oct 15 16:47:33 1991
The Sun folks are correct -- the old ROMs and SCSI host adapter can't talk
to the newer disks.
By the way, this is probably not a question to be asked on this list.
Sun-Nets is devoted to Sun networking issues only.
Jim
Jim Duncan <jim@math.psu.edu> Penn State Math Dept Systems Administrator
"[A computer is] like an Old Testament god, with a lot of rules and no mercy."
Joseph Campbell
-----------------------------------------------------------------------------
>From geertj@ica.philips.nl Tue Oct 15 16:54:38 1991
First off, your question is on the wrong list, this is the sun-NETS list
and one would expect networking issues here..
Having said that, could you check on the following things:
- SCSI termination
- What messages come from the auto-config part of the kernel during
boot-up? (zs0 on obio blah blah..)
- What SCSI ID does the drive have
- Check if pin 26 on the 3/50 SCSI bus isn't connected to ground
(but if I remember correct, this is a 3/60 and 4/110 layout problem)
- Are you using the generic kernel?
Hope this helps,
Geert Jan
-----------------------------------------------------------------------------
>From zrfp0406@awssn3.rus.uni-stuttgart.de Wed Oct 16 14:22:22 1991
May be the disk is set to an SCSI address
which is not configured in your kernel.
It could be a good idea to check with 'format' which disks are found.
Another possible reason could be wrong SCSI bus termination.
>The hardware people at Sun say it can not be done because the firmware of
>the Sun 3/50 and its old host adapter can not handle these newer disks.
I am not shure, but I don't believe that.
Dr.-Ing. Joerg Hertzer
Computer Center University Stuttgart
Allmandring 30
W-7000 Stuttgart 80
Germany
Phone: ++49-711-685-5803
Fax: ++49-711-682357
E-Mail: Joerg.Hertzer@rus.uni-stuttgart.de (preferred)
S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de
ZRFP@DS0RUS1I.bitnet
-----------------------------------------------------------------------------
>From geertj@ica.philips.nl Wed Oct 16 18:41:47 1991
A disk not seen in the motd file is not recognized by the SCSI driver
and thus not accessible, no need to try it.
A disk should be recognized if it has SCSI ID 0,1,2 or 3, according to
the motd (the slave number divided by 8 is the SCSI ID).
It also follows that the disk should be connected during boot-up.
I remember some weirdness regarding SCSI availability during power-on
diagnostics: have you tried switching off the 3/50 while leaving the disk on?
You can check the SCSI-ID of the disk by:
- connect it to the SLC
- get to new-command mode (n command)
- enter 'probe-scsi' and watch what happens.
You should set the SCSI ID to 0. Possibly you only have to switch the
number at the back to 0. Try SCSI ID 3 too.
You have to reboot after each try. As long as the kernel doesn't find the
disk during boot-up, it's no use trying to access it.
Hope this helps,
Geert Jan
-----------------------------------------------------------------------------
>From deltam!tigger!jt@uunet.UU.NET Wed Oct 16 22:16:47 1991
Somehow I find Sun telling you you can't use a certain disk because the host adapter can't handle it, somewhat of a farce.
The number settings on the back of of the drive are to identify the drive to the computer.
What it sounds like to me is you want to run the 3/50 diskless, add the disk on for you own files. If you are doing this do the following set the ID indicator to 0. Bring up Sun's format program, to see if the Disk is recognized by the computer. If the formatter found the drive, you may want to format the drive.
WARNING: MAKE SURE YOU HAVE BACKED UP ALL YOUR INFORMATION THAT YOU WANTED FOR YOUR SLC BEFORE FORMATTING THE DISK DRIVE.
What it sounds like to me is that the disk drive still has the data from the SLC on it. Sun3's and SLC don't have the same CPU architecture. Format the drive and create a new file system on each of the disk partitions you want to use.
If this doesn't work...... well maybe Sun was right.
Jim Wills, Systems Administrator
Delta Microsystems, Inc. Voice (510) 449-6881
111-C Lindbergh Ave. Fax (510) 449-6885
Livermore, Ca. 94550 Email jwills@deltam.com
Hardware, n.:
The parts of a computer system that can be kicked.
-----------------------------------------------------------------------------
>From kevins@Aus.Sun.COM Wed Oct 16 23:52:57 1991
The number is the target ID on the SCSI bus. For the sun4c machines, they
set the target ID to 3 for sd0 (compatibility, don't ask :-) generally.
The "drive number" in a config line is 8*target_ID + lun - so ID 0
would be:
disk sdN at si0 drive 000 flags 0
ID 1 would be:
disk sdN at si0 drive 010 flags 0
ID 6 is:
disk sdN at si0 drive 060 flags 0
The driver number above is in octal to make it easier, and the relationship
between N and the ID is arbitrary.
>
> Oct 11 13:35:38 sleepy vmunix: st0 at si0 slave 32
ID 4 is the tape...
> Oct 11 13:35:38 sleepy vmunix: st1 at si0 slave 40
ID 5 is another tape.
> Oct 11 13:35:38 sleepy vmunix: sd0 at si0 slave 0
sd0 is target 0, lun 0
> Oct 11 13:35:38 sleepy vmunix: sd1 at si0 slave 1
sd1 is target 0, lun 1 (second disk in a shoebox)
> Oct 11 13:35:38 sleepy vmunix: sd2 at si0 slave 8
sd2 is target 1, lun 0
> Oct 11 13:35:38 sleepy vmunix: sd3 at si0 slave 9
> Oct 11 13:35:38 sleepy vmunix: sd4 at si0 slave 16
> Oct 11 13:35:38 sleepy vmunix: sd6 at si0 slave 24
> Oct 11 13:35:38 sleepy vmunix: zs0 at obio 0x20000 pri 3
> Oct 11 13:35:38 sleepy vmunix: zs1 at obio 0x0 pri 3
> Oct 11 13:35:38 sleepy vmunix: le0 at obio 0x120000 pri 3
> Oct 11 13:35:38 sleepy vmunix: bwtwo0 at obmem 0x100000 pri 4
> Oct 11 13:35:38 sleepy vmunix: bwtwo0: resolution 1152 x 900
> Oct 11 13:35:38 sleepy vmunix: hostname: sleepy
> Oct 11 13:35:38 sleepy vmunix: domainname: dretor
> Oct 11 13:35:38 sleepy vmunix: root on dretor:/export/root/sleepy fstype nfs
> Oct 11 13:35:38 sleepy vmunix: swap on dretor:/export/swap/sleepy fstype nfs size 12288K
> Oct 11 13:35:38 sleepy vmunix: dump on dretor:/export/swap/sleepy fstype nfs
>
> The hardware people at Sun say it can not be done because the firmware of
> the Sun 3/50 and its old host adapter can not handle these newer disks. Could
> anyone out there confirm or unconfirm this. Sun has always given us great
> support but there have been several occasions where they said a particular
> problem could not be solved but was solved later by someone on the net.
That's what hardware people get for commenting on software :-) They may
be correct that the 3/50 boot proms can't handle this particular disk,
Two things come to mind as to problem:
1) make sure target ID and one of the entries match - you should probably
pick 0 and 000 just to make sure.
2) make sure that pin 26 of the disk SCSI interface is *NOT* TERMPWR. The
3/50 and 3/60 ground that pin, which is a Bad Thing for newer disks. (The
3/50 was designed before SCSI made that decision) Easiest way to fix it
is to scratch pin 26 on the board, or from the cable.
l & h,
kev
Kevin Sheehan
Optimation Software Engineering
kevin.sheehan@fourx.aus.sun.com
-----------------------------------------------------------------------------
>From mcostel@kaman.com Thu Oct 17 11:03:22 1991
I recently added a 424MB disk to a Sun 3/60. I had a similar experience
to yours because the disk would not start. I needed to change a jumper
on the disk controller so that the drive would start when powered up
rather than waiting for a SCSI command. Sorry I can't be more specific,
but I don't have a SUN0207 SCSI disk here.
If you are interested in doing this with more of your 3/50s, we resell
Sun and 3rd party equipment. I could purchase the SUN0207 scsi disks,
do the integration, and sell you the complete package.
Mark Costello
Kaman Sciences Corp.
Utica, NY
(315) 734-3660
-----------------------------------------------------------------------------
>From brent@napa.Telebit.COM Thu Oct 17 11:24:23 1991
Sun-3 and Sun-4 systems have different ideas about what SCSI ID (set
by the jumpers on the drive itself) "sd0" and so forth map to. On a
Sun-4, sd0 is SCSI ID 3. On a Sun-3, sd0 is SCSI ID 0, and SCSI ID 3
will be seen (if anything) as sd4.
The system will tell you at boot time, in the kernel startup messages,
what (if any) drives it sees at what device names.
-Brent
-- Brent Chapman Telebit Corporation Sun Network Specialist 1315 Chesapeake Terrace brent@telebit.com Sunnyvale, CA 94089
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:16 CDT