Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!pt!cadre!sean
From: sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
Newsgroups: comp.dcom.lans,comp.bugs.4bsd
Subject: Re: NP100 Ethernet Controller problem under 4.3BSD
Message-ID: <758@cadre.dsl.PITTSBURGH.EDU>
Date: Thu, 30-Jul-87 10:38:27 EDT
Article-I.D.: cadre.758
Posted: Thu Jul 30 10:38:27 1987
Date-Received: Sat, 1-Aug-87 10:19:18 EDT
References: <186@lri.lri.fr>
Reply-To: sean@cadre.dsl.pittsburgh.edu.UUCP (Sean McLinden)
Organization: Decision Systems Lab., Univ. of Pittsburgh, PA.
Lines: 53
Keywords: np100, 4.3BSD
Xref: mnetor comp.dcom.lans:702 comp.bugs.4bsd:473

In article <186@lri.lri.fr> rd@lri.lri.fr (Roland Dirlewanger) writes:
>
>Hi there,
>
>We have just installed a Micom/Interlan NP100 Ethernet board on our
>VAX 11/750 running 4.3BSD. After rebooting the Vax, the controller worked
>for one or two days, then failed to respond, though both of the green LEDs
>were on.
>
>I tried to reset it with the usual sequence:
>	ifconfig ix0 down
>	npload np.image
>	sleep 10
>	ifconfig ix0 up
>This helped only for a few minutes, then the controller failed again.

I noticed the same problem which appeared to be "fixed" by powering down
the Unibus and powering it up, again. Not very satisfactory.

I've also noticed that if I have two boards in the same Unibus with CSRs
of 166000 and 166020 (as suggested by the manual), both fail the initial
diagnostics AND none of the devices further down the Unibus are configured
in at boot time. Removing the second board fixes the autoconf problem,
though npload never finishes.

A couple of other points: Around April there was a revision made to the
Berkeley NP100 code which you may want to get a copy of. In particular,
the driver and pseudo-driver were affected. Also, I would love to have
a copy of the sources for np.image (and a cross compiler for the CPU),
but I don't know if these are available. The Berkeley distributed code
comes from MICOM.

Interestingly, we actually bought two of these boards but MICOM tried to
talk us out of them. Their contention was that there was little or no benefit
to the intelligent controller in the BSD Unix environment because most of
the protocol stuff is handled in the kernel. For that reason, they recommended
two NT1010s. We chose the 100's because we wanted a hedge against future
"enhancements" in the Unix environment which might make use of the
sophistication of the board. We had hoped to make use of the intelligence
in a network of NFS machines where some were Vaxen (on one controller),
and the others were Suns (the second controller).

A final note. We have since had the opportunity to compare the NP100 to
the Excelan EXOS 304 Controller. Both controllers are on the same Unibus
and traffic on the networks is roughly equivalent. I would be happy to
discuss my observations on the comparison with interested parties. Note
that we have received no compensation from either Micom or Excelan for this 
trial.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
(412) 648-9600