8808 packets after a crash

[Gary Bjerke]

Re: a post by Steve Wynne, Sun, 31 Jan 1999 13:15:44 -0500, subject
"8808-type Packets after Unrelated Crash", in the January list archive.

Steve, I just subscribed to the eepro100 mailing list, and noticed your
post in January about the 8808 packets. I couldn't find any useful
responses to it in subsequent posts.

I have seen this too, and I believe I can reproduce it at will (with a
little effort). I've ported eepro100.c to an embedded system running a
Phillips TM1100 multimedia processor. In that system, I noticed that if
the driver ran into an out-of-resource condition in the RX ring and
issued a transmit, the 82558 would start spewing 8808 frames. These are
802.3 pause frames for flow control, and they contain a timer value.
The receiving endpoint is assumed to be a switch port, which should stop
sending frames for the duration of the timeout. On my system the timer
value was about 40 seconds, and the frames were issued about every 40
seconds, thus continually renewing the timeout.

Since my test board was connected to a dumb 10BaseT hub, which by
definition is half-duplex, these frames should NEVER be issued. I tried
setting options which should disable flow control even in full duplex
mode, and still the problem occurred. My hub probably propagated the
pause frame all the way to the switch, through an intermediate hub which
was downlinked to several other hubs. The result was that a large
network segment was completely shutdown.

In your case, if your system crash resulted in the Rx ring not being
serviced (interrupts locked out by a spin loop, IP not servicing
delivered packets and so running you out of memory to refill the ring,
and so on), you would probably see this. I forced this to happen on a
Linux 2.0.34 kernel (Redhat 5.0) by no'oping the interrupt handler and
ping-flooding the ethernet controller. When I reported this to Intel,
their engineer told me that

A) I misunderstood full-duplex, and was only *assuming* that full-duplex
was disabled
B) My test was invalid, because real drivers service interrupts
C) Good drivers are written to never run out of resources

I avoided strangling the bugger, but gave up on trying to get useful
information from him. He obviously hadn't even read my email very
carefully.