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 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 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.