On Sat, 8 Jul 2006 11:23:59 +0200 (CEST) "Bernd Kischnick" <kisch at sesamstrasse.dyndns.tv> 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.
