Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!dgis!generous
From: generous@dgis.UUCP
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: Problem with eagle drives on 9900 SI controller
Message-ID: <204@dgis.UUCP>
Date: Fri, 27-Feb-87 21:56:12 EST
Article-I.D.: dgis.204
Posted: Fri Feb 27 21:56:12 1987
Date-Received: Sun, 1-Mar-87 14:41:38 EST
Organization: Defense Gateway Info. System, Alexandria, VA
Lines: 38
Keywords: cache, eagles
Xref: utgpu comp.bugs.4bsd:195 comp.unix.wizards:1172


I recently run into a problem (which might have been around since the
system first came up ~1 year ago), with the bad block forwarding
table getting garbled up.  The problem was never noticed until recently, when
some soft errors started showing up; when I attempted to mask them
out with the SI utilities (bbud, vh, bad, etc...), I noticed that the
original bad block info had been wiped out.

I am running 4.2BSD (historical reasons |-)), on a VAX 11/780, 16Mb, 2 MBA's,
with twin 9900 SI disk controllers, each with an attached 2Mb cache processor.
Each controller is attached to 4 eagles (8 total), and 1 rm05 disk pack (yes, 
that's roughly a total of 4 Gb of hard disk storage;  do you see why I want to
find out what's going on!!!).  Here's the hardware configuration:

+-------+  +------+  +-------+ +-------+ +-------+ +-------+ +-------+ +------+
I MBA 0 I--I 9900 I--I cache I-I eagle I-I eagle I-I eagle I-I eagle I-I RM05 I
I-------I  +------+  +-------+ +-------+ +-------+ +-------+ +-------+ +------+
I-------I  +------+  +-------+ +-------+ +-------+ +-------+ +-------+ +------+
I MBA 1 I--I 9900 I--I cache I-I eagle I-I eagle I-I eagle I-I eagle I-I RM05 I
I-------I  +------+  +-------+ +-------+ +-------+ +-------+ +-------+ +------+
I 16Mb  I
+-------+
 11/780 w/ 4.2BSD

The drives were formated with the SI formater program (dfmt) utility 
(I never could get the standalone format program to work on MBA1, 
but that's another problem).  The version of the SI hp.c driver is Rev. D 
(dated 2/86).   I would be interested in talking to anyone who
might have come across a similar problem, or might have clues/suggestions...

Thanks for the help

-curtis-

Curtis C. Generous
Lawrence Livermore National Labs
ARPA: generous@lll-tis-b.ARPA
UUCP: {seismo,vrdxhq}!dgis!generous