Subject: Re: [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender

From: Stephen Hemminger <[email-masked]>
Date: Sat, 8 Jul 2006 22:32:40 -0700

On Sat, 8 Jul 2006 11:23:59 +0200 (CEST)
"Bernd Kischnick" <[email-masked]> wrote:

> 
> On Sa, 8.07.2006, 00:36, Stephen Hemminger explained:
> 
> > The fix is not acceptable, because it eliminatess the whole sender memory
> > flow control limitation.
> >
> > The root cause is that the device incorrectly holds onto packets when
> > the carrier is lost. The device should clear it's own queue.
> > What hardware is this?
> >
> 
> That's the built-in Ethernet MAC of the 82xx series Motorola PowerQUICC
> CPUs. The driver is 2.4.32:arch/ppc/cpm2_io/fcc_enet.c, or
> 2.6.17.3:arch/ppc/8260_io/fcc_enet.c, with modifications by
> Wolfgang Denk to support a specific PHY chip.
> 
> Of course I've been examinating the driver first. It's obvious that the
> bridge code experiences much broader testing than the odd driver for
> the odd embedded target. But I didn't see a way to have the driver handle
> this problem correctly.

The driver doesn't handle carrier properly.
It needs to call netif_carrier_off when carrier is lost, and netif_carrier_on
when carrier is detected. This is done in some drivers by phy interrupt, and
in others by polling the carrier status.

Bridging can't detect lost links and do fail over without it.