Silly me. My hats off to Ed Killian for having the single correct answer
amongst the responses. He looked past my stated problem and suggested
that we were just missing a terminator on the coax cable.
Original problem statement...
> While trying to connect a 4/110 to a Sparc 1+, the 4/110 now gives us
> the error 'ie0: iebark reset'. This happens after a 'rup' or a
> 'spray'. We've been unable to get any form of connectivity between
> these two machines, so I'm wide open to ideas on how to get them to
> talk or even to give me better diagnostics. There's nothing else on
> this baby net.
>
> What the woof is a 'iebark reset'? What am I doing wrong? What broke
> and needs fixing? This used to work!
stern@sunrise.east.sun.com had the most concise answer about what an
error of this sort means...
> iebark is a "watchdog timer" (hee hee). it watches the ie chip to make
> sure it's still alive after (relatively) long periods of inactivity,
> and if the chip appears to have died, it smacks it with a reset. this
> is due to a bug in the lance chip/ie driver that causes the chip to
> hang/get confused under high loads.
Also, netman@rave.com supplied this handy description of a variety of
ie0 type complaints. It's worth keeping...
> SYNOPSIS : Common "ie" ethernet errors
>
> DETAIL DESCRIPTION : Many "ie" ethernet errors with out any details about what
> they are.
>
> SOLUTION SUMMARY : ie%d: Ethernet jammed
>
> Network activity has become so intense that sixteen
> successive transmission attempts failed, causing the 82586
> to give up on the current packet. Another possible cause
> of this message is a noise source somewhere in the network,
> such as a loose transceiver connection.
>
> ie%d: no carrier
>
> 82586 has lost input to its carrier detect pin while trying
> to transmit a packet, causing the packet to be dropped.
> Possible causes include an open circuit somewhere in the
> network and noise on the carrier detect line from the
> transceiver.
>
> ie%d: lost interrupt: resetting
>
> Driver and 82586 chip have lost synchronization with each
> other. Driver recovers by resetting itself and the chip.
>
> ie%d: iebark reset
>
> 82586 failed to complete a watchdog timeout command in the
> alloted time. Driver recovers by resetting itself and the
> chip.
>
> ie%d: WARNING: requeueing
>
> Driver has run out of resources while getting a packet
> ready to transmit. The packet is put back on the output
> queue for retransmission after more resources become
> available.
>
> ie%d: panic: scb overwritten
>
> Driver discovered memory that should remain unchanged
> after initialization has become corrupted. This error
> usually is a symptom of a bad 82586 chip.
>
> ie1: giant packet:
>
> Packet bigger than the maximum ethernet size came through
> on ie1 (max = 1518 bytes total). Obviously, a bogus
> packet. Possible causes:
>
> Noise in the "quiet space" between packets, making
> 2 pkts look like 1, or too-small between-pkt gap: pkts
> have a minimum spacing between them. Jam two of them
> closer together than that, and have what looks like
> 1 pkt.
>
> ENP or STP bits blown away: Start of Pkt or End of Pkt
> bits got munged. A non-Sun host not respecting
> ethernet packet size limit can send oversized packets
> and cause this problem.
My many thanks klaus.jungbauer@teefax.mch.sni.de
to the people pwcs!poptest@uxc.cso.uiuc.edu
who helped. edk@mach10.utica1.kaman.com
pdcmi!rick@rambone.psi.net
stern@sunrise.east.sun.com
martin@gea.hsr.it
netman@rave.com
ffm.deu.ubn.net
--------------------------------- R A Z O R ------------------------ \ \ \
John E. Ivory \ / __ __ / Tower Concepts, Inc. \ \
ivory@tower.com \/ /_ /_ / 103 Sylvan Way \ \
/ /__ __/ . New Hartford, NY 13413 \
A Problem Tracking System / Voice: (315) 724-3540 \
with Integrated Configuration Management FAX: " " -3129
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:11 CDT