8808 packets after a crash

[Manfred Young]

I agree that a network card shouldn't send flow control packets when it's
running half-duplex, but the EtherExpress does if it's configured to do so.
eepro100.c could be modified to enable flow control only if the link is
running full-duplex.

----- Original Message -----
From: Gary Bjerke <gbjerke@austin.polycom.com>
To: Manfred Young <myoung@scaleable.com>
Sent: Friday, June 25, 1999 2:38 PM
Subject: Re: 8808 packets after a crash


> Manfred Young wrote:
>
> > 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.
>
> An endpoint connected to a half-duplex hub is never supposed to issue
> flow-control packets. The option byte is supposed to allow the 82558/9 to
use
> flow control on full-duplex links only. The programmer's manual uses the
> qualifying phrase "full-duplex" in more than one place in discussing flow
> control options. In any case, I've tried all possible settings that
explicitly
> disable full-duplex, and have still occasionally gotten transmit lockups
with
> PAUSE frames.
>
> Here is what it says on page 150 of "Gigabit Ethernet" by Kadambi,
Crayford,
> and Kalkunte:
>
> "The PAUSE frame is restricted to use within full-duplex 802.3 stations
only.
> By definition, a full-duplex Ethernet station has a single point-to-point
link
> to another single Ethernet station."
>
> This is a little misleading, as one link partner might be a full-duplex
switch
> port. The key issue is that, because the other partner is full-duplex and
> flow-control compliant, it does not propagate the packet. If an 82559
sprays
> PAUSE frames to a half-duplex hub, they propagate to every endpoint, and
> potentially cause all endpoints to lock up because one endpoint is having
> problems. The normal scenario for flow control would be, for example, a
single
> high-capacity server connected directly to a switch port. Throttling back
the
> server does not take a whole segment down - throttling back through a hub
does.
>
>
>
> >
> >
> > ----- 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.
> > >
>