My quesion:
> The log on my DNS is full of these...
>
> Jan 6 19:58:09 caliban vmunix: ie0: Ethernet jammed
> Jan 6 19:58:09 caliban vmunix: ie0: no carrier
>
> When this happens, it hoses the whole segment. Is this a hardware problem,
> or perhaps the dreaded ping-of-death? This is an old box; could it be
> dying? TIA,
Some helpful advice:
----From: Glenn Satchell - Uniq Professional Services <Glenn.Satchell@uniq.com.au>
Reasonably well known bug in the Intel ethernet driver (ie0) on the old 4/4xx and 4/2xx systems. The patch required is:
100570-05 :Synopsis: SunOS 4.1.1;4.1.2;4.1.3: ie0 ethernet jumbo patch 102143-01 :Synopsis: SunOS 4.1.3_U1: ie0 ethernet jumbo patch 103058-01 :Synopsis: SunOS 4.1.4: ie0 ethernet jumbo patch
----
From: "Marty W. Bullock" <mbullock@mindspring.com> The "Ethernet jammed" indicates that the network interface has detected 16 consecutive collisions. Check your collision rate(s) on the network. If this is the only machine with the problem, you probably have a faulty NIC or connection. TTFN!
----
From: Trevor Paquette <tpaquett@aec.ca>
I have the following documents that may help..
----------- ie0: Ethernet jammed ====================
This message can appear on SPARCservers or x86 machines with an Intel 82586 Ethernet chip. It indicates that 16 successive transmission attempts failed, causing the driver to give up on the current packet.
If this error occurs sporadically or at busy times, it probably means that the network is saturated. Wait for network traffic to clear. If bottlenecks arise frequently, think about reconfiguring the network or adding subnets.
Another possible cause of this message is a noise source somewhere in the network, such as a loose transceiver connection. Use snoop(1M)or a similar program to isolate the problem area, then check and tighten network connectors as necessary.
------------
SRDB ID: 4238
SYNOPSIS: Common "ie" ethernet errors
DETAIL DESCRIPTION:
There are 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
The 82586 chip 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
The driver and the 82586 chip have lost synchronization with each other. The driver recovers by resetting itself and the chip.
ie%d: iebark reset
The 82586 chip failed to complete a watchdog timeout command in the allotted time. The driver recovers by resetting itself and the chip.
ie%d: WARNING: requeueing
The 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
The driver discovered that memory that should remain unchanged after initialization has become corrupted. This error usually is a symptom of a bad 82586 chip.
ie1: giant packet:
A 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 packets look like 1, or too-small between-packet gap: packets have a minimum spacing between them. Jam two of them closer together than that, and have what looks like 1 packet.
ENP or STP bits blown away: Start of Packet or End of Packet bits got munged. A non-Sun host not respecting the ethernet packet size limit can send oversized packets and cause this problem.
BUG REPORT ID: n/a PATCH ID: n/a PRODUCT AREA: n/a PRODUCT: Ethernet SUNOS RELEASE: SunOS 4.1.1 UNBUNDLED RELEASE: n/a HARDWARE: Sun4, Sun3
----
Thanks to all... I'll let you know if I learn more.
Tim
==== Tim Buller buller@math.ukans.edu Math Department Systems Manager Snow Hall 643 University of Kansas, Lawrence, KS 66045 913-864-7311
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:42 CDT