rd@lri.lri.fr (Roland Dirlewanger) (07/17/87)
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 was first suspecting the controller itself, because the first time we installed it, the LEDs were showing a kernel failure. We sent the board back to the distributor for repair. Before sending it back again, I would like to know from other NP100 users if they encountered the same problems, and how they solved it. Does someone know how to use the npdump facility ? Thanks for your help. -- Roland Dirlewanger Universite Paris-Sud, LRI - Batiment 490, 91405 Orsay Cedex - France Phone: ~33 1 69 41 66 20, Email: rd@sun1.lri.fr -- Roland Dirlewanger Tel: (1) 69 41 66 20 UNIVERSITE PARIS-SUD Tx: FACORS 692166 F LRI - Batiment 490 UUCP: rd@sun1.lri.fr 91405 ORSAY CEDEX
sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) (07/30/87)
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
rd@lri.lri.fr (Roland Dirlewanger) (08/05/87)
In article <758@cadre.dsl.PITTSBURGH.EDU>, sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) writes: > In article <186@lri.lri.fr> rd@lri.lri.fr (Roland Dirlewanger) writes: [Description of the strange behaviour of the 4.3BSD generic NP100's driver] > I noticed the same problem which appeared to be "fixed" by powering down > the Unibus and powering it up, again. Not very satisfactory. > 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. I got the new version of the driver. It solved all the problems. > 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. I think they had some problems with the software at the beginning. Although the NP100 was said to work under 4.2BSD, the French distributor of Micom/Interlan products strongly encouraged us to switch to 4.3BSD before installing the board. I don't know if the NP100 board really improves the transfert rate on the Ethernet, but there are almost two major reasons why I didn't want an NI1010 board: 1/ the NI1010 requires more electrical power from the Unibus as the NP100 (NI1010: 6.7 A, NP100: 4.5 A) 2/ the NI1010 is not 802.3 compatible. So you can't connect the NI1010 board to a Fan-Out unit (this kind of boxes acting like eight different transceivers). You need to put it on a separate transceiver, handling both Ethernet 1 and 802.3 (like Interlan's NT100 transceiver) Since I installed the new driver, I'm quite happy with the NP100. > 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. Me too. I also would also like to know how to use the npdump facility. -- Roland Dirlewanger Tel: (1) 69 41 66 20 UNIVERSITE PARIS-SUD - LRI - Batiment 490 E-mail: rd@sun1.lri.fr 91405 Orsay Cedex - France