vsh@etnibsd.UUCP (Steve Harris) (11/14/89)
(this is cross posted to comp.sys.sun as well)
Some time ago, I queried the net if anybody had experiences with
"cheapo" SCSI disk drives. I received two kinds of responses:
1) No, but let me know what you learn.
2) We're using 350 MB disks from XYZ which sell for $2500.
By "cheapo", I meant under (or close to) $1000. Which probably means
about 80 MB capacity. Which probably also means targeted for the PC
market.
After shopping around, asking folks at work where they got their PC or
Mac disks, we identified a vendor, Hard Drives International (HDI) of
Tempe, AZ, as having very good prices, a reputation for quality, and a
30 day free return/replacement policy.
However, they have no experience with Sun computers. This means,
insofar as support goes, you're on your own!
Here is a sample of the SCSI disks they have (price includes enclosure
and power supply, capacity is in MB, times are in milliseconds):
Capa- Seek Transfer
Manufacturer Model city Time Rate Price
------------ ----- --- ---- ----- -----
MiniScribe 9380S 340 16 10 1895
MiniScribe 3180S 160 17 10 1275
Seagate 296N 80 28.0 10 599
Quantum Pro80S 80 19.0 10 799
Quantum Pro105S 105 19.0 10 899
Micropolis 1375 153 16.0 10 1295
Micropolis 1578 332 16 10 1795
(Note: these prices change, the Pro80S just went down $150!!)
DISCLAIMER -- I have no association with these people other than
as a satisfied customer.
Their phone number is: 800-234-3475. You get a cheerful recording
and wait for the next available sales rep. (usually not more than a
minute). If you will be buying for your company, ask for Brian in
Corporate Accounts -- he knows his business particularly well, and was
most helpful (give him my name so he knows putting up with me was worth
his while).
We ordered the Quantum Pro80S and the MiniScribe 3180S. The Pro80S is
the little brother to the Pro105S, which Sun uses in the SPARCstation
and the 3/80, so I was confident it would work. I called MiniScribe
and they said they were "pretty sure" their drive would work.
To make a long story short, I never was able to format the MiniScribe,
and returned it. We'll try the Micropolis 1375 next.
I had all kinds of problems with the Quantum. But I finally succeeded
in formatting the drive after the manual arrived and I found the actual
number of blocks on the drive. The entry in the /etc/format.dat file
is WRONG. Here is the entry I made that works.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
disk_type = "Quantum ProDrive 80S" \
: ctlr = MD21 : fmt_time = 1 \
: cache = 0x5c : trks_zone = 6 : atrks = 0 : asect = 1 \
: ncyl = 802 : acyl = 2 : pcyl = 804 : nhead = 6 : nsect = 34 \
: rpm = 3662 : bpt = 16896
# partition table for 11MB root, 25MB swap, and 45MB usr
partition = "Quantum ProDrive 80S" \
: disk = "Quantum ProDrive 80S" : ctlr = MD21 \
: a = 0, 22644 : b = 111, 51204 : c = 0, 163608 : g = 362, 89760
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
FORMATTING THE DRIVE:
After correcting the format.dat file, I used the format utility under
SunOS 4.0.3 on a both a SPARCstation1 and a 3/50. On the SPARCstation,
the drive at SCSI address 1 is sd1, on the 3/50 it is sd2 (see below).
In the next couple paragraphs, I will refer to this as drive 1 (as
on the SPARCstation), substitute "drive 2" if on a 3/50, 3/60, etc.
Format goes out and looks for drives attached to the system. If it
doesn't find sd1, either the addressing or the wiring is wrong.
When you select drive 1, you may get messages to the effect that there
are discrepancies between the size reported by the disk and the size
reported by the label. Ignore these, you're going to reformat the disk
anyway.
You will also get a message that no defect list was found.
Go into the defect sub-system and request the original defect list,
the drive will report some number of defects to the Sun. When you
exit the defects sub-menu, commit the new list. (It's my impression
that the disk is smart enough to take care of its own defects, and
that this is why the format does not find a defect list. I don't
know if it matters whether or not you extract the original list from
the disk, it doesn't show up if you format the disk again.)
During the course of formatting the disk (which takes about 1 second!),
format reports the following error message:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Error for command 'format'
Error Level: Fatal Block: 3
Sense Key: Illegal Request
Warning: Using default mode select parameters.
Warning: Drive format may not be correct.
Block 3 (0/0/3), Fatal non-media error (illegal request)
failed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
THIS IS A SPURIOUS ERROR MESSAGE, THE FORMAT DID WORK CORRECTLY!
(Thanks to Donna at the Sun hotline for telling me to ignore this
error message, and for being so helpful. As she noted, the real test
is whether or not the label command succeeds.)
Next issue the label command. It should work with no errors.
Exit format and run newfs to build your filesystems. (more: see below)
THE HDI SHOEBOX:
To get the free-standing "shoebox" from HDI, you have to order the "Mac
kit", but need to specify a generic SCSI interface. It was explained
to me that the Mac SCSI interface is non-standard and requires a
different EPROM than the Generic, or PC, interface. Later I spoke to
Quantum who said this is not the case (at least for the ProDrives) -- I
didn't fully understand what the difference was but you could use
either style equally well. For other drive manufacturers this may not
be true, so order the Mac kit with the generic SCSI interface.
The box has two female "CHAMP"-style SCSI connectors on the back (like
a Centronics printer connector). However, when you look inside the box
you see that they do NOT form a horseshoe loop with the drive in the
middle -- the ribbon just runs from the first connector to the second
connector to the drive. This means you cannot daisy-chain these
units! (You would have to modify the cable to make a horseshoe).
Since I do not plan to daisy chain, I just connect to the lower CHAMP
connector, the one at the end of the cable (I'm not a SCSI expert, but
it's my understanding that you must avoid all "T" connections to the
SCSI bus -- by connecting to the middle CHAMP, the little strand of
ribbon cable to the lower connector would constitute a T and signal
quality could be compromised -- SCSI experts please correct/amplify
these remarks).
CABLING TO THE SUN:
HDI supplies a cable to connect the "shoebox" to your Mac. At one end
is a 50 pin CHAMP connector, at the other is a 25 pin "D" connector
(like RS-232). It's useless! You will have to buy or make your own
cable -- I make mine with unshielded ribbon cable and 50-pin CHAMP and
"D" IDC (Insulation Displacement) connectors.
For connecting to the SPARCstation, I built a CHAMP to "edge-connector"
ribbon cable, opened up the box and connected the external disk in
place of the second disk.
Some time ago, there was much discussion of how Sun screwed up the SCSI
interface on their 3/60s -- pin 26, which is supposed to supply +5
volts for termination power was grounded. This meant that any other
device which chose to supply +5 on that line was likely to melt-down
its power supply, or worse, its firmware. Since, up till now, I have
always connected to Sun shoeboxes, I have not been concerned with this
problem.
However, now that I am connecting to another vendor's shoebox, I must
take precautions. As a simple, if ugly, fix, I just cut wire 26 of the
ribbon cable at the Sun end, causing line to float. (Actually, I made
a short piece of cable with line 26 cut which I can insert between the
sun and the cable to the disk drives). Strangely, when I tested for
continuity between pin 26 and ground on the 3/60, there was none.
Still, better to be safe...
BTW -- the Quantum drive does not have a jumper to select the source
for termination power (a la CDC). According to their tech hotline, the
hardware can detect +5 on pin 26 and uses that if it's there, otherwise
it uses +5 from its local power input!
DRIVE ADDRESSING:
Note that the SPARCstation's disk addressing is peculiar -- logical
disk 0 (sd0) is at SCSI address 3, and logical disk 1 (sd1) is at SCSI
address 1.
On the 3/50, SCSI address 1 maps to logical disk 2 (sd2). This is due
to the assumption that there can be up to two drives on each SCSI
controller (the SCSI standard allows up to 8 devices per controller);
the SCSI controller at address 0 (my primary drive) could have disks 0
and 1, the controller at address 1 (my secondary drive) could have
disks 2 and 3. In fact, with embedded SCSI, there is only one device
at each SCSI controller address, but the Unix kernel is configured to
allow for two.
The HDI shoebox has a clever little address setting switch on the back
of the box -- there are two little levers and a window displaying a
digit, press the "+" lever and the digit increments, press the "-"
lever and it decrements (you have to "flip" the lever to be able to
press it).
Unfortunately, the value displayed in the window does not match the
value set on the three address jumpers of the drive. I checked for
continuity and found that setting the switch to 1 does not jumper
address A0. Furthermore, when you examine the wiring of the plug that
mounts on the disks address jumper pins, you see that it can only
jumper pins 0 and 1 -- there is only one wire running to the pair of
connectors for jumper 2. (I assume this setup works okay for Mac's.)
I just disconnected the plug from the disk and set the address manually
(the three address jumpers are labeled: A0, A1, A2). You have to open
the box up to do this, but once the plug has been removed you can
access the address jumpers by removing a metal plate from the base of
the shoebox.
While you're removing the plug, remove the parity-enable jumper
(labeled "PE" -- it's the middle of three, just above the address
jumpers). Apparently the disk doesn't work correctly with the Sun if
parity is enabled (this is at the recommendation of Quantum -- I
noticed that the two Pro105S drives in our SPARCstation also has the PE
jumper removed). (For what it's worth -- I just succeeded in formatting,
labeling, and newfs-ing a Pro80 with parity enabled.)
MANUALS:
The drives do not come with owners manuals -- you can get one by
calling the manufacturer's technical support line. HDI will give you
the manufacturers' 800 numbers. Quantum's is 800-367-1984.
Over the course of mucking with these disks, I have looked at a number
of manuals. Most are fairly good, but usually you have to dig to find
the information you need. The Quantum manual is exceptional, far
superior to all the others I have seen. It is well organized, well
written, readily comprehensible (insofar as a technical manual can be
readily comprehensible), and professionally typeset (not a Xerox of an
nroff printout on a dot-matrix printer!!). There are a large number of
diagrams and tables which make the information much easier to
understand. It has as good a summary of SCSI as any I have seen. The
day the manual arrived, it took me about 30 seconds to find the
information I needed to diagnose the source of my problems (the
erroneous format.dat entry)! It's my SCSI reference manual now.
CACHE:
I did not attempt to format the drive using the standalone diag utility
which comes with SunOS 3.x, but I bet it would work. However, it seems
likely the on-board cache capability of the drive would not be enabled
-- there is no provision for this capability in diag. From reading the
disk manuals, it seems this capability requires a a bit be set in the
SCSI "mode select" command -- it is NOT on by default. I assume that
the "cache = 0x5c" parameter in the format.dat file results in the
appropriate bit being set.
=== MILD FLAME ===
I do wish Sun would publish definitions of these parameters (cache,
trks_zone, atrks, asect) so that we could take advantage of them. For
example, the MiniScribe manual speaks in terms of alternate sectors per
cylinder (not per track); how do I modify my format.dat entry to
accommodate this capability? Why is there no entry in section 5 of the
Command Reference Manual for format.dat???
=== END FLAME ===
SUN HOTLINE:
I'd like to take a moment to commend Sun on improving the hotline. Six
months ago my request for assistance could have taken several days
before I received a response, and it's unlikely the person at the other
end would have been much help. They have come a long way from those
dark days -- the response was within 2 hours, and Donna was most
helpful in resolving this problem.
I'm sure there are still problems, especially with more esoteric
aspects of the operating system. Nevertheless, I was impressed with
the improvement.
FOLLOW-UP:
Although my formatting took place under SunOS 4.0.3, our application
currently runs under 3.5. I figured, no problem, I'll just load 3.5
(from my master tape -- I refuse to go through suninstall) while I
still have the disk mounted under 4.0.3, halt, set the address jumper
to 0, plug it in to a standalone 3/50, and reboot. No such luck. I
got the message:
Boot: sd(0,0,0)
and nothing else. It just sat there. The EEPROM saw the disk, but was
unable to find the boot program. Back to the drawing board.
So, I set up a 3/50 with a cartridge tape drive and this disk on the
SCSI bus. Booted from 3.5 tape, loaded diag, relabeled the disk,
loaded the standalone copy, copied the miniunix to sd(0,0,1), and
booted sd(0,0,1)vmunix -as. Standard stuff. Worked fine. Reloaded
3.5 from my master tape, sync'ed the disk, and rebooted. No problem.
Clearly, something under 4.0.3 is incompatible with 3.5. My guess is
newfs, but how the boot EPROM loads the boot program from the root file
system is a mystery to me. Any ideas?
--
Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vshkc@hprnd.HP.COM (Kurt Chan) (11/23/89)
|The box has two female "CHAMP"-style SCSI connectors on the back (like |a Centronics printer connector). However, when you look inside the box |you see that they do NOT form a horseshoe loop with the drive in the |middle -- the ribbon just runs from the first connector to the second |connector to the drive. This means you cannot daisy-chain these |units! (You would have to modify the cable to make a horseshoe). |Since I do not plan to daisy chain, I just connect to the lower CHAMP |connector, the one at the end of the cable (I'm not a SCSI expert, but |it's my understanding that you must avoid all "T" connections to the |SCSI bus -- by connecting to the middle CHAMP, the little strand of |ribbon cable to the lower connector would constitute a T and signal |quality could be compromised -- SCSI experts please correct/amplify |these remarks). The "T" connections you refer to act as transmission line stubs. ANSI has limited the length of the stubs to .1 meters on single-ended systems (and device capacitance to 25 pF, including the stub). On maximally configured systems (6 meters, 5-7 peripherals) the cumulative effects of marginal transmission line design can cause failure. Also note that SCSI-2 recommends that devices should be spaced no closer than 0.3 meters to reduce the stub effects. |However, now that I am connecting to another vendor's shoebox, I must |take precautions. As a simple, if ugly, fix, I just cut wire 26 of the |ribbon cable at the Sun end, causing line to float. (Actually, I made |a short piece of cable with line 26 cut which I can insert between the |sun and the cable to the disk drives). Strangely, when I tested for |continuity between pin 26 and ground on the 3/60, there was none. |Still, better to be safe... Hopefully, the Sun is always at one end of the cable and provides it's own terminating circuit. You can test this by powering up the Sun, disconnecting the SCSI cable, and probing the SCSI signal wires on the bulkhead. They should read no less than about 2.5V and, when grounded through an ammeter, should provide about 40 mA of current (depending on the value of Sun TERMPWR and the resistance of the ammeter). Kurt Chan Hewlett-Packard