From: Stephen Hemminger <shemminger@osdl.org>
To: Bernd Kischnick <kisch@sesamstrasse.dyndns.tv>
Cc: netdev@kernel.org, bridge@lists.osdl.org, Wolfgang Denk <wd@denx.de>
Subject: Re: [Bridge] [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender
Date: Sat, 8 Jul 2006 22:32:40 -0700 [thread overview]
Message-ID: <20060708223240.57cfd14f@localhost.localdomain> (raw)
In-Reply-To: <43150.217.5.191.115.1152350639.squirrel@sesamstrasse.dyndns.tv>
On Sat, 8 Jul 2006 11:23:59 +0200 (CEST)
"Bernd Kischnick" <kisch@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.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Hemminger <shemminger@osdl.org>
To: "Bernd Kischnick" <kisch@sesamstrasse.dyndns.tv>
Cc: netdev@kernel.org, bridge@lists.osdl.org, Wolfgang Denk <wd@denx.de>
Subject: Re: [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender
Date: Sat, 8 Jul 2006 22:32:40 -0700 [thread overview]
Message-ID: <20060708223240.57cfd14f@localhost.localdomain> (raw)
In-Reply-To: <43150.217.5.191.115.1152350639.squirrel@sesamstrasse.dyndns.tv>
On Sat, 8 Jul 2006 11:23:59 +0200 (CEST)
"Bernd Kischnick" <kisch@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.
next prev parent reply other threads:[~2006-07-09 5:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-04 15:48 [Bridge] [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender Bernd Kischnick
2006-07-04 15:48 ` Bernd Kischnick
2006-07-07 22:36 ` [Bridge] " Stephen Hemminger
2006-07-07 22:36 ` Stephen Hemminger
2006-07-08 9:23 ` [Bridge] " Bernd Kischnick
2006-07-08 9:23 ` Bernd Kischnick
2006-07-09 5:32 ` Stephen Hemminger [this message]
2006-07-09 5:32 ` Stephen Hemminger
2006-07-10 16:26 ` [Bridge] " Stephen Hemminger
2006-07-10 16:26 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060708223240.57cfd14f@localhost.localdomain \
--to=shemminger@osdl.org \
--cc=bridge@lists.osdl.org \
--cc=kisch@sesamstrasse.dyndns.tv \
--cc=netdev@kernel.org \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.