Layer 2 Multicasting problem on shut down system brings down all eepro100's on the net!!

[Manfred Young]

The packets with Ether type 8808 frame are 802.3x link flow control packets.
These packets are meant to be used only when the link is in full duplex
mode.

Unfortunately, the eepro100 driver always enables flow control. Since it's
not always possible to determine the duplex setting for a link, I believe
that the eepro100 driver should, by default, disable flow control. A new
option to enable flow control would then be required.

----- Original Message -----
From: Robert Schwartz <roberts@corel.com>
To: <linux-eepro100@beowulf.gsfc.nasa.gov>
Sent: Wednesday, September 01, 1999 5:32 PM
Subject: Layer 2 Multicasting problem on shut down system brings down all
eepro100's on the net!!


> Hi,
>
> We are still diagnosing a major problem that has been occurring on our
> network for the past several weeks, but I thought I'd get this info out
> so that someone can either help us expedite a solution, or to help
> someone else who may be having a similar problem. Here is what we know
> so far
>
> On occasion, after a linux box is halted (we've reproduced it on a Red
> Hat 6.0 system running with the stock kernel 2.2.5-15(?)) but the power
> remains on, the eepro100 card will start multicasting to mac
> destination: 01:80:c2:00:00:01 an Ether type 8808 frame. This, in turn,
> causes ALL other eepro100's on the network to pause transmitting,
> effectively, crippling all network communications to/from ANY machine
> with an eepro100 card on the network!!
>
> Now, the machines have been told to halt, and display on the screen does
> say the system can now be powered off, however it is at this point where
> we have successfully reproduced this multicasting problem. We believe
> that the card may either be left in a state that causes this strange
> behavior either because of a bug in the firmware of the card, or perhaps
> because the driver does not appear to reset the card upon shutdown.
>
> To test this theory, we have made a small mod to the driver to force a
> software reset of the card upon unloading of the driver. So far this
> afternoon, that machine has been performing flawlessly (with over 10
> shutdowns and no multicasts). We will let the machine run over night and
> will try a few more tests with this new driver, before loading back the
> original driver and recreating the problem. We will of course post back
> to the group the modifications, once we're convinced it could be a fix.
>
> Any help, comments or suggestions would be appreciated.
>
> Thanks,
>
> -Rob
>
>
>