SUMMARY: ie0: iebark reset ???

From: John E. Ivory (
Date: Fri Oct 07 1994 - 08:06:12 CDT

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! 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, 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
to the people pwcs!
who helped.

--------------------------------- R A Z O R ------------------------ \ \ \
 John E. Ivory \ / __ __ / Tower Concepts, Inc. \ \ \/ /_ /_ / 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