8808 packets after a crash

[Manfred Young]

82558 and 82559 based EtherExpress cards can be configured to send/receive
flow control frames.

eepro100.c always enables this flow control. Byte 19 of i82558_config_cmd is
used to enable/disable flow control. This byte is initialized to 0xBD; set
it to 0x80 to disable flow control.

I believe that there should be an option to control this setting.

----- Original Message -----
From: Gary Bjerke <gbjerke@austin.polycom.com>
To: <stevemw@mindspring.com>
Cc: <linux-eepro100@cesdis1.gsfc.nasa.gov>
Sent: Friday, April 09, 1999 12:06 PM
Subject: 8808 packets after a crash


> 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.
>