Asdcsvax.1780
net.periphs
utcsrgv!utzoo!decvax!ucbvax!ucsfcgl!sdcarl!sdcattb!sdcatta!phonlab!sdcsvax!phil
Thu Mar 18 13:31:28 1982
Foreign disk systems for the VAX Family
Dear Friends,
Here are all the messages that I received in response to my recent
request for information about SI RH780/Massbus emulators and Fujitsu
Winchester Disks. It seems that the Fuji's are a real winner. Not
one serious problem!
The opinion of SI controllers (in general) was not too good....
There seems to be enough interest in this to justify opening the
expanded topic for net-wide discission:
----------------------------------------------------------
"`Foreign' disk controllers and disks for the VAX family".
----------------------------------------------------------
Please post your feelings and experiences directly to net.periphs
if possible. Feel free to mail to me if you can't.
What is the word on the emulex RH780/massbuss system?
Does anyone really have any of the larger Fuji's?
Thanks to all of you that have contributed so far!
Phil Cohen
UC San Diego
mail to: ucbvax!sdcsvax!phil or phil@nprdc
p.s.: If your "boss" objects to this discussion, you have the wrong job.
=============================================
>From ucbvax!ucbcad:quarles Sat Mar 13 07:55:24 1982
To: v:sdcsvax!phil
Subject: S.I. disk controller
We are running a 780 under 4.1 with a S.I. 9400 controller, and
have both a Fuji and an Ampex on the controller. We have had several
problems with the combination. First the bad news:
If you have more than one type of drive on the controller, there
is still only one device type register, so autoconfig. doesn't work
right, since it finds only the single drive type. Several people have
complained to S.I. about this, and they claim that they are working on it.
The reset on the controller is not connected to anything except
the reset switch on the front of the box - You must manually reset it
each time rather than having it reset automatically by the system during
bootup.
The controller generates spurious writes on power up. This means
that anytime you are going to power up your controller, you must first
either power down or write protect all the drives connected to it.
This is aparently a well known problem, because in addition to the
warning from S.I., we also got a warning from our DEC CE about it.
If you care to build a new size table in the driver, S.I. will (or at
least can) supply you with a set of microcode for the controller that
will run the Fuji raw instead of mapped as 2 RM03s - This seems
to work quite well, and avoids the overlapped seek problem.
One further problem with the S.I. controller is in its handling
of unexpected events. When we had a power supply problem with the Ampex,
we got occasional seek incomplete errors from the drive. The controller
would set the proper bit in the error type register, BUT, would not
re-issue the command or generate an interrupt. This causes the entire
disk drive to disappear as far as 4.1 is concerned. The only way to
get access to the disk again is to reboot.
Our biggest complaint is with S.I. service. They want ~2100/year
for service with 8 working hour response and ~1500/year for 16
working hour response, and MUCH more if you want coverage on
evenings/weekends (This is just for the controller - not including
the Fuji). We have had our controller totally die twice in <6 MONTHS, MINUTES THINGS DAYS BECAUSE BASED CALLED CHECKED , - PLANNING SCREAMING A FOR ARRIVES. PROBLEMS, THURSDAY NOW (BOTH LIST TOOK ONE FUNCTIONING ~2 WHEN OF NEWS: ALTHOUGH ON RID NEVER SATURDAY-SUNDAY-MONDAY ~19X24 DOWN. BOARD TIME WEEKEND, PC KEPT AFTERNOON, NIGHT WITH SOFT FAILURE JUST INTERMITTENT SATURDAY AN AS AT S.I. SECOND TIMES FIRST WAS DRIVES THAT AND TWO THE CE ANY TAPE HAD EMULEX MILES FEW SYSTEM ROUTINE RUNS PAY DO READY SITE FOUND TO SITS HAVE CONSECUTIVE CURRENTLY ANOTHER DRIVE JOB GET DISK THEM SERVICE WERE OUR CABINET OUT DOWN ARE THEY SENT ORDER MAIN BAD POKING GOOD AWAY ABLE MORNING WE PROBLEM, CONTROLLER FIX POWER EACH GREAT. HERE ITS BEFORE ADJUSTED IN STARTED BEEN REPLACE IT MONDAY SUPPLY SYSTEM, AFTER PERIODS THIS ONLY ENTIRE ALL.="======================" DEAD FUJI VOLTAGES. ATTENTION LEAST COMING BOARD). SOON>From ucbvax!decvax!ittvax!swatt Sun Mar 14 09:01:59 1982
Date: Sat Mar 13 14:16:12 1982
To: sdcsvax!phil
Subject: SI disks under 4.1 BSD
Phil:
We are also currently investigating using SI products. Two people you
should talk to are:
Mike O'Dell (mo@lbl-unix or lbl-unix!mo)
George Gobel (pur-ee!ghg)
The overlapped seek botch should not affect UNIX operation, as you just
put the correct partition sizes in the driver table anyway. I had heard
the botch applied to the CDC 9775 drive when configured as two RM05's,
but the same principles apply; straight VMS drivers would blow up trying
to treat one drive as two physical disk head assemblies.
George Goble runs SI controllers with Fujis and likes them. We are
looking into the Fujis, but the real attraction is the Eagle, which will
be 480 MBytes in the same size as the 160. These will probably not be
available from SI until the end of this year or the beginning of next;
they're having trouble getting them in any quantitiy.
You can reach "pur-ee" through decvax; "lbl-unix" can be reached through
ucbvax.
- Alan S. Watt ([decvax!]ittvax!swatt)
=============================================
>From phonlab!sdcatta!sdcattb!sdcarl!ucsfcgl!ucbvax!decvax!duke!swd Sun Mar 14 09:54:01 1982
Date: Sat Mar 13 14:06:18 1982
Subject: SI fuji's.
SI's field serviec (at least on the east coast) is not good.
The fuji's work better if you configure them to look like one
large RM03 rather than two smaller ones. The SI controller
handles this nicely, and it takes changing only a #define or two
in the driver to make unix happy.
=============================================
>From ucbvax!teklabs!terryl Sun Mar 14 17:53:31 1982
To: ucbvax!sdcsvax!phil
Subject: SI disks under 4.1
We here at Tek have a couple of VAXEN running 4.1 with the SI disks with
no problems. Are you aware that the Fujitsu's can be mapped as either two RM03
disks per physical disk, or as one big RM03 disk per physical disk??? I don't
remember which switches you change, but there are a couple on the controller
card, and then there are a couple in the disk that you have to change; unfor-
tunately though, you can't tell through software which mode the disks are in
because SI hardwires the device type register regardless of which mode the
disks are in, so you can solve that by either having another device driver for
the SI's, or put hooks into the original saying if this is an SI, then use
these sizes. Send mail to ....!ucbvax!teklabs!sterling for more info; he's
the main support for VAXEN at Tek.
Terry Laskodi
...!ucbvax!teklabs!terryl
=============================================
>From nprdc!Dean@Cornell Mon Mar 15 07:46:32 1982
Mail-from: ARPAnet host udel-relay rcvd at Mon Mar 15 07:31:30 1982
Date: 13 Mar 82 14:01:15-EST (Sat)
From: Dean at Cornell
To: phil at Nprdc
Subject: SI disk drives
Via: Cornell; 13 Mar 82 18:16-EST
Via: UDel; 13 Mar 82 18:32-EDT
We have been using Fujitsu 160MB drives with the SI massbus controller under
4.1BSD for quite a while. The drives and controller have been excellent with
no problems to date (we've had them for about a year). We are currently
using them in the RM03 emulation mode without any serious difficulties. The
seek problem you refer to may be the one caused by the "two" RMO3s being
separately optimized. This can result in significantly non-optimal seek
behaviour. For this reason we are about to change the disk mapping to
"super" RM03 emulation (requires changing one DIP switch in the SI 9400
controller). This makes each Fuji drive look like an RM03 with 10 tracks
per cylinder instead of the standard 5. Purdue has been running their
drives this way for a while with no problems. The one potential problem
is the bad block file, since you can't use the standard DEC bad block file
program on the "super" RM03. However, none of our Fuji drives (or Purdue's)
seem to have bad blocks that are not ECC correctable.
You might also want to consider the SI Massbus controller with the CDC 675MB
drive. We have had one of these for about 3 months with only one problem
(turned out to be a loose cable in the drive). You can run it as 2 300Mb
RM05s, or else an unmapped mode which gives you 40 tracks/cyl and 843 cyls.
The bad block problem in unmapped mode is a bit trickier here, but at least
one site (Brian Redman at harpo) has done it, and we plan to be running ours
that way shortly.
SI service has been quite good, and the equipment reliable. Since their
maintenance contract costs are about the same as DECs, they certainly should
be.
My pricing may be a little out of date, and some of our deals with SI were
slightly confusing (involving multiple simultaneous purchases, trade ins,
educational discounts, etc.), but here are the prices we wound up with
SI massbus ctlr and 1 Fuji 160Mb disk $21,150
Additonal Fuji drive $8,550
SI massbus ctlr and 1 CDC 600MB drive $34,900
(Installation additional)
I hope all this is some help. If you have any questions, don't hesitate
to get in touch.
Dean Krafft, Research Associate
Cornell University, Computer Science Dept.
(607) 256-4052
dean.cornell@udel, decvax!cornell!dean
=============================================
>From nprdc!ucbcad.clemc@Berkeley Mon Mar 15 23:36:39 1982
Mail-from: ARPAnet host ucb-c70 rcvd at Mon Mar 15 23:12:19 1982
Date: 15 Mar 1982 21:37:09-PST
From: ucbcad.clemc at Berkeley
To: phil@NPRDC
Subject: SI and Fuji's
In general the Fuji's are great. SI on the other hand.. When I was at
Tektronix we had a ton of these and had very few problems, but... Once
I got here to UCB, this machine (Tek Vax or UcbCad depending on what
naming convention), has a SI and a fuji and has had tremendious
difficulty. Of three major hard failures, all have been with the
controller.
Basically, we have the controller on loan and are NOT planing to
purchase it. As soon as the emulex comes in, we will return this
controller to SI. Besides its reliablity, the controller is a real
turkey for SW. We have in the kernel an:
#ifdef UCBCAD
force the drive to understand that this really is a Fuji
not two RM03's
#endif
What a pain. Good luck,
Clem Cole.
clemc@berkeley
ucbvax!clemc
============================================
>From ucbvax!pur-ee!mahler Tue Mar 16 09:31:45 1982
To: ucbvax!sdcsvax!phil
Subject: SI's & FUJI's
Cc: ghg
Phil:
The Engineering Computer Network at Purdue University runs
the 160 MB FUJI's on the SI 9400 SBI controllers. We have about
16 FUJI'S and about 10 9400's on the SBI (spread across 6 VAXs).
And it seems like we have a new system coming in every month between
now a Christmas. I would be happy to discuss the situtation with
the controllers and drives, and if I don't have the answer I can get
you in touch with a person here who can answer it. I might also mention
the PURDUE DUAL VAX (not an 11/782), the FUJI's and 9400's run
on the dual.
Steve Mahler, Network Services Manager
Purdue University
(ucbvax!pur-ee!mahler)
==============================================
>From ucbvax!pur-ee!mahler Tue Mar 16 09:31:49 1982
To: ucbvax!sdcsvax!phil
Subject: SI'S & FUJI'S
OOOPS .. my tx number is 317+494-3373 .... Steve Mahler (pur-ee!mahler)
=================================================
>From phonlab!sdcatta!sdcattb!sdcarl!ucsfcgl!ucbvax!ucbcad!tekcad!chriso Tue Mar 16 21:46:53 1982
Date: Mon Mar 15 16:44:34 1982
To: ucbcad!ucbvax!ucsfcgl!sdcarl!sdcattb!sdcatta!phonlab!sdcsvax!phil
Subject: re: Info needed on SI disk systems under 4.1 BSD
Dear Phil:
We have the following system configuration:
VAX 11/780 -------|-------|-------|-------|-------|
UBA-| MBA0-| MBA1-| SI | SI |
| | | RH780 | RH780 |
... 2) RM03's TU-77 EMULATA|EMULATA|
0---| 1---|
| |
9400 9400
| |
3) Fugitsu's 3) Fugitsu's
(160MB/dr) (160MB/dr)
The SI stuff was installed in mid September under 4.0 BSD. In
October we put up 4.1 BSD and have had no problems other than:
3) calls to service one of the 9400's. During the last call they
replaced the power supply (bad -5V supply)
1) call to fix a loose cable connection to one of the drives
Above and beyond normal op-sys adjustments that are necessary when
one wants to make use of an add on disk:
Installation requires 5 line addition to autoconfig.c or a new
version of firmware for the 9400's. Our controllers return a drive
type of RM05 or RM03 when what you really want is "SIFJ" (or some
such thing). In hp.c the drive sizes are indexed into via the
drive type and if you already have RM0[35]'s or you don't want to
change the RM0[35] sizes entry you end up with a mess. Our
solution was to patch autoconfig.c and make a SIFJ entry into the hp.c
sizes table.
Further questions: ...!ucbvax!teklabs!tekcad!chriso
Chris Olson
====================================================
>From nprdc!bierma Thu Mar 18 12:01:51 1982
Date: 18 Mar 1982 at 1127-PST
From: bierma at NPRDC
Subject: possible lost message
To: sdcsvax!phil
>From Odonnell@YALE Thu Mar 18 08:37:24 1982 remote from nprdc
Mail-from: ARPAnet host yale rcvd at Thu Mar 18 08:37:01 1982
Date: 17-Mar-82 2130-EST
From: John O'Donnell <ODONNELL YALE AT>
Subject: Fujitsu/SI
To: Phil at NPRDC
Hi; saw your note on usenet asking about SI controllers on
4.1BSD. We have a number of 750s on campus. Several have
Emulex controllers (SC21/V) with Fujitsu 2284s; one has an SI
controller with the same drives. The drives are really good;
of 7 drives over 1-1/2 years, one power supply has failed,
nothing else. The Emulex controllers are also excellent; no
problems (solid or intermittent) of any kind to report. We
have drivers available for 4.1, 4.0, V7.
Alas, the SI controller has been a long sad story. Months of
VAX crashes, now reduced somewhat; still many many bad-block
problems, apparently caused by the controller occasionally
writing the wrong block or something. The SI controller is on
a VMS system, but the Emulex driver should work without
modification (barring timing problems on the SI) since they
both strive to emulate the DEC controller. The only change
from the distributed Berkeley controller is to the tables that
map sizes.
Good luck; if you go with SI, things are probably better now
(ours was an early 750 controller); but beat hell out of it while
its under warranty.
-------
The above file was stepped on by a recent system crash. Ironically
enough the crash was a bad-block problem on one of our disk drives hung
off a SI controller. It is not a hard enough problem to track down the
source (happens every 3 mos or so) but it is interesting that the problem
has shown up elsewhere. Ther is a hard bug in SI's microcode - it fails
to drop the Volume Valid bit when a drive spun down. I have told the
engineers about this and they claim they are working on it, but months
later (this has been going on for a year) when I call them back they
claim to know nothing about the problem. This seems to be their typical
attitude towards customers.
The physical assemble of the SI controller is also verry poor. There
is no practical way to diagnose it in operation (boards stacked on boards)
and the power supply is completely inaccessable.
The only advantage SI has is the multiple cpu port capability.
Have you heard about the new Emulex SC750. It is a RH750 equivelent controller
that plugs directly into the 750's CMI bus. It also supports mixed drive types.
===============
End of Message.
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
