steve@tellab3.UUCP (Steve Harpster) (10/02/84)
I've been experiencing strange ethernet problems. Maybe someone out there can help me out. First let me say that we have 3 750's all running 4.2 BSD with Interlan's controller. 1. When a tap is unplugged from the controller, then plugged back in, the system reboots. No error messages, panics, nothing --- it just starts rebooting. I can live with this but it's not too friendly. 2. Because of an incredibly poor design, the cable from the controller to the tap quite often comes loose. This is noticed because the machine appears down and the lights on the controller stay dark. The problem is, none of the other machines can talk either. For example, if machine A's tap is loose, machine B and machine C should still be able to talk but they can't! If machine A crashes, everything is okay. The problem only appears when the tap is loose (wiggling the cable usually brings all the machines back up on the network). Needless to say, this makes it hard to figure out which machine has the trouble. 3. This is the most disturbing. Every machine appears down to the others. The taps are secure. Each controller on each machine periodically flashes the carrier sense light. It looks like they each detect activity on the network but they can't figure out who's doing it. For the most part, the ethernet works great. Whenever we do any activity under the floor though and bump the cable everything goes to hell. If anyone has any ideas, please let me know. Thanks. -- ...ihnp4!tellab1!steve Steve Harpster Tellabs, Inc.
smh@mit-eddie.UUCP (Steven M. Haflich) (10/07/84)
The first problem, that a 750 reboots when its Interlan tap is (re)connected, is well known and has been reported here before. The tap draws a large surge of 15V power when first connected, and the paranoid powerfail detection in the 750 thinks that there has been a power failure. There is no known fix, except using a different kind of tap. However, once your network is established and stable, will you really need to plug and unplug taps frequently? There is no reason for the transceiver cable to work loose at either end. You should strain relieve the interface end of the cable (with a cable tie) to the CPU chassis near the interface. It is also wise to affix the transceiver to something solid (again, cable ties work well) and then strain relieve the cable near it as well. Most important, make sure those awkward little clips on the transceiver end of the cable are tight and working. They can be "adjusted" a little with a screw driver.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (10/08/84)
Your third problem may be due to a bug in ifconfig. Are you sure you have the corrected version? -Ron
rpw3@redwood.UUCP (Rob Warnock) (10/11/84)
+--------------- | I've been experiencing strange ethernet problems. Maybe someone out | there can help me out. First let me say that we have 3 750's all | running 4.2 BSD with Interlan's controller. | ...ihnp4!tellab1!steve | Steve Harpster | Tellabs, Inc. +--------------- Incidently, whose transceivers are you using? Interlan? DEC? TCL? (Other?) What version of the spec (1.0 vs 2.0 vs 802.3)? They all interoperate (usually) on the cable, but the problems/symptoms on the controller side are different. +--------------- | 1. When a tap is unplugged from the controller, then plugged | back in, the system reboots. No error messages, panics, | nothing --- it just starts rebooting. I can live with | this but it's not too friendly. +--------------- I have seen a note on this before... the transceiver may (per spec) draw up to 1/2 Amp of +15 volts (actually, 12-15 +/- 5%), which the controller provides from its host computer's bus, in this case your Unibus backplane. Now a half-Amp is a good bit, especially if the transceiver has heavy filters (capacitors) which cause a heavy startup surge (NOT spec'd, although conservative design would suggest not drawing more than the allowed 1/2 Amp). Plugging in the transceiver can therefore cause a temporary overload on the +15v supply (of some microseconds or even milliseconds), which can cause the power-fail detectors in the VAX (which are QUITE good!) to trip, forcing and immediate and complete power-up reset sequence! (So that's why you don't see any console messages...) If you have people handy with electronics around, they may be able to build you a little surge filter (with a power supply "choke" inductor or equivalent, plus a swamping resistor) that you can put in series with the +15 line to the transceiver (pin 13), as close as possible to the controller board. If the D.C. resistance of the choke is low enough (a few ohms) and the inductance high enough (a Henry or two), it should cure the problem. WARNING: I have not tested this and cannot guarantee the results. (You may have problems with the inductance causing an instability in the D.C.-to-D.C. converter in the transceiver. That's why I mentioned the swamping resistor.) +--------------- | 2. Because of an incredibly poor design, the cable from the | controller to the tap quite often comes loose. This is | noticed because the machine appears down and the lights | on the controller stay dark. The problem is, none of the | other machines can talk either... +--------------- If this is true, the transceiver is not meeting spec. I'm guessing you may be losing one side of the transmit pair, causing the transceiver to think you are sending continuously, but the transceiver's "jabber control" circuit should stop this after a few (20-150) milliseconds. Make sure your transceivers are all equipped with "jabber control". If they aren't, complain (and replace them!). (In the version 2.0 Ethernet Spec., this is called a "Transmit Watchdog Timer", Section 7.4.6) +--------------- | 3. This is the most disturbing. Every machine appears down to | the others. The taps are secure. Each controller on each | machine periodically flashes the carrier sense light. It | looks like they each detect activity on the network but | they can't figure out who's doing it. | | For the most part, the ethernet works great. Whenever we do any | activity under the floor though and bump the cable everything goes to hell. +--------------- Check the mechanical integrity of all joints, the physical taps, and the termination resistors at the ends. A short circuit or an open circuit will cause each transmitter to think that it's "colliding" with someone else (due to reflections from the "mismatch"). If you have controllers equipped with the TDR (Time Domain Reflectometer) feature (counts "ticks" from transmit til collision), you can use that to narrow the source of the problem to within a few tens of meters. (A real TDR can be used if you get desperate.) Hope that helps. Rob Warnock UUCP: {ihnp4,ucbvax!amd}!fortune!redwood!rpw3 DDD: (415)572-2607 (*new*) Envoy: rob.warnock/kingfisher USPS: 510 Trinidad Ln, Foster City, CA 94404 (*new*)