A site I'm working with is building a machine using a 79c975 Ethernet
chip.  We were seeing problems where, if the CPU is frozen by external
means (JTAG interface, to be precise) for a sufficiently long period,
the network goes out to lunch.

"sufficiently long" seems to be more related to number of packets than
amount of time, and "goes out to lunch" is a deliberately fuzzy term.
The network still works, but packets get severely delayed and grossly
re-ordered; pinging from another machine produces a low loss rate, but
RTTs of several seconds - anywhere from a couple of milliseconds to
some seven seconds.  And the packets get reordered to the point where
the serial numbers printed by ping might look like ..., 3, 7, 8, 10, 5,
11, 9, 6, 14, 12, 13, 15, ....

Based on some good guessing by one of the people there and some LEDEBUG
output, we created the patch below, which completely cures the
misbehavior for them.  I offer it for consideration and possible
testing by people with other chips which use am79900.c.  (I have no
idea how specific it is to the particular chips in question; for
example, I know they are 79c975s but I don't know whether there are
multiple revs of the 975, and if so which rev was in use.)

This is for a 1.5W source tree, but I'm told numerous other patches
(largely endianness cleanups) had to be applied to am79900.c, so the
line numbers may not match anything in particular.  The first of the
context lines should be pretty definitive, though.

--- am79900.c-	Tue Jul 10 16:41:49 2001
+++ am79900.c	Tue Jul 10 16:34:56 2001
@@ -451,6 +451,7 @@
 			printf("%s: missed packet\n", sc->sc_dev.dv_xname);
 #endif
 			ifp->if_ierrors++;
+			lance_reset(sc);
 			return(1);
 		}
 		if (isr & LE_C0_MERR) {

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B